refactor(tray): move Permissions into shared-state MVVM ownership

[bkudiess]

Moves the Permissions page's presentation, lifecycle, and shared settings behavior out of code-behind into a WinUI-free view model while preserving current security, command exposure, and visual behavior.

What changed

• Add a transient PermissionsPageViewModel and no-cache runtime projection, activated through the existing navigation scope.
• Make ISettingsStore field-scoped, serialized, versioned, and origin-aware so Settings, Permissions, tray, Hub, Connection, and local MCP writers converge without self-echo or stale updates.
• Add a narrow observable presentation contract over the existing App-owned V2 ExecApprovalsStore; runtime and UI continue sharing one authoritative store.
• Preserve V2 CAS metadata, invalid-path fail-closed behavior, dynamic inheritance, stable rule identity, monotonic events, and last-valid failure projection.
• Keep NodeCapabilityGating as the sole command-exposure owner and preserve BrowserProxyActivation/shared-token behavior.
• Rebuild the live capability list after permission changes and after local MCP restarts, so tools/list reflects current persisted permissions without a gateway reconnect or app restart.
• Reduce PermissionsPage.xaml.cs from 891 to 557 lines while leaving the visual tree intentionally unchanged.
• Update the architecture ledger and behavioral guards for single-owner shared mutable state.

Ownership transfer

• Old owner: PermissionsPage.xaml.cs directly owned settings mutation, runtime projection, approval-file presentation, and subscriptions.
• New owners: PermissionsPageViewModel, PermissionsPageRuntimeSource, ISettingsStore, and the App-owned ExecApprovalsStore presentation contract.
• Preserved invariant: field-scoped mutation persists before NotifySettingsSaved; active surfaces and MCP capability discovery converge to the newest version; command exposure remains owned by NodeCapabilityGating.

Scope decision

This lands as one atomic ownership transfer. Splitting the view model, shared-settings convergence, and V2 approval observation would temporarily leave parallel mutable owners or require throwaway compatibility paths. Visible Fluent/icon/card cleanup remains separate, so this PR stays behavior- and visual-identical.

Validation

Exact validated head: aaebf76640f4e2c67c40c77470bf86d98da2e086.

• ./build.ps1: all 5 projects passed
• OpenClaw.Shared.Tests: 3,415 passed, 32 skipped, 0 failed
• OpenClaw.Tray.Tests: 2,126 passed, 0 skipped, 0 failed
• OpenClaw.WinNode.Cli.Tests: 126 passed, 0 skipped, 0 failed
• Focused settings, Permissions, navigation, ownership, origin/version, and MCP-restart contracts: 191 passed, 0 skipped, 0 failed
• Total exact-head tests in the required suites: 5,667 passed, 32 skipped, 0 failed

The focused set includes restart rebuilding from current settings, origin suppression, monotonic versioning, two-consumer convergence without echo, background UI dispatch, stale mutation rejection, CAS retry preservation, Permissions row/order parity, and code-behind ownership guards.

External CI status

At the time of this update, the PR has 28 checks: 13 successful, 14 skipped, 1 failed, and 0 pending.

The failed aggregate Build and Test / test job reported two environmental/repository-wide blockers outside this PR's changed paths:

• Gateway LKG drift: pinned 2026.6.11, npm latest 2026.7.1-2.
• Two Shared process-launch tests timed out or missed output on the hosted runner: Run_EchoCommand_Powershell and Run_CapturesStderr.

Both Shared tests pass in the exact-head local run above. Build jobs were skipped after the aggregate test job failed. CodeQL is green.

Review status

ClawSweeper reviewed exact head aaebf76640f4e2c67c40c77470bf86d98da2e086 with no actionable findings and no security findings. Its remaining proof request was an exact-head runtime demonstration of the final MCP restart rebuild behavior. The transcript below provides that evidence.

Real behavior proof

Exact head aaebf76640f4e2c67c40c77470bf86d98da2e086 was launched with the side-by-side Dev identity, isolated tray data, and local MCP port 18765 because another worktree already owned the release identity and default listener.

• Exact proof process: PID 83076
• Unrelated existing process: PID 18988, left running and untouched
• Initial settings: Node mode off, Local MCP on, Camera on
• Final settings: Node mode off, Local MCP on, Camera on
• Only PID 83076 was stopped
• The isolated MCP bearer-token file was removed after proof

