Exec approval display keeps a braille blank in the command #2010

Activity

1. github-project-automation

   added this to Windows Companion Appon Nov 4, 2026
2. github-project-automation

   moved this to Backlog in Windows Companion Appon Nov 4, 2026
3. clawsweeper

   added

   clawsweeper:intake:bugPreliminary submission classification; full source review pending.Preliminary submission classification; full source review pending.

   clawsweeper:intake:needs-environmentPreliminary submission classification; full source review pending.Preliminary submission classification; full source review pending.

   clawsweeper:intake:needs-reproPreliminary submission classification; full source review pending.Preliminary submission classification; full source review pending.

   P2Normal priority bug or improvement with limited blast radius.Normal priority bug or improvement with limited blast radius.

   clawsweeper:bulk-filedClawSweeper detected a high recent issue-filing volume from this author.ClawSweeper detected a high recent issue-filing volume from this author.

   clawsweeper:needs-security-reviewClawSweeper marked this issue as needing security-sensitive review.ClawSweeper marked this issue as needing security-sensitive review.

   clawsweeper:no-new-fix-prClawSweeper does not recommend queueing a new automated fix PR for this issue.ClawSweeper does not recommend queueing a new automated fix PR for this issue.

   clawsweeper:source-reproClawSweeper found a high-confidence source-level issue reproduction.ClawSweeper found a high-confidence source-level issue reproduction.

   impact:securityThis issue is about security boundaries, credentials, authz, sandboxing, or sensitive data.This issue is about security boundaries, credentials, authz, sandboxing, or sensitive data.

   issue-rating: 🦞 diamond lobsterVery strong issue quality with high-confidence source-level or clear reproduction.Very strong issue quality with high-confidence source-level or clear reproduction.

   and removed

   clawsweeper:intake:bugPreliminary submission classification; full source review pending.Preliminary submission classification; full source review pending.

   clawsweeper:intake:needs-environmentPreliminary submission classification; full source review pending.Preliminary submission classification; full source review pending.

   clawsweeper:intake:needs-reproPreliminary submission classification; full source review pending.Preliminary submission classification; full source review pending.

   on Nov 4, 2026
