Summary

• Problem: the shared /approve command submitted approval decisions through the generic callGateway helper. That opened an ordinary transient Gateway request instead of the operator approvals resolver/client path, so approvals that require the trusted approval-runtime client context could be invisible and surface as unknown or expired.
• Solution: route /approve submissions through resolveApprovalOverGateway. That helper connects via the operator approvals Gateway client path and sends approval decisions with the approval-runtime client context used by the exec/plugin approval managers.
• What changed: updated the shared approve command handler to use the approval resolver, preserved exec approval behavior, kept plugin approval routing for plugin:<id> approvals, refreshed focused tests around resolver calls and fallback routing, and documented that /approve handles exec and plugin approvals.
• What did NOT change (scope boundary): approval authorization policy, approver config shape, native approval delivery, and approval id formats are unchanged.

Motivation

• Manual /approve should behave like native approval actions: it needs to resolve through the trusted approval runtime, not through a one-off generic Gateway call. The failure was observed from Slack with /approve plugin:<id>, but the fix is in the shared command path and applies to approval submission generally.

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 #
• Related #
• This PR fixes a bug or regression

Real behavior proof (required for external PRs)

• Behavior addressed: manual channel /approve should resolve pending exec/plugin approvals through the approval resolver instead of returning unknown or expired approval id because the generic Gateway client path cannot see the approval.
• Real environment tested: isolated local OpenClaw Gateway on macOS/Darwin arm64, Node v24.15.0. The proof used a Slack native command context against the real Gateway approval APIs and resolver path; it did not call the Slack network.
• Exact steps or command run after this patch: node --import tsx --input-type=module <temporary proof harness> | tee /tmp/openclaw-pr-84678-approval-proof.txt; then node scripts/run-vitest.mjs src/auto-reply/reply/commands-approve.test.ts.
• Evidence after fix (screenshot, recording, terminal capture, console output, redacted runtime log, linked artifact, or copied live output):

proof started gateway_url=ws://127.0.0.1:52702
proof command_context=slack native /approve
proof approval_listener=ready scopes=operator.approvals internal_runtime=true
plugin request accepted status=accepted id=plugin:fe8734e7-2b24-4549-9bc3-6e9a675c0427
plugin command reply=✅ Approval allow-once submitted for plugin:fe8734e7-2b24-4549-9bc3-6e9a675c0427.
plugin waitDecision id=plugin:fe8734e7-2b24-4549-9bc3-6e9a675c0427 decision=allow-once
exec request accepted status=accepted id=proof-exec-3a13b093-ef6e-48cb-a09e-827bd7756e66
exec command reply=✅ Approval allow-once submitted for proof-exec-3a13b093-ef6e-48cb-a09e-827bd7756e66.
exec waitDecision id=proof-exec-3a13b093-ef6e-48cb-a09e-827bd7756e66 decision=allow-once
gateway events=plugin.approval.requested,plugin.approval.resolved,exec.approval.requested,exec.approval.resolved
proof result=pass

Focused test output:

node scripts/run-vitest.mjs src/auto-reply/reply/commands-approve.test.ts
Test Files  1 passed (1)
Tests       18 passed (18)

• Observed result after fix: /approve plugin:<id> allow-once in a channel command context resolved a live pending plugin approval through plugin.approval.resolve, and /approve <exec-id> allow-once still resolved an exec approval through exec.approval.resolve. Gateway events included requested and resolved events for both approval families.
• What was not tested: actual Slack app network slash-command callback delivery from Slack's servers; this proof invokes the Slack command handler locally while using a real Gateway and WebSocket approval clients.
• Before evidence (optional but encouraged): prior manual Slack /approve plugin:<id> allow-once returned Failed to submit approval: unknown or expired approval id.

Root Cause (if applicable)

• Root cause: /approve bypassed resolveApprovalOverGateway and called callGateway directly. The generic call did not use the operator approvals client path that supplies the trusted approval-runtime client context required by approval visibility checks.
• Relevant contract: approval resolution filters pending approval records through the connected Gateway client. A trusted approval-runtime client is established by connecting as the Gateway backend approval client with operator.approvals scope and the approval runtime token; resolveApprovalOverGateway owns that connection path.
• Missing detection / guardrail: tests asserted raw Gateway method calls instead of verifying that /approve uses the approval resolver path used by native approval actions.
• Contributing context (if known): exec and plugin approvals both resolve through the shared approval visibility contract; plugin ids additionally need plugin.approval.resolve routing.

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/commands-approve.test.ts
• Scenario the test should lock in: /approve calls resolveApprovalOverGateway instead of callGateway, preserves exec approval submission, routes plugin:<id> submissions to plugin approval resolution, and still enforces configured approvers across the shared command path.
• Why this is the smallest reliable guardrail: the regression was in shared command routing, before any live channel delivery behavior.
• Existing test that already covers this (if any): existing approve-command tests covered parsing/auth and are updated to assert the resolver path.
• If no new test is added, why not: N/A.

User-visible / Behavior Changes

Manual /approve commands now submit decisions through the same approval resolver path used by trusted approval clients, so pending exec/plugin approvals can be resolved from channel command surfaces as documented.

Diagram (if applicable)

Before:
/channel /approve <id> -> callGateway -> ordinary transient gateway call -> approval may be hidden -> unknown/expired

After:
/channel /approve <id> -> resolveApprovalOverGateway -> operator approvals client -> approval manager -> resolved

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): No
• Data access scope changed? (Yes/No): No
• If any Yes, explain risk + mitigation: N/A.

Repro + Verification

Environment

• OS: Darwin 25.2.0 arm64
• Runtime/container: local worktree, Node v24.15.0, pnpm 11.1.0
• Model/provider: N/A
• Integration/channel (if any): shared manual /approve command path; verified with a Slack command context and focused command-handler tests
• Relevant config (redacted): channel approval approver config exercised in tests

Steps

1. Submit /approve <id> <decision> from a configured approver.
2. Handler authorizes the sender for that approval family.
3. Handler calls resolveApprovalOverGateway to submit the decision through the operator approvals client path.

Expected

• Pending exec/plugin approval resolves or the actual resolver error is returned.

Actual

• Focused tests pass and assert approval routing through the resolver.

Evidence

Attach at least one:

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

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

• Verified scenarios: real local Gateway proof for channel-context /approve plugin:<id> allow-once, real local Gateway proof for exec /approve <id> allow-once, focused approve-command test suite with exec approvals, plugin approvals, fallback routing, authorization, and gateway-client scopes.
• Edge cases checked: unauthorized plugin approvers remain rejected in tests; legacy unprefixed fallback still attempts exec then plugin in tests; plugin-only not-found errors surface cleanly in tests.
• What you did not verify: actual Slack network callback from the hosted Slack app in this split worktree.

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.

Compatibility / Migration

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

Risks and Mitigations

• Risk: changing the manual command path could regress exec approval submission.
  • Mitigation: focused tests assert exec approval routing still submits successfully and preserve existing fallback behavior.