Inspectable exact-head transcript

HEAD aaebf76640f4e2c67c40c77470bf86d98da2e086
identity dev
MCP port 18765
proof PID 83076
unrelated PID 18988 remained running

# Initial raw JSON-RPC and winnode state
POST / tools/list -> HTTP 200
raw tool count: 51
camera tools: camera.list, camera.snap, camera.clip
winnode --list-tools -> 51
winnode app.settings.get NodeCameraEnabled -> true
winnode app.navigate permissions -> navigated=true
Permissions UI: Node mode Off, Camera On, Local MCP On

# Native Camera toggle through the open Permissions page
Camera UI: On -> Off
persisted NodeCameraEnabled: false
POST / tools/list -> HTTP 200
raw tool count: 48
camera tools: none
winnode --list-tools -> 48
winnode app.settings.get NodeCameraEnabled -> false

# Native Local MCP restart while Camera remains disabled
Local MCP UI: On -> Off
persisted EnableMcpServer: false
endpoint: stopped
Local MCP UI: Off -> On
persisted EnableMcpServer: true
POST / tools/list after restart -> HTTP 200
raw tool count after restart: 48
camera tools after restart: none
winnode --list-tools after restart -> 48
Permissions UI after restart: Camera Off, Local MCP On

# Restore through raw MCP to prove cross-surface convergence
POST / tools/call app.settings.set NodeCameraEnabled=true -> HTTP 200
JSON-RPC error: none
persisted NodeCameraEnabled: true
already-open Permissions UI Camera: On
POST / tools/list -> HTTP 200
raw tool count: 51
camera tools: camera.list, camera.snap, camera.clip
winnode --list-tools -> 51
winnode app.settings.get NodeCameraEnabled -> true

# Final restoration and cleanup
Node mode: false
Local MCP: true
Camera: true
proof PID 83076 stopped
unrelated PID 18988 still running
token file removed

This demonstrates the final restart fix directly: after Camera was disabled, stopping and restarting local MCP rebuilt capabilities from current persisted settings and continued serving 48 tools with no camera commands. Restoring Camera through raw MCP updated the already-open WinUI page and returned both raw JSON-RPC and winnode discovery to 51 tools.

Permissions UI and persisted-field parity

Native WinUI Automation inspected all visible permission toggles after restoration. 10/10 matched persisted settings:

Field	UI	Persisted
Node mode	Off	false
System tools	On	true
Browser control	On	true
Camera	On	true
Canvas	On	true
Screen capture	On	true
Location	On	true
Text-to-speech	Off	false
Speech-to-text	Off	false
Local MCP Server	On	true

Evidence manifest

The sanitized proof bundle retains raw JSON-RPC responses, winnode output, UI/settings parity, process cleanup, final-state restoration, and SHA-256 hashes. It does not retain the MCP bearer token.

Evidence	SHA-256
proof-summary.json	14a0326c99821d450a55323e4e33264f0b30ba53324eebe3c629aab630db7c21
initial raw 51-tool list	936527832a77fbf9caf30ea32f8f65850d2f1018c55cd765047689d1006cad4b
raw 48-tool list before restart	4694cc3c8496e3c5715b798864ce95e20a40102b65c5bdee009ec1a9fb52c0b4
raw 48-tool list after restart	12f5ecb44aee0d0c8d30b46f029db172f1ce06fec3a696973bbb75d3043a3efb
raw Camera restore call	c4a9e8d82de9bc3822ded9135c6b61e64c67fc93d30b486c53bf45a7c9d56a44
raw restored 51-tool list	82e846c38abbdd42c6c27902cce49ecdad4be1729f8947290369f5785698cd1c
10/10 UI/settings parity	3bbc8216d4fb7e44cece7fbeb1821335d4858a7b6ea3077eb528dddd5da84ef8

Current-main integration proof

A disposable detached workspace combined current main aac07abb1fbdaf2d75aa269397f094256188e1b5 with A0 aaebf76640f4e2c67c40c77470bf86d98da2e086 without rewriting any branch or remote.

