fix(chat): in-chat approval card can show a different command than Allow runs

[SebTardif]

What Problem This Solves

The in-chat approval card could display text different from the command an Allow action resolved, especially when Gateway text contained concealed Unicode, secret-shaped content, truncation, oversized content, or a missing command.

User Impact

• Reviewable commands retain Allow once, Always allow, and Deny once.
• Unreviewable or missing command content renders a Deny-only card with an explanation.
• Direct or stale Allow responses are blocked before exec.approval.resolve I/O unless the matching pending card permits that exact decision.

Why This Change Was Made

The existing display sanitizer already classified truncated, oversized, secret-redacted, and concealment-unsafe text. The chat mapper previously discarded those status flags and still offered Allow. The repair carries the sanitizer status into card actions and verifies the current pending card immediately before the existing approval RPC.

The original contributor commits remain on the original PR branch. The final follow-up adds deterministic native WinUI, production-provider, production-WebSocket, and Gateway-fixture proof.

Change Type

• Bug fix
• Feature
• Refactor
• Docs or instructions
• Tests or validation
• Security hardening
• Chore or infrastructure

Scope

• Tray or WinUI UX
• Windows node capability
• Local MCP command contract
• Gateway approval response
• Permissions, privacy, or security
• Tests, CI, or docs

Required proof pools

• windows-winui-interactive: PASS. The real isolated native chat view showed a reviewable card with Allow/Deny actions and a missing-command card with Deny only.
• windows-wsl-mxc: PASS. Strict non-skipping Gateway-to-node MXC validation completed 17/17.
• windows-wsl-gateway-e2e: Production approval I/O boundary verified against the repository loopback Gateway. The test uses the real OpenClawChatDataProvider, GatewayClientChatBridge, and OpenClawGatewayClient WebSocket request/response implementation. An installed external Gateway service was not required and no command was executed.

Validation

Current head: 8e6fe7c953604e0e9f189b92bbfd2df822f55844

• ./build.ps1: PASS.
• Shared: 4,110 passed, 32 skipped, 0 failed.
• Tray: 3,128 passed, 0 failed.
• Strict validate-mxc-e2e.ps1 without -AllowSkip: 17/17 passed.
• Gateway fixture integration: 30/30 passed.
• Native Gateway fixture UI: 5/5 passed.
• Focused fixture protocol tests verify valid issued-ID acknowledgement, invalid-decision retry, unissued-ID rejection, and concurrent double-resolve one-shot behavior.
• Security-focused rubber-duck review findings were addressed.

Real behavior proof

Native chat UI

GatewayFixtureUiTests.ApprovalCardsGateAllowAndResolveThroughGateway launches the freshly built app in a disposable profile and drives the actual native chat UI against the production WebSocket client and isolated loopback Gateway.

1. A reviewable echo fixture-safe approval rendered Allow once, Always allow, and Deny once. Clicking Allow once sent exec.approval.resolve with fixture-issued ID fixture-safe-approval and decision allow-once; the Gateway returned ok.
2. A missing-command approval visibly rendered only Deny is available, exposed no Allow actions, and clicking Deny once sent fixture-issued ID fixture-unreviewable-approval with decision deny; the Gateway returned ok. The active Deny-only state was captured by the fixture.
3. A superseded card's Allow actions disappeared and no third approval RPC was sent.

Production provider and WebSocket boundary

RespondToPermissionAsync_StaleAllowStopsBeforeProductionWebSocketIo connects a real OpenClawGatewayClient to the loopback Gateway, wraps it in the production GatewayClientChatBridge, and uses the real OpenClawChatDataProvider.

• Approval A is superseded by approval B.
• A direct stale Allow response for A is attempted through the production provider.
• No exec.approval.resolve WebSocket request is recorded for A.
• B remains the current pending approval.
• Allow for B sends the exact fixture-issued B ID with decision allow-once and receives ok.

This directly verifies rejection before final WebSocket I/O when approval state changes.

Fixture correlation safety

The synthetic Gateway:

• publishes only fixture-owned approval IDs;
• validates the decision before consuming the ID;
• consumes an issued ID atomically before acknowledgement, so overlapping resolves cannot both receive ok;
• allows a valid retry after an invalid decision;
• records only safe fixture correlation metadata;
• never executes a command;
• rejects unissued IDs and unsupported decisions with INVALID_PARAMS.

Security Impact

• New permissions or capabilities? No.
• Secrets or tokens handling changed? The existing sanitizer's safety status is now enforced by card eligibility.
• Network calls changed? No new production call. Unsafe or stale Allow is blocked before the existing approval RPC.
• Storage schema changed? No.

Compatibility and Migration

• Reviewable approval requests retain their existing actions and RPC path.
• No configuration or migration is required.

Review Conversations

• Current source and proof-harness findings are addressed.
• Required validation and native/production-path proof describe the current head.

[clawsweeper]

🦞👀
ClawSweeper picked this up.

Pull request received. I will update this pull request when review starts.

ClawSweeper review complete

ClawSweeper finished reviewing this revision. The review result is being finalized.

View the workflow run.

[clawsweeper]

Codex review: needs maintainer review before merge. Reviewed September 27, 2026, 3:11 PM ET / 19:11 UTC (Revision 14).

ClawSweeper review

What this changes

The branch sanitizes command text on native chat approval cards, limits unreviewable requests to Deny, checks pending approval state before sending a response, and adds fixture and UI coverage.

Merge readiness

✅ Ready for maintainer review

Keep this PR open. Current main still offers Allow for approval text the user cannot fully review, while this branch adds a guard at the approval RPC boundary. The prior review’s fixture finding is addressed, and the current-head proof covers the previously missing stale-Allow case.

Priority: P1
Reviewed head: 8e6fe7c953604e0e9f189b92bbfd2df822f55844

Review scores

Measure	Result	What it means
Overall readiness	🐚 platinum hermit (4/6)	The focused patch has current-head native and production-client proof, with no remaining concrete review finding.
Proof confidence	🦞 diamond lobster (5/6)	Sufficient (live_output): Current-head evidence reports a real isolated WinUI card sending safe Allow and missing-command Deny through the production WebSocket client to a loopback Gateway. A production-provider test observes stale Allow rejected before WebSocket I/O and current Allow acknowledged. No stored-data contract changes.
Patch quality	🐚 platinum hermit (4/6)	No actionable review findings were identified.

Verification

Check	Result	Evidence
Real behavior	Verified	Sufficient (live_output): Current-head evidence reports a real isolated WinUI card sending safe Allow and missing-command Deny through the production WebSocket client to a loopback Gateway. A production-provider test observes stale Allow rejected before WebSocket I/O and current Allow acknowledged. No stored-data contract changes.
Evidence reviewed	7 items	Current main still has the reported behavior: The fetched main revision maps raw command and message text into an approval card and offers the default Allow actions. Introduced card guard: The mapper uses the existing sanitizer’s status flags and offers only Deny when command or message text is truncated, oversized, or unsafe to review. Approval I/O guard: The provider checks the matching pending card and permitted decision before calling the existing approval RPC.
Findings	None	None.
Security	None	None.

How this fits together

Gateway approval events enter the Windows tray chat view as cards with command details and response buttons. A user’s response passes through the chat provider to the Gateway approval RPC, which can authorize command execution.

flowchart LR
A[Gateway approval event] --> B[Chat event mapper]
B --> C[Sanitize displayed text]
C --> D{Fully reviewable?}
D -->|Yes| E[Allow and Deny card]
D -->|No| F[Deny only card]
E --> G[Pending approval check]
F --> G
G --> H[Gateway approval response]

Loading

Before merge

None.

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
Production and test lines	production +36/-6, tests +573/-7	Most of the branch adds focused coverage around a small approval-path change.

Technical review

Best possible solution:

Land the card eligibility and pending-response guard together, retaining the native UI and production WebSocket regression coverage.

Do we have a high-confidence way to reproduce the issue?

Yes, from source: current main places raw approval text on a card with Allow actions, and the branch’s tests exercise unsafe and stale cases. This read-only review did not execute the application.

Is this the best way to solve the issue?

Yes. Reusing the established sanitizer and checking the pending card at the existing RPC entrypoint is a focused repair; the production-client and native UI tests cover the relevant effects.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning medium; reviewed against cf3626aa5ed7.

