[bkudiess]

Depends on #2063 (feat: decide approvals from the Inbox and background toasts), which depends on #2060 (feat: show live Gateway approvals, automation failures and account alerts in the Inbox) and #2057 (feat: web-aligned Inbox for the footer bell and notifications page). This is layer 4 of 4; it includes the lower layers' commits, so review only the top two commits (feat(inbox): Do not disturb and This PC alerts in the Inbox and fix(inbox): Do not disturb lets pairing and scope-upgrade requests through).

What Problem This Solves

There was no way to silence OpenClaw alerts without also missing approvals, and nothing told you when Windows privacy settings blocked a device that an enabled node capability (camera, microphone, location) needs.

User Impact

User impact: the Inbox (bell flyout and full Inbox page) has a Do not disturb toggle. While it is on, Windows toasts, their sounds and in-app banners stay silent for everything except approvals and device pairing or scope-upgrade requests ("Approvals always come through"); the Inbox still collects items and the bell still counts them, and the bell switches to a slashed bell with help text "Do not disturb is on. N waiting". The System tab now shows This PC alerts (for example "This PC: camera access is off") with Open Windows privacy settings, which disappear when the block clears or the capability is turned off. This PC alerts work in the packaged (MSIX/Store) app; unpackaged development builds never show them (see Evidence).

Why This Change Was Made

• One Do not disturb rule. DoNotDisturbPolicy decides; ToastService.ShowToast applies it using the alert kind AppNotificationPublisher derives from the existing Inbox classification (so exec-approval Gateway notifications still toast), and AppNotificationInfoBarPresenter applies it to banner eligibility without forgetting banners the user closed. Background approval toasts from ApprovalToastPresenter are never silenced. The Settings Send test notification button stays an explicit user test.
• Persisted through the settings owner. SettingsData.DoNotDisturb is a field-scoped ISettingsStore save; hosts read and toggle it only through InboxFeed, which ignores stale change events.
• No consent prompts. This PC alerts read AppCapability.CheckAccess (no prompt) only for devices an enabled capability needs while node or MCP mode is on: camera for camera.*, microphone for speech-to-text and camera clips (they record sound by default), location for location.get. They re-read on settings saves and Windows access-change events; a dismissed row stays dismissed until its block clears or changes. The action opens only the matching ms-settings:privacy-* page.
• Fixture isolation kept. Fixture mode never reads host privacy state and never launches Settings; OPENCLAW_FIXTURE_DEVICE_ACCESS supplies synthetic access for manual fixture proof.
• New strings are localized in all six locales; docs/ARCHITECTURE.md gains the Do not disturb and This PC rows.

Evidence

Fixture Gateway (chat-interactive, approval). The first two screenshots come from an earlier build of this branch, before the fix that attaches settings after the service provider exists (the bell badge path did not change); the rest come from the final code. Plain bell, nothing waiting:

Amber count while an approval waits; the flyout shows the new Do not disturb row:

Do not disturb on: slashed bell, the amber count still shows, and the approval is still listed. The bell's help text reads "Do not disturb is on. 1 waiting" and settings.json holds "DoNotDisturb": true:

Do not disturb on the full Inbox page:

This PC row in the System tab with an accent (non-approval) count, from a fixture app launched with camera enabled and OPENCLAW_FIXTURE_DEVICE_ACCESS=camera=denied-by-user:

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 or winnode
• Gateway, connection, or pairing
• Setup or onboarding
• Permissions, privacy, or security
• Tests, CI, or docs

Required proof pools

• windows-winui-interactive: new Inbox Do not disturb states, the slashed bell and This PC rows need current-head visual, accessibility and notification proof in the WinUI app, including on-screen toast suppression and a real privacy block in the packaged app.

Validation

Run on head 247abef2 after rebasing onto #2063's review fixes (3e904ada) (Windows 11 ARM64, .NET SDK 10.0.403, OPENCLAW_REPO_ROOT set to the worktree):

