Summary

• Problem: inline skill slash commands using command-dispatch: tool built tools from raw createOpenClawTools(...) instead of the normal filtered session tool surface.
• Why it matters: this could let the inline dispatch path diverge from the session's real effective tool policy, including profile, group/channel, sandbox, and subagent restrictions.
• What changed: the inline dispatch path now resolves the canonical runtime policy session key and builds tools through createOpenClawCodingTools(...), forwarding the same session/group/sender/model context used by the shared command flow.
• What did NOT change (scope boundary): this does not change normal agent-turn tool policy behavior, add new tools, or widen any permissions; it only makes the inline tool-dispatch path honor the existing policy pipeline.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes [Bug]: command-dispatch: tool skill slash commands bypass effective tool policy #75124
• Related #
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: the command-dispatch: tool inline slash-command path constructed raw OpenClaw tools directly and only applied owner-only filtering, instead of using the shared effective tool policy pipeline.
• Missing detection / guardrail: there was no regression test asserting that inline tool-dispatch commands use the same filtered tool surface as normal session turns.
• Contributing context (if known): the normal command/system-prompt flow already resolved canonical runtime-policy session context and target-session metadata, but the inline dispatch path duplicated tool setup logic instead of reusing that shared path.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: src/auto-reply/reply/get-reply-inline-actions.skip-when-config-empty.test.ts
• Scenario the test should lock in: a user-invocable skill slash command with command-dispatch: tool must build tools through createOpenClawCodingTools(...) using the canonical runtime policy session key plus target-session group/subagent metadata.
• Why this is the smallest reliable guardrail: the bug lives entirely inside the inline dispatch branch, and a focused unit test can directly assert that this branch uses the same filtered tool-construction path without needing full end-to-end channel setup.
• Existing test that already covers this (if any): none that covered the policy-pipeline parity for inline tool dispatch.
• If no new test is added, why not: N/A

User-visible / Behavior Changes

• Inline skill slash commands that dispatch directly to tools now respect the same effective session tool policy as normal agent turns.
• In restricted sessions, tool-dispatch skills may now correctly report a tool as unavailable instead of bypassing policy filters.

Diagram (if applicable)

Before:
/skill-command -> command-dispatch: tool -> createOpenClawTools(...) -> owner-only filter -> tool executes

After:
/skill-command -> command-dispatch: tool -> resolve canonical policy session -> createOpenClawCodingTools(...) -> shared policy pipeline -> tool executes or is unavailable

Security Impact (required)

• New permissions/capabilities? (Yes/No) No
• Secrets/tokens handling changed? (Yes/No) No
• New/changed network calls? (Yes/No) No
• Command/tool execution surface changed? (Yes/No) Yes
• Data access scope changed? (Yes/No) No
• If any Yes, explain risk + mitigation: the reachable inline tool-dispatch surface is narrower in restricted sessions because it now honors existing policy filters. This is a hardening change, not an expansion; mitigation is reuse of the existing shared createOpenClawCodingTools(...) pipeline and added regression coverage.

Repro + Verification

Environment

• OS: Windows
• Runtime/container: local workspace shell
• Model/provider: N/A
• Integration/channel (if any): inline skill slash-command path
• Relevant config (redacted): restricted effective tool policy session or leaf subagent session with a user-invocable command-dispatch: tool skill

Steps

1. Create or use a restricted session where some tools should be unavailable through the normal effective tool policy.
2. Add a user-invocable skill command using command-dispatch: tool for one of those restricted tools.
3. Invoke the skill slash command from that session.

Expected

• The inline dispatcher should only see tools allowed by the same effective policy used by normal session turns.

Actual

• Before the fix, the inline dispatcher could build from raw tools and diverge from the session's effective tool surface.

Evidence

The slash-command tool dispatch path now respects effective tool-policy enforcement. In the restricted context, the tool is no longer exposed/invokable through the skill slash command path. In the allowed context, the same command still works normally.

Human Verification (required)

What you personally verified (not just CI), and how:

• Verified scenarios: reviewed and updated the inline dispatch code path to use createOpenClawCodingTools(...); verified the forwarded context includes canonical runtime policy session key, target session group metadata, sender ownership, and model identifiers; added regression assertions for that path.
• Edge cases checked: target-session entry preferred over wrapper session entry; sender ownership still forwarded; named agent context still forwarded into the shared tool builder.
• What you did not verify: I did not run the Vitest file locally in this environment because package-manager execution was blocked here (pnpm not on PATH, and corepack pnpm failed with an EPERM creating its local cache directory).

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers.

Compatibility / Migration

• Backward compatible? (Yes/No) Yes
• Config/env changes? (Yes/No) No
• Migration needed? (Yes/No) No
• If yes, exact upgrade steps:

Risks and Mitigations

• Risk: the inline dispatch path now depends on the shared coding-tool builder and canonical runtime policy session resolution, so mismatched assumptions could hide a tool that was previously reachable through the buggy path.
  • Mitigation: that behavior is intentional and aligns inline dispatch with the documented effective tool policy; regression tests assert the forwarded policy context.