• Merge base: d2de6150753b82c0f093582d0d1f9a20b59b2ef7
• Synthetic merge tree: f390ecf7cc830ccb9ee7ce09be35bbcd247dc12d
• Synthetic merge commit: 487e20364ff7dfdadd31e85842aafaeddf58b6a0
• Merge result: 42 staged files, 34 modified, 8 added, 0 deleted
• Hygiene: 0 unmerged, 0 unstaged, 0 untracked, no conflict markers, git diff --cached --check clean
• Source inclusion: all current-main chat/history/native-tool files and A0 Permissions/shared-state files included exactly once, with no duplicate <Compile> entries
• Ledger and behavior union: current-main NativeToolProjector/session-display/session-run ownership plus A0 Permissions/settings-owner rows and routing all present

Synthetic merge validation

• ./build.ps1: all 5 projects passed
• Full Shared: 3,428 passed, 32 skipped, 0 failed
• Full Tray: 2,238 passed, 0 skipped, 0 failed
• Full WinNode CLI: 126 passed, 0 skipped, 0 failed
• Focused A0 contracts: 191 passed, 0 failed
• Focused current-main Shared session/display/protocol regressions: 258 passed, 0 failed
• Focused current-main Tray chat, native-tool, history, tool-activity, session-display, and connection regressions: 694 passed, 0 failed
• Aggregate including repeated focused runs: 6,935 passed, 32 skipped, 0 failed

The disposable worktree was removed after validation. The retained sanitized merge manifest SHA-256 is 5a994a589b49318ea5284ca16dab675e0e3e27ad92c8e70bd732201b7b167404.

This proves the four overlapping files preserve the semantic union of current-main chat/session/tool behavior and A0 Permissions ownership. No A0-A3 branch rewrite is required for integration.

Deferred visual work

This PR intentionally preserves the existing capability icons, colors, cards, spacing, and copy. Fluent icon/token/SettingsCard cleanup remains a separate visible-design change.

[clawsweeper]

Codex review: needs maintainer review before merge. Reviewed August 11, 2026, 6:45 PM ET / 22:45 UTC.

ClawSweeper review

What this changes

The PR moves Permissions-page state, permission writes, and execution-approval presentation into shared observable owners, and rebuilds local MCP capabilities from current settings after a restart.

Merge readiness

⚠️ Ready for maintainer review - 3 items remain

Keep open. This collaborator-owned, actively landing base layer is mergeable and no discrete correctness defect was found; landing the broad ownership transfer remains a maintainer decision after current-head checks finish.

Priority: P2
Reviewed head: bd2ff648f36645af06086da55e18a95ce7c13fb2
Owner decision: Required. See Decision needed.

Review scores

Measure	Result	What it means
Overall readiness	🐚 platinum hermit (4/6)	The implementation has focused behavioral coverage and no actionable review finding; active checks remain the final current-head integration signal.
Proof confidence	🌊 off-meta tidepool	Not applicable: This collaborator PR is exempt from the external-contributor proof gate; its body nevertheless provides useful prior-head runtime MCP and Permissions evidence.
Patch quality	🐚 platinum hermit (4/6)	No actionable review findings were identified.

Verification

Check	Result	Evidence
Real behavior	Not applicable	Not applicable: This collaborator PR is exempt from the external-contributor proof gate; its body nevertheless provides useful prior-head runtime MCP and Permissions evidence.
Evidence reviewed	8 items	Architecture ownership: The current PR head records ISettingsStore, the exec-approvals presentation store, PermissionsPageViewModel, and PermissionsPageRuntimeSource as the authoritative owners, with direct page ownership closed. Settings convergence source: The shared store serializes edits, persists once, tags the synchronous save with its writer origin, and republishes a versioned snapshot. Approval safety source: Replacement rejects invalid or untrusted approval files before persistence, and typed observation failures retain the last valid presentation snapshot.
Findings	None	None.
Security	None	None.

How this fits together

The tray Permissions page edits persisted node permissions used by capability gating and the local MCP server. UI and MCP settings writers converge through shared stores, then tool discovery reads the resulting capability set.

flowchart LR
  A[Permissions page] --> B[Shared settings store]
  C[Local MCP settings call] --> B
  B --> D[Permissions view model]
  B --> E[Capability gating]
  E --> F[Local MCP server]
  F --> G[Tool discovery]
  D --> A

Loading

Decision needed

Question	Recommendation
Should this resolved Permissions ownership layer land now as the base for the dependent tray-refactor stack?	Land the resolved layer: Accept this current-main merge as the shared Permissions, settings, and approval ownership base after active checks complete.

Why: The change is an intentionally broad architectural transfer with downstream PR dependencies, so source correctness alone cannot choose its landing order.