• ./build.ps1: passed (Shared, Cli, WinNodeCli, SetupEngine, WinUI; documentation and proof-pool validation passed).
• dotnet test ./tests/OpenClaw.Shared.Tests/OpenClaw.Shared.Tests.csproj --no-restore: passed 4922, failed 0, skipped 25 (existing opt-in integration/MXC/GPU skips).
• dotnet test ./tests/OpenClaw.Tray.Tests/OpenClaw.Tray.Tests.csproj --no-restore: passed 5407, failed 0, skipped 0.
• git diff --check: clean.
• Focused: DoNotDisturbTests (policy matrix, pairing and scope-upgrade requests come through while a standard alert stays silent, pairing results stay standard, both App pairing-request toasts tagged as approvals, approval tagging in AppNotificationPublisher, banner suppression/restore including closing an approval banner while on, persistence, settings attached later, stale change events, toast-service source guard), ThisPcAlertsTests (only enabled capabilities are read, unknown/allowed is not a block, camera needs the microphone, system-managed copy, route allowlist, fixture override parsing, publish/withdraw/dismiss/re-episode/replace through ThisPcAlertSource), GatewayFixtureIsolationContractTests (no host privacy reads or Settings launch in fixture mode), LocalizationValidationTests.
• Independent review: rubber-duck reviewed the implementation; its blocking findings (fixture Settings launch, microphone for camera clips, banner hide state, settings attached before the store existed) were fixed, and its re-check found no remaining blocking issues.

Review fixes

• Dual-model review of the stack (L4-dnd-pairing-requests, low): Do not disturb silenced device pairing and scope-upgrade request toasts and banners although users decide them like approvals. DoNotDisturbPolicy now treats Inbox access requests as approvals, and App's node-pairing-pending and pairing-request toasts pass AlertKind.Approval; paired/rejected results stay standard.
• Rebased onto feat: decide approvals from the Inbox and background toasts #2063's review fixes; the ledger keeps the lower layers' updated approval rows.

Real Behavior Proof

• Environment tested: Windows 11 ARM64, Debug build (unpackaged) of this commit's source, Gateway fixture (scripts/run-gateway-fixture.ps1 -Scenario chat-interactive -Interaction approval), plus a second fixture-isolated app on a copy of that profile with NodeCameraEnabled true and OPENCLAW_FIXTURE_DEVICE_ACCESS=camera=denied-by-user.
• PR head or commit tested: screenshots and UIA reads come from the source of 00f4c9f2 (the pre-rebase layer-4 commit). The review fix and the rebase onto feat: decide approvals from the Inbox and background toasts #2063 do not change the bell, toggle or This PC rendering; head 247abef2 was revalidated with the full test run above but not re-screenshotted.
• Exact steps or command run: sent run approval to trigger a real fixture exec.approval.requested; opened the bell; switched Do not disturb on; opened Open Inbox; read the bell and toggle through UI Automation; read the profile settings.json.
• Evidence after fix: screenshots above; UIA bell help "Do not disturb is on. 1 waiting", toggle Name: Do not disturb, HelpText: Approvals always come through, value on/off; settings.json DoNotDisturb: true.
• Observed result: plain, amber, slashed and accent bell states render as designed; Do not disturb persists and keeps the approval listed and counted; the This PC row lands in the System tab with the privacy-settings action.
• Screenshot or artifact links verified? (Yes/No/N/A) Yes
• Not verified or blocked: on-screen toast suppression (fixture and isolated instances suppress all toasts by design, so the rule is covered by unit and source tests only); a real Windows privacy block (needs an OS settings change on this shared host) and native AppCapability behavior in the packaged MSIX app. A native probe from an unpackaged process returned UserPromptRequired for webcam, microphone and location even though all are allowed, so unpackaged builds map to Unknown and show no This PC alerts (fail-safe, documented in the ledger). Clicking Open Windows privacy settings outside fixture mode was not exercised.

Security Impact

• New permissions or capabilities? (Yes/No) No
• Secrets or tokens handling changed? (Yes/No) No
• New or changed network calls? (Yes/No) No
• Command or tool execution surface changed? (Yes/No) No
• Data access scope changed? (Yes/No) Yes
• If any answer is Yes, explain the risk and mitigation: the app now reads Windows privacy access status for camera, microphone and location with AppCapability.CheckAccess, which never prompts, only for capabilities the user enabled and only while node or MCP mode is on. Only the status enum is logged; no notification or user content is logged or exported. The Inbox action launches only three allowlisted ms-settings:privacy-* URIs, and never in fixture mode.

Compatibility and Migration

• Backward compatible? (Yes/No) Yes
• Config or environment changes? (Yes/No) Yes
• Migration needed? (Yes/No) No
• If yes, list the exact upgrade steps: none. settings.json gains DoNotDisturb (default false when absent). OPENCLAW_FIXTURE_DEVICE_ACCESS is read only in Gateway fixture mode.

Review Conversations

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