Labels

Label changes:

• add proof: sufficient: Contributor real behavior proof is sufficient. Current-head evidence reports a real isolated WinUI card sending safe Allow and missing-command Deny through the production WebSocket client to a loopback Gateway. A production-provider test observes stale Allow rejected before WebSocket I/O and current Allow acknowledged. No stored-data contract changes.
• add rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🦞 diamond lobster and patch quality is 🐚 platinum hermit.
• add status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (live_output): Current-head evidence reports a real isolated WinUI card sending safe Allow and missing-command Deny through the production WebSocket client to a loopback Gateway. A production-provider test observes stale Allow rejected before WebSocket I/O and current Allow acknowledged. No stored-data contract changes.
• remove status: 📣 needs proof: Current PR status label is status: 👀 ready for maintainer look.
• remove merge-risk: 🚨 automation: Current PR review merge-risk labels are merge-risk: 🚨 security-boundary.
• remove rating: 🦐 gold shrimp: Current PR rating is rating: 🐚 platinum hermit, so this older rating label is no longer current.

Label justifications:

• P1: A misleading command approval card affects a user-facing security decision in an active chat workflow.
• merge-risk: 🚨 security-boundary: The changed card actions and provider guard control whether an Allow decision can reach the Gateway approval RPC.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🦞 diamond lobster and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (live_output): Current-head evidence reports a real isolated WinUI card sending safe Allow and missing-command Deny through the production WebSocket client to a loopback Gateway. A production-provider test observes stale Allow rejected before WebSocket I/O and current Allow acknowledged. No stored-data contract changes.
• proof: sufficient: Contributor real behavior proof is sufficient. Current-head evidence reports a real isolated WinUI card sending safe Allow and missing-command Deny through the production WebSocket client to a loopback Gateway. A production-provider test observes stale Allow rejected before WebSocket I/O and current Allow acknowledged. No stored-data contract changes.

Evidence

What I checked:

• Current main still has the reported behavior: The fetched main revision maps raw command and message text into an approval card and offers the default Allow actions. (src/OpenClaw.Tray.WinUI/Chat/ChatEventMapper.cs:465, cf3626aa5ed7)
• Introduced card guard: The mapper uses the existing sanitizer’s status flags and offers only Deny when command or message text is truncated, oversized, or unsafe to review. (src/OpenClaw.Tray.WinUI/Chat/ChatEventMapper.cs:481, 8e6fe7c95360)
• Approval I/O guard: The provider checks the matching pending card and permitted decision before calling the existing approval RPC. (src/OpenClaw.Tray.WinUI/Chat/OpenClawChatDataProvider.cs:940, 8e6fe7c95360)
• Prior fixture finding addressed: The fixture validates the approval decision before atomically consuming an issued ID. Protocol tests cover invalid-then-valid retry and concurrent one-shot resolution. (tests/OpenClaw.TestSupport/Gateway/FixtureGatewayServer.cs:388, 8e6fe7c95360)
• Current-head final-effect proof: The new test uses the production provider and WebSocket client against a loopback Gateway. It asserts no approval request for a superseded ID and a successful response for the current ID; the PR body reports this test and the native UI fixture passing at the reviewed head. (tests/OpenClaw.Tray.Tests/OpenClawChatDataProviderTests.cs:14430, 8e6fe7c95360)
• Relevant code history: The current-main approval mapper lines trace to the chat runtime extraction associated with Barbara Kudiess. Recent provider history also includes Scott Hanselman’s chat runtime maintenance. (src/OpenClaw.Tray.WinUI/Chat/ChatEventMapper.cs:448, f8a8825ccbb4)

Likely related people:

• karkarl: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)
• shanselman: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

Rating scale

Score	Internal tier	Crab rank	Meaning
6/6	S	🦀 challenger crab	Exceptional readiness
5/6	A	🦞 diamond lobster	Very strong readiness
4/6	B	🐚 platinum hermit	Good normal PR; ordinary maintainer review
3/6	C	🦐 gold shrimp	Useful, but confidence is limited
2/6	D	🦪 silver shellfish	Proof or implementation needs work
1/6	F	🧂 unranked krab	Not merge-ready
N/A	NA	🌊 off-meta tidepool	Rating does not apply

