Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

Why this matters

This is an important security / policy issue, not a cosmetic one.

OpenClaw documents that tool availability should be constrained by:

• tool profiles
• group / channel policy
• sandbox policy
• subagent depth policy

In particular, the docs explicitly say leaf subagents should have no session tools by default.

But the inline skill-command path for command-dispatch: tool does not use the normal tool-policy pipeline. It creates the raw OpenClaw tool set and only applies owner-only filtering before invoking the requested tool.

That means a user-invocable skill slash command can expose tools that the current session should not have, depending on which tool a skill or plugin targets.

The problem

Normal agent turns build tools through createOpenClawCodingTools(...), which applies:

• profile policy
• agent / provider policy
• group policy
• sandbox policy
• subagent policy

The skill slash-command dispatch path does not.

Instead it does:

1. load user-invocable skill commands
2. if a skill uses command-dispatch: tool, call createOpenClawTools(...)
3. apply only applyOwnerOnlyToolPolicy(...)
4. execute the matched tool

So the command-dispatch path can diverge from the session's real effective tool set.

Impact

This breaks the expectation that "if /tools or the active profile says a tool is unavailable, the session cannot use it".

Examples of policy that can be bypassed by a tool-dispatch skill:

• messaging-profile sessions that should not have orchestration / coding tools
• subagent leaf sessions that should not have sessions_* control tools
• sandbox-aware tool gating, because this path does not thread the normal sandboxed filtering path
• runtime flags like intentionally omitting a tool from the current effective surface

Even if some core tools are awkward to drive through raw slash-command args, the policy mismatch itself is the bug: a supported user-facing feature is skipping the central authorization/filtering pipeline.

Steps to reproduce

1. Configure an agent with a restrictive tool profile, or use a leaf subagent where session tools should be denied.
2. Add a user-invocable skill with frontmatter like:

---
name: spawn-subagent
description: Spawn subagent
command-dispatch: tool
command-tool: sessions_spawn
---

3. Invoke the skill slash command from that restricted session.
4. Observe that the inline dispatcher resolves tools via createOpenClawTools(...) instead of the normal filtered tool surface.

Expected behavior

Skill slash commands that dispatch directly to tools should use the same effective tool set as the current session.

At minimum, this path should honor the same filtering used by normal agent turns:

• profile policy
• group/channel policy
• sandbox policy
• subagent policy

Actual behavior

command-dispatch: tool currently skips that policy pipeline and can see tools that should have been removed from the session's effective surface.

OpenClaw version

2026.4.27

Operating system

Any

Install method

Any

Model

N/A (model-independent)

Provider / routing chain

N/A (local tool-policy issue, reproducible before provider dispatch)

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response