[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 real behavior proof before merge.

What this changes

This PR adds a persisted Do not disturb toggle and Windows device-access alerts on top of the stacked Inbox changes.

Example: Do not disturb is enabled while one approval for echo fixture-only waits.

• Before: There is no quiet-mode toggle.
• After: The bell is slashed and still counts the approval, while ordinary interruptions are suppressed.

Review scores

Measure	Result	What it means
Overall readiness	🧂 unranked krab (1/6)	Useful visible feature evidence supports the final layer, but the cumulative patch retains serious approval-disclosure defects.
Proof confidence	🦐 gold shrimp (3/6)	Real behavior proof is necessary before merge. See Before merge.
Patch quality	🧂 unranked krab (1/6)	Security review found an item that needs attention.

Product

Kind: Feature · Worth it: Yes · Fix scope: Complete
User problem: Users cannot silence routine interruptions while retaining approvals, or see actionable warnings when Windows privacy settings block enabled device capabilities.
Reason: The collaborator-authored direction supplies useful controls and recovery links through existing native owners; no additional product approval is needed.

Merge readiness

⛔ Blocked before merge - 8 items remain

Keep open: this collaborator-authored feature is absent from main, but its included approval layer still has blocking disclosure defects.

Priority: P2
Reviewed head: 00f4c9f203661f0de437c7093b51ff07d08a3af1

Before merge

• Add real behavior proof - Authority-chain proof required: the Windows ARM64 fixture screenshots show the toggle, slashed bell, retained approval count and synthetic camera warning, but do not exercise native toast activation or rejection at the final operator transport write for missing scope, forged/replayed tokens, revocation or connection replacement. The body also explicitly leaves on-screen suppression, packaged AppCapability detection and the real privacy-settings action unverified. The additive DoNotDisturb field defaults to false, but no latest-stable existing-profile upgrade run is supplied. Provide current-head runtime evidence for these paths and redact credentials, IPs and non-public endpoints. After adding proof, update the PR body, then request a new review with @clawsweeper re-review. The PR author or someone with repository write access can request it.
• Expose the complete command before enabling approval (P1) - The command TextBlock stops after eight wrapped lines, while GatewayApprovalDecisions.CanReviewInFull only rejects sanitizer truncation beyond its much larger limit. A command consisting of echo , 2000 a characters and && whoami remains eligible for Allow once and Always allow although its final operation is hidden. Remove visual truncation and make the complete command scrollable, or withhold permit decisions until it is fully reviewable. This unchanged defect is also recorded on feat: decide approvals from the Inbox and background toasts #2063.
• Preserve plugin reviewer detail before offering approval (P1) - The parser discards request.detail, which the consumed Gateway contract defines as reviewer-only detail. A plugin request titled Run query, described as Execute the requested SQL, with its SQL in detail therefore offers permission without showing the actual query. Preserve this field in the pending model and display it as reviewable plain text before enabling permit actions. The same omission remains from feat: decide approvals from the Inbox and background toasts #2063.
• Report uncertain approval completion without claiming no send (P2) - This catch maps a timeout after the resolve RPC was transmitted to Failed, which displays Your decision wasn't sent. Try again. If the Gateway accepted the decision but its response and resolved event were lost, that statement is false and encourages retrying an authorization whose outcome is unknown. Use outcome-neutral wording across the supported locales, or distinguish confirmed pre-send failures from uncertain completion. This behavior is unchanged from feat: decide approvals from the Inbox and background toasts #2063.
• Resolve security concern: Incomplete disclosure weakens informed approval - These permit actions can authorize sensitive operations and reusable grants; connection fencing and one-shot tokens do not establish that the user reviewed the operation being authorized.
• Resolve merge risk - The author must establish that retained toast authority cannot reach an approval RPC after token replay, approval-scope loss or connection replacement.
• Improve patch quality - Add final-effect proof for an operator without approval scope and for forged, replayed, revoked and earlier-connection toast authority before approval RPC I/O.
• Add data-model compatibility proof - The review found that existing stored data may not work after upgrade. Show that existing data still loads and works with this change.

Findings

• [P1] Expose the complete command before enabling approval — src/OpenClaw.Tray.WinUI/Controls/InboxView.xaml:131-133
• [P1] Preserve plugin reviewer detail before offering approval — src/OpenClaw.Shared/GatewayPendingApproval.cs:160-165
• [P2] Report uncertain approval completion without claiming no send — src/OpenClaw.Tray.WinUI/Services/OperatorApprovalDecisions.cs:220-223
• [high] Incomplete disclosure weakens informed approval — src/OpenClaw.Tray.WinUI/Controls/InboxView.xaml:133

Tests

• Missing end-to-end proof: Missing scenarios are native interruption suppression with approval delivery preserved, packaged privacy-block detection and recovery, final-effect rejection of unauthorized or stale toast authority, and upgrade from the latest stable release with existing settings intact.

Agent review details

How this fits together

Gateway events and Windows privacy status feed the native Inbox; settings control interruptions, and approval decisions return through the authenticated operator client.

flowchart LR
  Gateway[Gateway] --> Sources[Inbox sources]
  Windows[Windows device access] --> Sources
  Sources --> Feed[Inbox feed]
  Settings[Settings store] --> Feed
  Feed --> UI[Inbox page and bell]
  Feed --> Alerts[Toasts and banners]
  UI --> Decisions[Approval decision owner]
  Decisions --> Gateway

Loading

Technical review

Best possible solution:

Keep the existing settings, notification and approval owners, expose complete approval details, and distinguish uncertain completion from a confirmed failure to send.

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

Source inspection establishes the approval-disclosure and timeout-feedback paths; supplied screenshots demonstrate the new visible states, but this review executed no target code.

Is this the best way to solve the issue?

The final layer appropriately extends existing owners: preserve approvals and Inbox collection while suppressing ordinary interruptions, and publish device blocks through the existing notification service without another connection or permission prompt.

Full review comments:

• [P1] Expose the complete command before enabling approval — src/OpenClaw.Tray.WinUI/Controls/InboxView.xaml:131-133
  The command TextBlock stops after eight wrapped lines, while GatewayApprovalDecisions.CanReviewInFull only rejects sanitizer truncation beyond its much larger limit. A command consisting of echo , 2000 a characters and && whoami remains eligible for Allow once and Always allow although its final operation is hidden. Remove visual truncation and make the complete command scrollable, or withhold permit decisions until it is fully reviewable. This unchanged defect is also recorded on feat: decide approvals from the Inbox and background toasts #2063.
  Confidence: 0.99
  Late finding: first raised on code an earlier review cycle already covered.
• [P1] Preserve plugin reviewer detail before offering approval — src/OpenClaw.Shared/GatewayPendingApproval.cs:160-165
  The parser discards request.detail, which the consumed Gateway contract defines as reviewer-only detail. A plugin request titled Run query, described as Execute the requested SQL, with its SQL in detail therefore offers permission without showing the actual query. Preserve this field in the pending model and display it as reviewable plain text before enabling permit actions. The same omission remains from feat: decide approvals from the Inbox and background toasts #2063.
  Confidence: 0.98
  Late finding: first raised on code an earlier review cycle already covered.
• [P2] Report uncertain approval completion without claiming no send — src/OpenClaw.Tray.WinUI/Services/OperatorApprovalDecisions.cs:220-223
  This catch maps a timeout after the resolve RPC was transmitted to Failed, which displays Your decision wasn't sent. Try again. If the Gateway accepted the decision but its response and resolved event were lost, that statement is false and encourages retrying an authorization whose outcome is unknown. Use outcome-neutral wording across the supported locales, or distinguish confirmed pre-send failures from uncertain completion. This behavior is unchanged from feat: decide approvals from the Inbox and background toasts #2063.
  Confidence: 0.99
  Late finding: first raised on code an earlier review cycle already covered.

Overall correctness: patch is incorrect
Overall confidence: 0.97

AGENTS.md: found and applied where relevant.

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

Merge-risk options

Maintainer options:

1. Validate approval authority before transport writes (recommended)
   The author should exercise allowed and forbidden toast activations through the real decision owner and operator transport, including replay, scope loss and connection replacement.

Provenance checked

• Notification list and shared footer changes intended behavior with a stated reason (feat(workspace): add native Home and Sessions workspace #1541: The native Workspace introduced its focused notification surface; later footer work shared that surface across Chat and Settings.)
• Toast delivery and sound changes intended behavior with a stated reason (fb9f30d: ToastService centralized deduplication, sound configuration and per-device idempotency; the new explicit quiet preference retains those responsibilities.)
• Chat approval RPC keeps the original intent (5505a85: Approval resolution must bypass the blocked chat turn through an RPC and retain retryable state on rejection or uncertain completion.)
• Pending request ownership keeps the original intent (323f46d: The protocol refactor centralized generation-safe request completion and lifecycle draining; the new kind-aware resolve retains that registry.)

Testing

Proof path: shipped entry point.

Security

Needs attention: The included approval surfaces can authorize operations without displaying their complete details.

Evidence

Security concerns:

• [high] Incomplete disclosure weakens informed approval — src/OpenClaw.Tray.WinUI/Controls/InboxView.xaml:133
  These permit actions can authorize sensitive operations and reusable grants; connection fencing and one-shot tokens do not establish that the user reviewed the operation being authorized.
  Confidence: 0.99

What I checked:

• Verified introduction and stack: The pinned introduction contains four stacked commits; the final Do not disturb layer is independently identifiable against its recorded parent. (00f4c9f20366)
• Main does not implement the feature: Current main retains the notification flyout and ungated standard-toast behavior, without DoNotDisturb or ThisPcAlert owners. (src/OpenClaw.Tray.WinUI/Services/ToastService.cs:27, b6f158ab257a)
• Command disclosure mismatch: The expanded command stops at eight wrapped lines, but permit eligibility checks sanitizer truncation at a much larger limit. (src/OpenClaw.Tray.WinUI/Controls/InboxView.xaml:133, 00f4c9f20366)
• Plugin detail discarded: The pending-approval parser retains description but has no field for request.detail, so the row cannot present it before authorization. (src/OpenClaw.Shared/GatewayPendingApproval.cs:163, 00f4c9f20366)
• Consumed Gateway disclosure contract: The patch consumes the Gateway plugin-approval protocol and explicitly mirrors its web reviewer. That protocol supplies reviewer-only detail, and the web renderer displays pluginDetail separately from description. (packages/gateway-protocol/src/schema/plugin-approvals.ts, 2ab781210c6f)
• Prior discussion independently verified: The review on feat: decide approvals from the Inbox and background toasts #2063 already identified the disclosure defects and uncertain-send wording; the responsible code remains unchanged in this stack. (7b2968711ac2)

Likely related people:

• Barbara Kudiess: Raw commit 3f6765e adds src/OpenClaw.Tray.WinUI/Controls/WorkspacePaneFooter.xaml.cs:26 relative to its recorded parents. This identifies author metadata, not feature responsibility or a PR merger. (role: source-line author; confidence: high; commits: 3f6765ea02f4; files: src/OpenClaw.Tray.WinUI/Controls/WorkspacePaneFooter.xaml.cs)
• Régis Brid: Raw commit 06ed71f adds src/OpenClaw.Tray.WinUI/Services/AppNotificationService.cs:7 relative to its recorded parents. This identifies author metadata, not feature responsibility or a PR merger. (role: source-line author; confidence: high; commits: 06ed71f3c01f; files: src/OpenClaw.Tray.WinUI/Services/AppNotificationService.cs)
• Ranjesh Jaganathan: Raw commit fb9f30d adds src/OpenClaw.Tray.WinUI/Services/ToastService.cs:14 relative to its recorded parents. This identifies author metadata, not feature responsibility or a PR merger. (role: source-line author; confidence: medium; commits: fb9f30de50e4; files: src/OpenClaw.Tray.WinUI/Services/ToastService.cs)

Preflight source

Source unknown. Source comparison at the observed PR snapshot only. Completion is self-reported; body, policy, tests, execution, and report bytes are not verified.

Review metrics

Metric	Value	Why it matters
Stack versus final layer	Full stack: +6492/-825 across 69 files; final layer: +1245/-33 across 35 files.	The cumulative merge includes prerequisite approval behavior, so the final layer cannot clear its inherited blockers.

Labels

Label changes:

• add P2: This is a useful new notification feature with normal priority, rather than a demonstrated regression affecting released users.
• add merge-risk: 🚨 security-boundary: The included approval controls authorize Gateway operations while command text can be visually truncated and plugin reviewer detail discarded.
• add proof: 📸 screenshot: Contributor real behavior proof includes screenshot evidence.
• add rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🦐 gold shrimp and patch quality is 🧂 unranked krab.
• add status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask.

Label justifications:

• P2: This is a useful new notification feature with normal priority, rather than a demonstrated regression affecting released users.
• merge-risk: 🚨 security-boundary: The included approval controls authorize Gateway operations while command text can be visually truncated and plugin reviewer detail discarded.
• rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🦐 gold shrimp and patch quality is 🧂 unranked krab.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask.
• proof: 📸 screenshot: Contributor real behavior proof includes screenshot evidence.

Rating scale

6/6 🦀 challenger crab · 5/6 🦞 diamond lobster · 4/6 🐚 platinum hermit · 3/6 🦐 gold shrimp · 2/6 🦪 silver shellfish · 1/6 🧂 unranked krab. Overall follows the weaker of proof and patch quality; ✨ marks media proof (a screenshot, video, or linked artifact) that directly shows the changed behavior.

Workflow

ClawSweeper edits this one comment on every review. Comment @clawsweeper re-review for a fresh review only. Repair and merge execution lanes are retired.

Reviewed November 7, 2026, 12:04 AM ET / 05:04 UTC.