Before merge

• Resolve merge risk (P1) - The current head merged main after the earlier exact-refactor-head runtime transcript, so its active hosted checks should complete before landing.
• Resolve merge risk (P1) - The PR changes persisted permission and execution-approval ownership across several existing surfaces, making it an intentional compatibility and security-boundary review point.

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
Diff composition	production +3,157/-985, tests +2,832/-167	The sizable ownership transfer includes substantial focused regression coverage.

Merge-risk options

Maintainer options:

1. Complete current-head validation (recommended)
   Wait for the active build and E2E checks because the current head resolved main after the earlier exact-head proof.
2. Accept the atomic transfer
   Once checks pass, maintainers may intentionally accept the broad ownership change as the stack's base layer.

Technical review

Best possible solution:

Land the current resolved head only after its active checks complete and the maintainer accepts this atomic shared-state ownership layer as the base for the dependent tray refactors.

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

Not applicable: this is an ownership refactor rather than a reported defect. The PR body includes a runtime exercise of the affected Permissions and MCP paths, although it predates the current integration merge.

Is this the best way to solve the issue?

Yes. The source follows the architecture ledger by keeping WinUI rendering in the page and moving shared mutable settings and approval state to dedicated observable owners.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against 4206611f2b2e.

Labels

Label justifications:

• P2: This is a broad but non-emergency tray refactor with no demonstrated user-facing regression.
• merge-risk: 🚨 compatibility: Existing persisted permission settings and their UI, tray, and MCP writers now converge through one store.
• merge-risk: 🚨 security-boundary: The refactor changes execution-approval presentation and node capability exposure while preserving fail-closed behavior.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🌊 off-meta tidepool and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: This collaborator PR is exempt from the external-contributor proof gate; its body nevertheless provides useful prior-head runtime MCP and Permissions evidence.

Evidence

What I checked:

• Architecture ownership: The current PR head records ISettingsStore, the exec-approvals presentation store, PermissionsPageViewModel, and PermissionsPageRuntimeSource as the authoritative owners, with direct page ownership closed. (docs/ARCHITECTURE.md:155, bd2ff648f366)
• Settings convergence source: The shared store serializes edits, persists once, tags the synchronous save with its writer origin, and republishes a versioned snapshot. (src/OpenClaw.Tray.WinUI/Presentation/SettingsStore.cs:53, bd2ff648f366)
• Approval safety source: Replacement rejects invalid or untrusted approval files before persistence, and typed observation failures retain the last valid presentation snapshot. (src/OpenClaw.Shared/ExecApprovals/ExecApprovalsStore.cs:492, bd2ff648f366)
• MCP restart behavior: Local-MCP enablement rebuilds capabilities when there is no gateway client; focused policy and gating tests cover disabled and restored Camera capability states. (src/OpenClaw.Tray.WinUI/Services/NodeService.cs:970, bd2ff648f366)
• Current-head provenance: The current head is a merge of the validated refactor head and current main, authored by Karen Lai as the conflict-resolution integration commit. (bd2ff648f366)
• Feature history: History connects Barbara Kudiess's prior merged Settings-page and V2 exec-approvals work with this branch, while Karen Lai authored the current integration merge. (src/OpenClaw.Tray.WinUI/Presentation/SettingsStore.cs:1, d2638ddbef57)

Likely related people:

• karkarl: Authored the current-main merge resolution and applied the actively-landing label. (role: current integration author; confidence: high; commits: bd2ff648f366; files: src/OpenClaw.Tray.WinUI/App.xaml.cs, src/OpenClaw.Tray.WinUI/Pages/PermissionsPage.xaml.cs)
• bkudiess: Feature history identifies Barbara Kudiess as the author of the prior Settings view-model and V2 exec-approvals work that this ownership transfer extends. (role: prior settings and approvals contributor; confidence: high; commits: d2638ddbef57, 4806eaac7c24, 7cd28b15af44; files: src/OpenClaw.Tray.WinUI/Presentation/SettingsStore.cs, src/OpenClaw.Shared/ExecApprovals/ExecApprovalsStore.cs)

Rank-up moves

Optional improvements that raise the rating; they are not merge blockers.

• Let the current running checks complete before landing.

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 (11 earlier review cycles; latest 8 shown)