4. clawsweeper commented on Nov 4, 2026

   

   clawsweeperBot

   on Nov 4, 2026 – with ClawSweeper

   More actions

   Codex review: this still needs some work.

   Summary
   This issue establishes a current approval-display defect: U+2800 survives sanitization and reaches the dialog without a warning, warranting security review.

   Reproducibility: Current source establishes that U+2800 survives the sanitizer and reaches the dialog without a confusable warning; no dialog, build or test was run during this read-only review.

   Next step
   Have the approval-security owners assess U+2800 rendering and shared redaction effects, then establish failing sanitizer and presenter regressions before changing the invisible-character set.

   Security
   Needs attention: The approval-display gap needs security assessment before an ordinary repair proceeds.

   Review details

   Best possible solution:

   Render U+2800 as a visible code-point escape while preserving execution payloads and legitimate Unicode text.

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

   Current source establishes that U+2800 survives the sanitizer and reaches the dialog without a confusable warning; no dialog, build or test was run during this read-only review.

   Is this the best way to solve the issue?

   The proposed explicit escape fits the sanitizer's existing purpose, provided regression coverage also checks the shared stripped-view redaction behavior.

   AGENTS.md: found and applied where relevant.

   Remaining risk / open question:

   • Actual Windows font rendering and a practical misleading-approval scenario have not been demonstrated.
   • IsInvisible also controls the stripped secret-redaction view, so adding U+2800 affects more than display escaping.

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

   Label changes

   Label changes:

   No label changes.

   Label justifications:

   • P2: A source-established approval-display gap merits repair, but no demonstrated exploit or urgent regression establishes broader severity.
   • impact:security: Agent-controlled invisible text can undermine the operator's understanding at an execution-authorization boundary.

   Evidence reviewed

   Security concerns:

   • [medium] Invisible character reaches an authorization prompt — src/OpenClaw.Shared/ExecApprovals/ExecApprovalCommandDisplaySanitizer.cs:281
     U+2800 passes unchanged into the approval command display and does not trigger the mixed-script warning; assess misleading rendering and the shared redaction implications without assuming an execution-policy bypass.
     Confidence: 0.94

   What I checked:

   • Current sanitizer omits U+2800: IsInvisible handles control, format, surrogate, separator categories and four explicit Hangul fillers, but excludes U+2800; EscapeInvisibles therefore preserves it. (src/OpenClaw.Shared/ExecApprovals/ExecApprovalCommandDisplaySanitizer.cs:266, 2c327dc5ac11)
   • Production presentation path: PromptAsync passes commandStatus.Text into the view, and the dialog binds view.CommandText directly to its monospaced TextBlock. (src/OpenClaw.Tray.WinUI/Dialogs/ExecApprovalDialog.cs:138, 2c327dc5ac11)
   • Warning does not compensate: The confusable detector classifies Latin, Greek and Cyrillic letters; U+2800 is script-neutral and cannot independently trigger its warning. (src/OpenClaw.Shared/ExecApprovals/ExecApprovalConfusableDetector.cs:57, 2c327dc5ac11)
   • Existing coverage establishes the intended boundary: Tests require visible escapes for invisible spoofing characters while preserving legitimate combining marks, variation selectors and homoglyphs; the inspected sanitizer and presenter tests lack a U+2800 regression. (tests/OpenClaw.Shared.Tests/ExecApprovalCommandDisplaySanitizerTests.cs:13, 2c327dc5ac11)
   • Related merged repair has a distinct scope: fix(chat): in-chat approval card can show a different command than Allow runs #1499 repaired chat-card eligibility and stale approval responses using existing sanitizer status; it did not add U+2800 classification.
   • Discussion and canonical search: The discussion contains only an automated review-start notice; searches for braille, U+2800, invisible approval text and this issue found no dedicated competing fix or canonical duplicate.

   Likely related people:

   • AlexAlves87: Raw commit 76f4d52 adds tests/OpenClaw.Shared.Tests/ExecApprovalCommandDisplaySanitizerTests.cs:13 relative to its recorded parents. This identifies author metadata, not feature responsibility or a PR merger. (role: source-line author; confidence: high; commits: 76f4d52c3b5e; files: tests/OpenClaw.Shared.Tests/ExecApprovalCommandDisplaySanitizerTests.cs)

   How this review workflow works

   • 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; those execution lanes are retired.
   • Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

   Reviewed November 4, 2026, 11:11 AM ET / 16:11 UTC.
5. SebTardif commented on Nov 4, 2026

   

   SebTardif

   on Nov 4, 2026

   ContributorAuthor

   More actions

   The fix is on fork branch fix/2010-braille-blank at 68f682996f315a705e04866299c8954d6c5d0781.

   This account cannot open the pull request. gh pr create returns CreatePullRequest forbidden, and REST POST /repos/openclaw/openclaw-windows-node/pulls returns 404. The repository pull request policy reads all.

   Compare link:

   https://github.com/openclaw/openclaw-windows-node/compare/main...SebTardif:fix/2010-braille-blank?expand=1
6. roboclaw-bot commented on Nov 10, 2026

   

   roboclaw-bot

   on Nov 10, 2026

   Contributor

   More actions

   I have prepared the narrowly scoped fix from SebTardif’s candidate, with contributor credit: U+2800 is rendered visibly by the existing approval-display sanitizer. The executed command and approval authority are not changed. Added coverage includes split-secret redaction, safe text and unchanged execution arguments; independent source/safety review found no actionable introduced defect.

   Native Windows tests, approval-display proof and the required containment proof are still pending. Keeping this issue open, and keeping the planned PR in draft status until the remaining validation is recorded.
7. roboclaw-bot commented on Nov 10, 2026

   

   roboclaw-bot

   on Nov 10, 2026

   Contributor

   More actions

   Draft #2104 (fix: exec approval display hides braille blanks in commands) is now open: #2104

   The draft is published from the roboclaw-bot fork with maintainer edits enabled and credits @SebTardif’s original fix. This issue remains open pending required native Windows tests, approval-display and MXC proof, review, and merge. Those validation results are not yet verified; the PR remains a draft.