Overall follows the weaker of proof and patch quality.
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

Workflow

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

History

Review history (13 earlier review cycles; latest 8 shown)

• reviewed 2026-09-27T16:42:04.418Z sha c8a3785 :: needs real behavior proof before merge. :: none
• reviewed 2026-09-27T16:54:35.922Z sha 9396ba2 :: needs real behavior proof before merge. :: none
• reviewed 2026-09-27T17:11:49.892Z sha 9396ba2 :: needs real behavior proof before merge. :: none
• reviewed 2026-09-27T17:55:50.573Z sha b18a234 :: blocked before merge. :: [P2] Reject approval IDs the fixture did not issue
• reviewed 2026-09-27T18:20:27.170Z sha 5b8dec1 :: needs real behavior proof before merge. :: none
• reviewed 2026-09-27T18:27:54.426Z sha 5b8dec1 :: needs real behavior proof before merge. :: [P2] Consume fixture approval IDs before acknowledging them
• reviewed 2026-09-27T18:38:24.405Z sha 5b8dec1 :: needs real behavior proof before merge. :: [P2] Consume fixture approval IDs before acknowledging them
• reviewed 2026-09-27T18:49:35.409Z sha 4067a74 :: needs real behavior proof before merge. :: [P2] Validate the decision before consuming its fixture approval ID

[karkarl]

Global triage: NEEDS_HUMAN_TEST. Take confidence 65%; recommendation confidence 92%; effort small-to-medium; risk medium.

Reviewed exact head de0164bfef42. The mapper and RPC choke-point guards consistently fail closed, and focused tests pass. Merge proof is incomplete: the reported validate-mxc-e2e.ps1 run exits 1 because all six MXC proofs skip, which is not valid exec-approval proof. Empty or missing command payloads also become Deny-only without an on-card explanation, and the provider guard logs then returns without user feedback.

Owner: maintainer proof scheduler. Run strict windows-wsl-mxc, capture isolated windows-winui-interactive evidence for truncated, oversized, concealed, and empty-command cards, and prove a real windows-wsl-gateway-e2e approval trace. Do not treat -AllowSkip as passing.

[SebTardif]

c8a3785 keeps Deny as the only action when the command text is missing, and the card now says that no command was included so only Deny is available.

Local filter Map_ApprovalRequestOffersOnlyDeny: 8 passed. Strict windows-wsl-mxc without -AllowSkip, WinUI cards for truncated, oversized, concealed, and empty commands, and a live gateway approval trace were not run on this pass.

[shanselman]

I now have strict BaseContainer support on this host. I am updating this original branch onto current main without rewriting history, then running ./scripts/validate-mxc-e2e.ps1 without -AllowSkip and the required Shared/Tray suites. I will post the exact updated SHA and results here.

[shanselman]

Validated updated exact branch head 9396ba2f512f110cf72ac32708ca206225462090 on a Windows 11 + WSL2 host where MXC 0.8 reports tier=base-container, needsDaclAugmentation=false, and no warnings.

Validation

• ./scripts/validate-mxc-e2e.ps1 without -AllowSkip: PASS, 17/17 tests.
• Required Gateway proofs passed:
  • MirroredWslSafeGatewayPort_IsListeningAndRecorded
  • RealGateway_SystemRun_ExecutesThroughWindowsNodeMxcSandbox
  • RealGateway_SystemRun_BlocksWritesToTrayDataDirectoryInMxcSandbox
• dotnet test ./tests/OpenClaw.Shared.Tests/OpenClaw.Shared.Tests.csproj --no-restore: PASS, 4,107 passed, 32 skipped, 0 failed.
• dotnet test ./tests/OpenClaw.Tray.Tests/OpenClaw.Tray.Tests.csproj --no-restore: PASS, 3,126 passed, 0 failed.

The validation process used task-local TEMP/TMP on D:\ because this account's default %TEMP% ACL prevents WSL from attaching a new disposable distro VHDX. No global ACL or WSL settings were changed, and fixture uninstall completed.