• reviewed 2026-08-03T23:23:40.661Z sha 57ac65d :: needs maintainer review before merge. :: none
• reviewed 2026-08-05T06:27:51.333Z sha 57ac65d :: needs maintainer review before merge. :: none
• reviewed 2026-08-05T07:14:12.801Z sha 57ac65d :: needs maintainer review before merge. :: none
• reviewed 2026-08-05T08:06:37.838Z sha 57ac65d :: needs maintainer review before merge. :: none
• reviewed 2026-08-05T20:04:06.259Z sha aaebf76 :: needs maintainer review before merge. :: none
• reviewed 2026-08-06T08:12:43.157Z sha aaebf76 :: needs maintainer review before merge. :: none
• reviewed 2026-08-06T23:31:54.345Z sha aaebf76 :: needs maintainer review before merge. :: none
• reviewed 2026-08-11T20:16:52.430Z sha aaebf76 :: needs maintainer review before merge. :: none

[bkudiess]

@clawsweeper re-review

[clawsweeper]

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: when the review finishes, ClawSweeper will create the durable review comment if needed or update the existing comment in place.

Re-review progress:

• State: Complete
• Detail: The durable review result and its route handoff completed.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/30781423270
• Updated: 2026-08-03T03:17:05.700Z

[bkudiess]

@clawsweeper re-review

[clawsweeper]

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: when the review finishes, ClawSweeper will create the durable review comment if needed or update the existing comment in place.

Re-review progress:

• State: Complete
• Detail: The durable review result and its route handoff completed.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/30988104787
• Updated: 2026-08-05T08:13:05.212Z

[bkudiess]

@clawsweeper re-review

[bkudiess]

@clawsweeper re-review

[bkudiess]

Exact-head closeout for aaebf76640f4e2c67c40c77470bf86d98da2e086 is now in the PR body:

• 5/5 projects built; Shared 3,415 passed / 32 skipped; Tray 2,126 passed; WinNode CLI 126 passed; focused contracts 191 passed.
• Raw JSON-RPC and winnode proved Camera On 51 tools -> Camera Off 48 tools -> local MCP stop/start still 48 -> raw app.settings.set restored Camera and 51 tools.
• All raw requests returned HTTP 200 where expected, the restore call had no JSON-RPC error, and 10/10 visible Permissions toggles matched persisted fields.
• Initial state was restored, only the isolated proof PID was stopped, the unrelated OpenClaw PID remained running, and the isolated token file was removed.

@clawsweeper re-review

[clawsweeper]

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: when the review finishes, ClawSweeper will create the durable review comment if needed or update the existing comment in place.

[bkudiess]

Current-main merge-result validation is now complete and recorded in the PR body.

• Current main: aac07abb1fbdaf2d75aa269397f094256188e1b5
• A0: aaebf76640f4e2c67c40c77470bf86d98da2e086
• Synthetic tree: f390ecf7cc830ccb9ee7ce09be35bbcd247dc12d
• Synthetic merge commit: 487e20364ff7dfdadd31e85842aafaeddf58b6a0
• Build: 5/5 projects
• Full suites: Shared 3,428 passed / 32 skipped; Tray 2,238 passed; WinNode CLI 126 passed
• Focused: A0 191 passed; current-main Shared 258 passed; current-main Tray chat/session/native-tool/history/tool-activity regressions 694 passed
• Hygiene: 0 conflicts, git diff --cached --check clean, all required source includes unique, and all four overlap files preserve both current-main and A0 ownership semantics
• The disposable worktree was removed; A0-A3 branches remain unchanged.

The earlier ClawSweeper re-review is already queued, so no duplicate review command was posted.

[karkarl]

Current-head Permissions UI proof

Automated with Windows UI Automation against commit bd2ff648f36645af06086da55e18a95ce7c13fb2 in the isolated live app.

1. Shared Permissions overview

The page loaded current node status and capability settings through the new shared-state presentation path.

2. Invalid executable-path validation

Entered basename-only hostname and selected Add entry. The page kept the invalid value visible, displayed the inline error, and left the allowlist count at zero.

3. Saved and persisted path-only rule

Entered **/hostname.exe, added it, navigated to Settings, then returned to Permissions. The 1 entry badge and rule remained, proving save plus refresh through the shared store/view-model path.

Cleanup and result

• Removed the temporary **/hostname.exe rule after capture.
• Confirmed the badge returned to No entries.
• The app remained responsive throughout navigation, validation, save, refresh, and removal.