Keep Windows-node capability state truthful across Settings, Gateway declaration, and agent guidance

[RomneyDa]

Problem

A Windows-node capability can appear enabled in Hub Settings while the agent says it cannot use it, or a permitted capability can be undiscoverable to the agent. This creates a trust gap between the UI, Gateway/node declaration, runtime readiness, and chat behavior.

Desired outcome

One authoritative, inspectable capability state drives Settings, diagnostics, node declaration, and agent guidance.

Definition of done

• Report one capability state that includes: Settings toggle, Windows permission, Gateway declaration, pairing/approval, and runtime readiness.
• Surface the state in Command Center and in the context supplied to the agent.
• Provide actionable, unambiguous failure reasons for camera, browser proxy, and system.run.
• Add MCP tools/list and tools/call coverage plus gateway-path proof for each meaningful state transition.

Related

• Tool containment testing + triage (camera, browser) #850 is the broader tool-containment tracking epic.
• The PCMag report observed camera access enabled in the app while the agent stated that it could not access the camera: https://www.pcmag.com/opinions/microsoft-thinks-openclaw-is-the-future-of-windows-my-testing-says-otherwise

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 13, 2026, 4:22 PM ET / 20:22 UTC.

Summary
Keep open. This is a member-owned, actively landing request for a cross-surface capability-state contract; it cannot be auto-closed, and the local read-only command sandbox failed before current-source, history, and maturity inspection could establish that main already provides the requested authority.

Reproducibility: no. high-confidence reproduction is available from this review. The supplied report describes a credible inconsistency, but local source, tests, and runtime paths could not be inspected because read-only commands failed in the sandbox.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.

Maintainer decision needed

Question	Recommendation
Should the active Windows-node work adopt one canonical capability-state contract as the authority for Settings, gateway declaration, diagnostics, and agent guidance?	Adopt a canonical state model: Define one state contract that distinguishes requested, approved, permission, and runtime-ready status, then make each surface a projection of it.

Why: The requested outcome spans multiple product surfaces and requires maintainers to choose the lasting state semantics and owner boundary before implementation can be safely scoped.

Next step
This active member-owned, cross-surface design needs a maintainer-selected state contract before it can be split into safe implementation work.

Review details

Best possible solution:

Define a single capability-state contract with explicit desired, approved, permission, and runtime-readiness dimensions, then project it consistently into Settings, diagnostics, gateway declaration, and agent context with transition-level MCP and gateway proof.

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

No high-confidence reproduction is available from this review. The supplied report describes a credible inconsistency, but local source, tests, and runtime paths could not be inspected because read-only commands failed in the sandbox.

Is this the best way to solve the issue?

Unclear. A shared capability-state contract is a coherent direction, but source review is required to decide whether one materialized owner or a tested projection layer is the narrowest maintainable implementation.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Current source and history could not be read because the repository command sandbox failed, so existing implementation coverage cannot be verified.
• A canonical state must preserve the distinction between an enabled preference, an approved declaration, and presently usable runtime readiness to avoid replacing one misleading status with another.

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

Label changes

Label changes:

• add issue-rating: 🦪 silver shellfish: Current issue advisory state selects this label.
• add clawsweeper:needs-info: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.
• add clawsweeper:needs-product-decision: Current issue advisory state selects this label.

Label justifications:

• P2: Conflicting capability status can materially hinder Windows-node setup and tool use, but the supplied evidence does not establish an emergency outage or security bypass.
• impact:ux-friction: The report describes confusing, contradictory UI and agent guidance during capability readiness and permission flows.

Evidence reviewed

What I checked:

• Active member-owned work: The provided issue context identifies RomneyDa as a MEMBER and shows the issue is labeled "status: 🚢 actively landing". The review policy requires such items to remain open for explicit maintainer handling. (5d90e419be85)
• Related work is adjacent, not a duplicate: The issue identifies Tool containment testing + triage (camera, browser) #850 as the broader tool-containment epic. Its stated containment work does not establish a canonical Settings-to-agent capability-state contract. (5d90e419be85)
• Local inspection blocked: Every attempted read-only repository command failed immediately with "bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted", so current source, tests, git history, VISION.md, and the required maturity helper could not be inspected.

Likely related people:

• RomneyDa: A repository MEMBER authored the issue and the supplied timeline shows active landing status; local history was unavailable for deeper ownership tracing. (role: issue author and active work owner; confidence: medium)
• samanthamsong: Authored the related open containment epic, which overlaps camera, browser, and command capability policy but not necessarily the requested state model. (role: adjacent containment-work author; confidence: low)

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.
• 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.