@clawsweeper re-review

[clawsweeper]

🦞👀
Exact review queued.

Re-review progress:

• State: Complete
• Detail: The durable review result and its route handoff completed.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/36335035817
• Updated: 2026-09-27T16:56:10.761Z

[shanselman]

Current head b18a234ef3e989b504f61541d03295d744e817bf now includes current-head final-effect proof through the real isolated WinUI app and synthetic loopback Gateway.

Changed-path behavior proof

GatewayFixtureUiTests.ApprovalCardsGateAllowAndResolveThroughGateway passed against the freshly built app:

1. A reviewable echo fixture-safe approval rendered Allow once, Always allow, and Deny once. Clicking Allow once sent exec.approval.resolve with the exact fixture-owned ID fixture-safe-approval and decision allow-once; the Gateway returned ok.
2. An approval with missing command text visibly rendered the explanation only Deny is available, exposed no Allow/Always allow buttons, and clicking Deny once sent the exact ID fixture-unreviewable-approval with decision deny; the Gateway returned ok. A screenshot was captured from this active state.
3. A later approval was resolved before response; its Allow actions disappeared and the Gateway received no third approval RPC.
4. A direct provider regression also proves a stale superseded approval ID cannot send Allow while the current ID can.

The fixture retains only safe test-owned approval IDs and the validated decision enum. It never executes a command.

Validation

• ./build.ps1: PASS.
• Shared: 4,108 passed, 32 skipped, 0 failed.
• Tray: 3,127 passed, 0 failed.
• Strict validate-mxc-e2e.ps1 without -AllowSkip: 17/17 passed.
• Gateway fixture integration: 30/30 passed.
• Native Gateway fixture UI: 5/5 passed, including the new approval proof.
• Rubber-duck security review findings were addressed before push.

@clawsweeper re-review

[clawsweeper]

🦞👀
Exact review queued.

Re-review progress:

• State: Complete
• Detail: The durable review result and its route handoff completed.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/36338827188
• Updated: 2026-09-27T17:57:33.162Z

[shanselman]

Current head 5b8dec189304864af4cd0560e57c059fd89dbaa7 now requires the synthetic Gateway to have issued an approval ID before exec.approval.resolve can receive a synthetic acknowledgement. Issued IDs are fixture-owned, one-shot, and recorded only with a validated decision enum; unissued IDs and unsupported decisions return INVALID_PARAMS.

Final validation after that guard:

• ./build.ps1: PASS.
• Shared: 4,109 passed, 32 skipped, 0 failed.
• Tray: 3,127 passed, 0 failed.
• Strict MXC: 17/17 passed.
• Gateway fixture integration: 30/30 passed.
• Native Gateway fixture UI: 5/5 passed.
• Focused protocol correlation: valid issued ID acknowledged; unsupported decision rejected; unissued fixture ID rejected.

The production approval path remains the real OpenClawGatewayClient WebSocket request/response implementation. The synthetic loopback Gateway supplies deterministic fixture-owned events and acknowledgements without executing a command or contacting an external service.

@clawsweeper re-review

[clawsweeper]

🦞👀
Exact review queued.

Re-review progress:

• State: Complete
• Detail: The durable review result and its route handoff completed.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/36340848959
• Updated: 2026-09-27T18:30:00.892Z

[shanselman]

The current-head Core/CLI failure is the same unrelated MigrationRecordTests 30-second timeout that intermittently blocked #1477. This run passed 1,119 Connection tests and failed only that baseline migration-script theory; the PR-specific protocol, fixture, UI, Shared, Tray, and MXC suites are green. I have requested a failed-job rerun.

[shanselman]

@clawsweeper re-review

[clawsweeper]

🦞👀
Exact review queued.

Re-review progress:

• State: Complete
• Detail: The durable review result and its route handoff completed.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/36342164282
• Updated: 2026-09-27T18:51:15.355Z

[shanselman]

@clawsweeper re-review

[clawsweeper]

🦞👀
Exact review queued.

Re-review progress:

• State: Complete
• Detail: The durable review result and its route handoff completed.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/36343505449
• Updated: 2026-09-27T19:12:45.611Z