rfc#25: default, pluggable Computer Use with CUA

[RomneyDa]

What Problem This Solves

OpenClaw has now landed a capability-based Computer Use route: the built-in computer tool uses screen.snapshot and the dangerous computer.act node command, macOS fulfills it with embedded Peekaboo, and the bundled cua-computer plugin provides an experimental Windows/Linux CUA fulfiller. The current CUA adapter maps only eight MCP tools to desktop-coordinate actions, so it loses most of CUA's semantic observation, background delivery, browser targeting, verification, session, recording, and skill behavior.

This RFC defines how CUA becomes the default, full-featured provider without replacing the landed route or reimplementing CUA's native driver in OpenClaw.

Design Constraints

1. Keep screen.snapshot + computer.act as the one Gateway-to-node Computer Use route.
2. Keep all native execution, artifacts, prompts, and consent on the selected node, including remote-Gateway setups.
3. Make OpenClaw.app directly spawn CUA embedded mode so macOS TCC remains attributed to OpenClaw.
4. Expand computer.act with versioned typed targets, semantic observations, delivery modes, verification, browser, scope, and recording actions rather than forwarding raw CUA MCP tools.
5. Run the shared CUA adapter in the bundled TypeScript node-host plugin on macOS, Windows, and Linux; keep CUA's native implementation upstream.
6. Make CUA default only when locally ready, keep Peekaboo selectable, and never switch provider silently during an execution.
7. Preserve CUA-derived model guidance while forbidding CLI, shell, generic MCP, native path, installation, and transport bypasses.
8. Keep host lifecycle and maintenance operations node-internal; substantive CUA agent behavior is portable, but all 49 MCP tools do not become public SDK methods.

Why This Change Was Made

The original RFC proposed a dedicated computer.provider.call.v1 route that projected CUA's native MCP catalog through a node-hosted provider runtime. Peter's landed work established a simpler and stronger portable boundary before that proposal could be implemented.

The rewritten RFC therefore:

• treats computer.act as the stable provider boundary and specifies an additive v2 contract;
• defines opaque screen/window/element/browser targets, provider generations, execution sessions, semantic observations, structured verification, and explicit escalation;
• accounts for all 49 published CUA tools, separating model actions from node-owned lifecycle and maintenance;
• reuses the macOS app's existing app-owned TypeScript node worker so one CUA adapter can run cross-platform while the app directly owns the TCC-bearing daemon;
• covers local Gateway-only, remote Gateway, macOS app, Windows companion, Windows/Linux node, and Peekaboo-provider flows;
• breaks implementation into parallel contract, runtime, platform, rich-action, UX/security, and packaged-acceptance waves.

The previous native-MCP proposal and its implementation plan are preserved under rfcs/0025/alternative-node-mcp-approach.md and rfcs/0025/alternative-node-mcp-implementation-plan.md for comparison.

User Impact

No runtime behavior changes with this RFC alone. If accepted and implemented, users receive CUA as the recommended Computer Use provider across supported desktop hosts, OpenClaw-owned macOS permission attribution, richer semantic and browser automation, explicit provider selection, and host-aware setup and diagnostics. Existing v1 nodes and Peekaboo remain supported.

Evidence

• Audited OpenClaw main at a8537805bd9, including the built-in computer tool, node-host plugin registry, macOS native fulfiller, app-owned TypeScript node worker, and bundled CUA plugin.
• Audited CUA main at b8a0f32a06c, the published 0.10 49-tool MCP reference, canonical skill, embedded process model, browser/background contract, permission policy, and generated 14-tool portable manifest.
• Verified every external RFC link returns HTTP 200.
• Verified balanced Markdown fences, all relative links, git diff --check, and byte-for-byte preservation of the previous RFC/plan apart from their explanatory notes and moved relative link.
• Implementation plan: rfcs/0025/implementation-plan.md.

AI-assisted: the architecture and source contracts were researched and the RFC was drafted with Codex; the resulting proposal and tradeoffs were reviewed directly.

[f-trycua]

I reviewed the current head, 43d02c54384a2feb03fb4b2aa515023fca19e239, against Cua Driver 0.10.0. I think two contracts need to change before implementation starts.

1. Add an embedded protected-consent and indicator adapter

The bounded existing-profile flow is incomplete against Cua 0.10.0.

A bounded manifest can pre-approve the exact browser resource, but browser_prepare(strategy=existing_profile) still requires an installed ProtectedConsentProvider. In bounded mode, Cua calls activate_preapproved() to create the persistent Stop-backed indicator lease. An OpenClaw dialog plus a new bounded manifest cannot satisfy that daemon contract by itself.

Please add a Cua upstream prerequisite for an authenticated host adapter over the inherited connection. It should bind the daemon instance, request digest, provider generation, policy hashes, execution lease, Cua session, operation, expiry, and exact browser resource. It also needs indicator activation, deactivation, Stop, and asynchronous revocation.

The manifest restart and the protected provider solve separate problems. Restarting loads the new immutable exact-resource manifest. The provider activates and revokes the persistent indicator after the new daemon starts.

Cua tracker: trycua/cua#2411

2. Destroy broadened authority on every run exit

Exact-profile approval creates a process-level immutable manifest. Calling end_session does not remove that manifest.

Normal completion, failure, cancellation, timeout, node or Gateway disconnect, provider crash, local Stop, and OpenClaw session clear should invoke one idempotent release path that:

1. revokes the browser grant and indicator;
2. ends the injected Cua session and OpenClaw host/policy leases;
3. releases synthetic input and recording ownership;
4. stops or restarts the daemon so the exact-profile manifest disappears;
5. advances provider generation and rejects every capability from the old execution.

Please bind this authority to a unique execution or lease id. A durable OpenClaw chat/session id can survive several agent executions and should not own native authority.

It would also help to separate provider ready from run authorized. Artifact, backend, permissions, private transport, and probes can be ready while no run owns a bounded manifest. Tools become callable only after run authorization succeeds.

Interaction ladder and ownership

The RFC should state Cua's actual verify-then-escalate ladder:

1. get_window_state returns the AX tree and screenshot together.
2. Try an element AX action with background delivery, then re-snapshot and verify.
3. On a concrete PX signal, try an element PX action from that window screenshot, still in background mode.
4. Use the exact browser-page route when the native window can be bound to a browser target, then verify with fresh browser state and refs.
5. Use delivery_mode:"foreground" only when background delivery was shown or reported to be ineffective.
6. In an auto session, call escalate_session only after the window ladder is exhausted. Then use get_desktop_state and desktop/system input for external UI such as permission prompts, file pickers, or authentication sheets.

bring_to_front is a standalone platform-specific tool where exposed. The normal cross-platform foreground transition calls the same action with delivery_mode:"foreground".

The model should select each rung using the version-matched Cua skill. The Gateway should admit or reject the exact model-selected call. It should never encode AX -> PX -> foreground -> desktop, automatically retry a mutation, or maintain a second copy of Cua's element, browser-ref, or capture-scope state.

Suggested RFC wording:

The Gateway does not implement or advance Cua's interaction ladder. It preserves Cua's native schemas and structured outcomes, applies host, execution, resource, and policy admission checks to each model-selected call, and never automatically retries or substitutes another interaction route. Cua enforces its session, capture-scope, reference, delivery, and consent invariants. The model selects the next rung using the version-matched Cua skill.

Live schemas and verdict handling

The reviewed plugin catalog should set the maximum allowed surface. The installed driver's live tools/list schemas should determine which reviewed tools and argument branches exist.

Please reject unsupported semantic branches rather than removing arguments silently. This also needs regression coverage for a schema-supported delivery_mode without an invented capability token, and for bring_to_front remaining a standalone tool rather than an action argument.

The model guidance and tests should preserve this result precedence:

• confirmed: verify the expected state and finish.
• unverifiable: inspect fresh state before deciding whether another mutation is needed.
• suspected_noop, an explicit refusal, or a delivery failure: another rung may be appropriate.
• escalation.recommended: describes a supported next move. It does not prove that the previous mutation failed.

This prevents duplicate clicks, text, submissions, and other side effects.

Platform and resource gates

• Windows readiness must prove that the companion, daemon, proxy, and supported helpers run in the intended interactive user session. Session 0 should report unavailable.
• Managed integrations need host-owned recording, download, upload, replay, and helper paths supplied outside model-visible arguments. Ambient PATH must not select managed helpers such as ffmpeg.
• The OpenClaw skill profile should preserve Cua's workflow and platform guidance while removing CLI bootstrap, daemon management, transport selection, and direct-shell instructions.

Cua upstream trackers

We created four focused Cua issues so this RFC and its implementation plan can depend on explicit upstream contracts:

• trycua/cua#2410: inherited connected IPC for embedded hosts
• trycua/cua#2411: embedded protected-consent and indicator adapter
• trycua/cua#2412: OpenClaw MCP-first skill and capability profile
• trycua/cua#2413: trusted host-owned resource and helper paths

The implementation plan should add the protected-provider work as a separate Wave 0 dependency or include it explicitly in CUA-1. Inherited IPC alone does not make existing-profile attachment available.

With these changes, the responsibility split remains clear: Cua reports native evidence, the model chooses the next action, the Gateway applies host/session/resource/policy admission, and Cua executes while enforcing its own session, delivery, capture-scope, reference, and consent rules.

[RomneyDa]

@f-trycua Thanks — I fully addressed the Cua 0.10.0 contract review in 8f15e2d.

I first verified the underlying Cua contracts at the RFC's pinned 994308a baseline: ProtectedConsentProvider owns indicator activation/deactivation and revocation, bounded mode uses activate_preapproved(), existing-profile attachment refuses without a certified provider, the bounded manifest is loaded as process-level immutable state, the canonical skill defines the ladder/verdicts, live schemas expose delivery_mode, and Windows Session 0 is non-interactive.

Here is exactly how each requested change is covered:

1. Protected consent and indicator adapter is now an independent ship prerequisite. The RFC summary and non-negotiable requirements now require both inherited connected IPC and an authenticated embedded-host ProtectedConsentProvider; they explicitly say the manifest restart and protected-provider activation solve separate problems (RFC lines 26-30, 102-108). The protected control channel is separate from model-facing MCP and bound to the execution lease (671-676).

2. The exact adapter contract is specified. The bounded flow binds schema/nonce/request digest, daemon instance, provider generation, permission mode, policy hashes, execution lease, Cua/transport sessions, operation/risk, expiry, PID/window, browser product, process fingerprint, and endpoint owner. It restarts for the immutable manifest, then requires successful activate_preapproved() before the grant becomes live. Local Stop sends asynchronous revocation; daemon revocation deactivates the indicator; host/channel/session/lease death fails closed (1070-1125).

3. Broadened authority now has one execution-scoped release owner. The RFC no longer treats best-effort end_session as sufficient. Normal completion, failure, cancellation, timeout, node/Gateway disconnect, provider crash, explicit Cua session end, local Stop, OpenClaw session clear, and lease expiry all converge on one idempotent path. It revokes the grant/indicator, ends Cua and OpenClaw leases, releases input/cursor/recording/replay state, stops or restarts the daemon to remove the manifest, advances generation, and rejects old capabilities. Authority is keyed by executionLeaseId, never a durable chat/session id (935-968).

4. Provider ready and run authorized are separate states. The inventory now has provider-level readiness plus an independent runAuthorization; ready normally coexists with inactive authorization, and tools become callable only for a matching execution lease, manifest, policy lease, and generation (412-486). Onboarding and remote selection preserve the same separation (1131-1180).

5. The actual Cua verify-then-escalate ladder and ownership split are explicit. The RFC now specifies tree+screenshot grounding, AX background, PX background on a concrete signal, exact browser-page routing, foreground delivery only after evidence, and explicit auto-session desktop escalation. bring_to_front remains standalone. The Gateway admits/rejects the model-selected call, never advances the ladder, never retries/substitutes a mutation, and never duplicates Cua reference/capture state (848-880).

6. Verdict precedence is preserved. confirmed, unverifiable, suspected_noop/refusal/delivery failure, and escalation.recommended now have the requested precedence, including the explicit warning that a recommendation does not prove the previous mutation failed (882-893).

7. Live schemas determine reviewed branches. The plugin catalog is now only the ceiling; the installed driver's live tools/list decides which reviewed tools and semantic branches exist. Unsupported branches are rejected rather than silently stripped. A schema-supported delivery_mode needs no invented capability token (412-421, 735-740). The implementation plan requires recorded live-schema fixtures for delivery_mode, standalone bring_to_front, verdict precedence, and no Gateway ladder advancement (plan lines 282-305).

8. Platform/resource/profile gates are explicit. Windows readiness must prove the companion, daemon, proxy, and helpers are in the intended interactive user session; Session 0 is unavailable (621-627). Recording, download, upload, replay, output, and helper paths are host-owned; ambient PATH cannot select helpers (746-770). The Cua skill work preserves workflow/platform guidance while removing CLI/bootstrap, daemon, transport-selection, and shell instructions (plan lines 141-166).

9. The implementation plan now carries the dependencies and proof. New Wave 0 item CUA-4 tracks trycua/cua#2411, defines the protected adapter and replay/Stop/deactivation tests, and joins CUA-1 on the critical path (plan lines 104-139). The graph and contract freeze now include CUA-4, ready-vs-authorized state, live schemas, verdict handling, execution identity, and the idempotent release path (plan lines 32-78). Linux, macOS, Windows, security, packaging, and model-parity waves all consume and prove those contracts.

10. All four upstream trackers are linked from the RFC and plan. #2410 inherited IPC, #2411 protected consent/indicator, #2412 OpenClaw MCP-first profile, and #2413 trusted host resources/helpers are now explicit dependencies (RFC lines 1518-1528).

The acceptance matrix now directly tests ready-without-authorization, execution identity, protected activation/revocation, every release trigger, live-schema behavior, standalone bring_to_front, no automatic mutation retry, Windows Session 0, and managed helper/resource paths (RFC lines 1348-1409). Validation passed: git diff --check, balanced Markdown fences, relative-link resolution, and live checks for all four Cua tracker URLs.

[RomneyDa]

Rewrote RFC 0025 in 7697219 around the architecture that has now landed in OpenClaw.

The primary decision is to keep the built-in computer tool and screen.snapshot + computer.act node route, then evolve computer.act additively with typed window/element/browser targets, semantic observations, delivery modes, structured verification, provider generations, execution-scoped CUA sessions, recording, and explicit escalation. The bundled CUA plugin remains the adapter and model-guidance owner; OpenClaw.app directly spawns the TCC-bearing embedded CUA daemon while its existing app-owned TypeScript node worker runs the shared adapter.

The rewrite also adds explicit local-Gateway, remote-Gateway, Windows companion, Linux, macOS, Peekaboo-selection, artifact, resource, protected-browser, onboarding, security, and packaged-acceptance flows. All 49 published CUA MCP tools are accounted for without making host maintenance operations public model actions.

The previous native-MCP provider proposal is preserved for comparison in rfcs/0025/alternative-node-mcp-approach.md, with its former plan in rfcs/0025/alternative-node-mcp-implementation-plan.md. The new parallelized plan is rfcs/0025/implementation-plan.md.

Validation: git diff --check; balanced Markdown fences; all relative links resolve; all external links returned HTTP 200; preserved alternative content matches the prior RFC/plan apart from its note and moved relative link.

[f-trycua]

CUA sessionized authorization follow-up

Following the latest RFC rewrite, we are refining CUA's permission model so
authorization belongs to an immutable session rather than the lifetime of a
whole daemon or runtime.

The proposed CUA model is:

runtime authorization ceiling
    ∩
immutable authorization session
    ∩
managed policy
    ∩
user policy
    =
effective authority for each call

A trusted host creates the authorization session and receives an action object
or connection already bound to it. The model cannot create, select, or widen
the mode through start_session, computer.act, MCP metadata, a public session
string, an environment value, or a reconnect token.

Existing CUA callers keep their current behavior through a compatibility
session. The new API is additive. Our first supported mixed-mode topology will
be a direct SDK host:

CuaDriver runtime with an explicit ceiling
  ├── standard CuaDriverSession
  ├── bounded CuaDriverSession with its own immutable manifest
  └── unrestricted CuaDriverSession

Each session owns its grants, browser bindings, manifest, expiry, revocation,
and cleanup. unrestricted skips CUA approval prompts but continues to obey
managed policy, user policy, OS permissions, hard denials, and resource
isolation.

This seems compatible with the RFC's statement that each OpenClaw execution
owns one CUA session that the model cannot name or reuse. I think the RFC should
distinguish two CUA concepts:

• the existing public activity-session label used for capture, recording,
  cursor, and lifecycle grouping;
• the new authorization session created by the trusted host and bound to the
  action channel.

Knowledge of the activity-session label never grants the authorization
session.

Could you review whether the following mapping checks the boxes for OpenClaw?

1. OpenClaw.app or its trusted node host owns the CUA runtime ceiling and the
   host-only authorization-session factory.
2. One executionLeaseId maps to one CUA authorization session. The model
   receives only the already-bound Computer Use action surface.
3. The requested mode is immutable for that execution. Changing modes requires
   ending the old authorization session and creating a new one.
4. OpenClaw's Gateway policy remains an independent ceiling. An unrestricted
   CUA session cannot override a Gateway, managed-policy, or user-policy denial.
5. Normal completion, cancellation, timeout, disconnect, local Stop, policy
   change, and provider restart close the authorization session and revoke its
   grants and resources.
6. A reconnect cannot recover the old authority from an execution ID, public
   session string, socket path, or serialized token.
7. Bounded policy content is copied into an immutable per-session manifest at
   creation. It does not remain daemon-global.
8. No permission-mode selector is added to computer.act, CUA
   start_session, or another model-facing schema.

There is one topology question we would especially like your review on. The
first CUA implementation will support mixed modes through the direct SDK,
where an in-memory session object is the authority binding. A shared daemon,
embedded MCP proxy, or remote service needs an authenticated accepted action
connection before it can offer the same property. A private socket plus an
injected session string is insufficient for mixed-mode authority.

If OpenClaw keeps one bounded compatibility-mode daemon per execution, it does
not need mixed-mode delegation for that first release. If it wants one CUA
runtime to serve executions with different modes, either the app/node must own
the direct SDK runtime or inherited/authenticated action-channel work must join
the critical path.

Current CUA tracking:

• trycua/cua#2542: canonical
  authorization at native dispatch;
• trycua/cua#2545: draft
  authorization-session foundation;
• trycua/cua#2437: trusted
  per-session permission modes;
• trycua/cua#2550: draft RFC for the
  SDK-owned runtime and transport-independent authorization model;
• trycua/cua#2410: inherited
  connected IPC for embedded hosts.

The foundation and RFC are still under review, and the direct SDK session API
has not shipped. We would like to confirm the OpenClaw mapping now so both
projects implement the same execution, authority, and teardown boundaries.

[clawsweeper]

Codex review: found issues before merge. Reviewed July 31, 2026, 12:05 AM ET / 04:05 UTC.

ClawSweeper review

What this changes

Adds RFC 0025 and a phased plan for making CUA a selectable default Computer Use provider while retaining OpenClaw’s existing screen snapshot and node action route.

Merge readiness

⚠️ Ready for maintainer review - 6 items remain

Keep open for maintainer review. This member-authored RFC proposes a new default Computer Use provider and now needs its security-sensitive authority topology reconciled with the July 30 CUA update before acceptance. Likely related people: RomneyDa (high confidence) for the RFC direction, and f-trycua (medium confidence) for the upstream CUA contract boundary.

Priority: P3
Reviewed head: 191852340455ac8262d20ab39c16be29b2ed1d26
Owner decision: Required. See Decision needed.

Review scores

Measure	Result	What it means
Overall readiness	🦐 gold shrimp (3/6)	The RFC is substantial and internally scoped, but its central upstream authorization premise needs an explicit update before maintainers can safely accept the roadmap.
Proof confidence	🌊 off-meta tidepool	Not applicable: This member-authored RFC changes planning documents rather than runnable behavior, so external contributor runtime proof is not the applicable gate.
Patch quality	🦐 gold shrimp (3/6)	Security review found an item that needs attention.

Verification

Check	Result	Evidence
Real behavior	Not applicable	Not applicable: This member-authored RFC changes planning documents rather than runnable behavior, so external contributor runtime proof is not the applicable gate.
Evidence reviewed	3 items	Proposed scope: The branch adds two RFC documents totaling 1,780 lines and explicitly states that no runtime behavior changes with this RFC alone; it is a product and architecture decision rather than a completed implementation. Upstream contract changed after the RFC baseline: The RFC body identifies a CUA 0.10-era audit baseline, while the July 30 discussion reports shipped CUA 0.14.1 support for SDK-owned runtimes and trusted immutable sessions and requests a topology update before re-review. Member-authored item requires human judgment: The item author is a repository MEMBER and is assigned in the timeline, so conservative cleanup policy keeps the RFC open for explicit maintainer direction rather than auto-closing it.
Findings	1 actionable finding	[P1] Update the RFC for CUA’s shipped authorization topology
Security	Needs attention	Reconcile execution authority with the shipped CUA session model: A default provider design must ensure that grants, permission mode, revocation, and cleanup are bound to a trusted execution session rather than a reusable transport or durable identifier; the later upstream update says that this contract is now available but the RFC has not incorporated it.

How this fits together

OpenClaw’s built-in Computer Use tool sends snapshots and approved actions through the Gateway to a selected desktop node. That node chooses a local provider such as CUA or Peekaboo, which performs native desktop actions and returns observations, verification, and artifacts.

flowchart LR
  Model[Agent model] --> Tool[Built-in Computer Use tool]
  Tool --> Gateway[Gateway policy and routing]
  Gateway --> Node[Selected desktop node]
  Node --> Provider[CUA or Peekaboo provider]
  Provider --> Desktop[Native desktop and browser]
  Provider --> Result[Observations and verification]
  Result --> Gateway
  Gateway --> Model

Loading

Decision needed

Question	Recommendation
Should this RFC adopt CUA 0.14.1’s SDK-owned or privately supervised execution-bound session topology before OpenClaw accepts CUA as the default provider roadmap?	Update then review: Revise the RFC and phased plan around the shipped trusted-session topology, then request maintainer review of the explicit SDK-versus-private-worker choice.

Why: The choice determines the permanent provider boundary, authority lifecycle, compatibility posture, and security guarantees; it cannot be resolved by a mechanical documentation edit alone.

Before merge

• Update the RFC for CUA’s shipped authorization topology (P1) - The RFC remains grounded in a CUA 0.10-era consent and transport design, but the July 30 upstream update reports shipped SDK-owned, immutable trusted sessions. Before this becomes the default-provider roadmap, revise the authority, teardown, and topology sections so the documented security boundary matches the supported CUA contract.
• Resolve security concern: Reconcile execution authority with the shipped CUA session model - A default provider design must ensure that grants, permission mode, revocation, and cleanup are bound to a trusted execution session rather than a reusable transport or durable identifier; the later upstream update says that this contract is now available but the RFC has not incorporated it.
• Resolve merge risk (P1) - Accepting the RFC without updating its CUA 0.10-era assumptions could retain a legacy authority and teardown topology when CUA now offers SDK-owned, execution-bound sessions.
• Resolve merge risk (P1) - The proposed default-provider cutover affects existing v1 nodes and Peekaboo selection, so compatibility and upgrade behavior need explicit maintainer agreement before implementation begins.
• Complete next step (P2) - A maintainer must choose the permanent CUA authority topology and compatibility posture; this is not a safe mechanical repair lane.

Findings

• [P1] Update the RFC for CUA’s shipped authorization topology — rfcs/0025-default-pluggable-computer-use.md:26-30
• [medium] Reconcile execution authority with the shipped CUA session model — rfcs/0025-default-pluggable-computer-use.md:26

Agent review details

Security

Needs attention: The RFC documents a native-action authorization boundary whose upstream topology has materially changed, so the security design needs reconciliation before acceptance.

Review metrics

Metric	Value	Why it matters
RFC surface	2 added files; 1,780 lines added	The proposal and its delivery plan are large enough that the outstanding topology decision affects both documents.
Runtime changes	0 implementation files changed	This branch establishes direction only, so acceptance should be based on architecture and upgrade safety rather than test status.

Merge-risk options

Maintainer options:

1. Refresh the authority design before acceptance (recommended)
   Update the RFC to use the shipped trusted-session model and show how existing v1 nodes and Peekaboo remain compatible during rollout.
2. Accept the legacy integration obligations
   Maintainers may retain the earlier topology, but should explicitly own its consent, transport, teardown, and upgrade requirements.
3. Pause the default-provider roadmap
   Defer this RFC if maintainers do not yet want to choose a permanent CUA authority boundary.

Technical review

Best possible solution:

Update the RFC and implementation plan to choose a direct SDK or private-worker CUA topology, bind one trusted CUA session to each execution lease, and retain explicit v1-node and Peekaboo compatibility before maintainers decide whether to adopt the roadmap.

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

Not applicable: this is a design RFC, not a report of a currently failing runtime behavior.

Is this the best way to solve the issue?

Unclear: retaining the existing Gateway-to-node route is a focused direction, but the documented CUA authority topology predates the shipped upstream trusted-session design and should be revised before approval.

Full review comments:

• [P1] Update the RFC for CUA’s shipped authorization topology — rfcs/0025-default-pluggable-computer-use.md:26-30
  The RFC remains grounded in a CUA 0.10-era consent and transport design, but the July 30 upstream update reports shipped SDK-owned, immutable trusted sessions. Before this becomes the default-provider roadmap, revise the authority, teardown, and topology sections so the documented security boundary matches the supported CUA contract.
  Confidence: 0.9

Overall correctness: patch is incorrect
Overall confidence: 0.9

AGENTS.md: unclear because the file could not be read completely.

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

Labels

Label justifications:

• P3: This is a forward-looking RFC with no immediate runtime change, despite its potentially broad future scope.
• merge-risk: 🚨 compatibility: The RFC changes the intended default provider while promising v1-node and Peekaboo continuity, which requires an explicit upgrade contract.
• merge-risk: 🚨 security-boundary: The unresolved CUA session and authorization topology controls native-action authority, grants, and teardown.
• rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🌊 off-meta tidepool and patch quality is 🦐 gold shrimp.
• status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Not applicable: This member-authored RFC changes planning documents rather than runnable behavior, so external contributor runtime proof is not the applicable gate.

Evidence

Security concerns:

• [medium] Reconcile execution authority with the shipped CUA session model — rfcs/0025-default-pluggable-computer-use.md:26
  A default provider design must ensure that grants, permission mode, revocation, and cleanup are bound to a trusted execution session rather than a reusable transport or durable identifier; the later upstream update says that this contract is now available but the RFC has not incorporated it.
  Confidence: 0.9

What I checked:

• Proposed scope: The branch adds two RFC documents totaling 1,780 lines and explicitly states that no runtime behavior changes with this RFC alone; it is a product and architecture decision rather than a completed implementation. (rfcs/0025-default-pluggable-computer-use.md:1, 191852340455)
• Upstream contract changed after the RFC baseline: The RFC body identifies a CUA 0.10-era audit baseline, while the July 30 discussion reports shipped CUA 0.14.1 support for SDK-owned runtimes and trusted immutable sessions and requests a topology update before re-review. (rfcs/0025-default-pluggable-computer-use.md:26, 191852340455)
• Member-authored item requires human judgment: The item author is a repository MEMBER and is assigned in the timeline, so conservative cleanup policy keeps the RFC open for explicit maintainer direction rather than auto-closing it. (191852340455)

Likely related people:

• RomneyDa: Authored all seven commits on this RFC branch, including the redesign around the existing computer action route, and is assigned to the item. (role: RFC author and assigned design owner; confidence: high; commits: 769721948ea9, 191852340455; files: rfcs/0025-default-pluggable-computer-use.md, rfcs/0025/implementation-plan.md)
• f-trycua: Provided the detailed CUA contract review and the subsequent shipped-topology update that the RFC now needs to reconcile. (role: upstream integration reviewer; confidence: medium; files: rfcs/0025-default-pluggable-computer-use.md)

Rank-up moves

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

• Update the RFC and implementation plan for CUA 0.14.1’s execution-bound session model.
• Ask maintainers to select the intended direct-SDK or private-worker provider topology.

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 (5 earlier review cycles)

• reviewed 2026-07-29T21:19:14.297Z sha 1918523 :: needs maintainer review before merge. :: none
• reviewed 2026-07-30T08:38:12.368Z sha 1918523 :: needs maintainer review before merge. :: none
• reviewed 2026-07-30T14:34:44.818Z sha 1918523 :: needs maintainer review before merge. :: none
• reviewed 2026-07-30T15:30:23.954Z sha 1918523 :: needs maintainer review before merge. :: none
• reviewed 2026-07-30T19:00:53.605Z sha 1918523 :: needs maintainer review before merge. :: none

[f-trycua]

Thanks for the review. One premise has changed since this was posted: the Cua authorization topology is now shipped.

Cua Driver 0.14.1 includes:

• SDK-owned same-process runtimes and directly supervised private workers
• an immutable runtime authorization ceiling
• trusted, immutable session permission modes
• connection-bound session action surfaces
• multiple isolated runtimes and sessions
• trusted SDK authorization-host callbacks
• runtime and session-scoped grant coordination and teardown

The recommended OpenClaw mapping is now:

OpenClaw trusted node host
  -> Cua SDK-owned runtime ceiling
    -> one trusted Cua session per executionLeaseId
      -> an already-bound action surface exposed through OpenClaw's provider

The model should not choose Cua's permission mode, runtime, transport, native session identifier, or resource paths. The public Cua session label is only for display and lifecycle correlation. OpenClaw should use the direct SDK runtime by default, or a private worker when process and crash isolation are required.

Relevant shipped work:

• trycua/cua#2561, SDK-owned runtime RFC implementation
• trycua/cua#2575, multiple direct runtimes
• trycua/cua#2577, resource-grant coordination
• trycua/cua#2578, trusted SDK authorization host
• trycua/cua#2616, simplified permission and session identity contract

Two focused Cua integration items remain and are being addressed:

• trycua/cua#2412, an OpenClaw MCP-first skill profile that removes CLI and transport selection from model guidance
• trycua/cua#2413, trusted host-owned resource and helper bindings

Could the RFC now:

1. update its Cua baseline from 0.10 to 0.14.1;
2. select direct SDK or private worker as the Cua provider topology;
3. map one executionLeaseId to one trusted Cua session;
4. remove the old dependency on a Cua-owned modal, persistent banner, and inherited socket transport;
5. keep v1 node and Peekaboo compatibility as an OpenClaw provider decision; and
6. rerun @clawsweeper re-review after those edits?

That should resolve the topology blocker while keeping OpenClaw's Gateway policy as the outer authority ceiling.

[f-trycua]

The Cua-side implementation discussed above is now ready for review in trycua/cua#2702, with the complete macOS, Windows, Linux, generated-binding, docs, and Nix CI matrix green.

The provider-facing contract now includes:

• an exact-version, digest-bound OpenClaw operating profile and companion resources;
• a live tool inventory check for every documented action and escalation branch;
• one SDK-owned, authorization-bound session for embedded, private-worker, or authenticated-service hosting;
• host-owned recording roots, download roots, staged uploads, replay artifacts, and recording helper selection;
• a dedicated trusted-host authorization bit for existing logged-in Chromium profile attachment;
• sanitization and redaction that prevent model arguments from choosing native paths or forging reserved approval fields; and
• explicit documentation that the model must receive only the bound session surface, never the unbound driver escape hatch.

Could the OpenClaw maintainers review whether this now satisfies the RFC's Cua provider, resource-policy, and authorization-boundary requirements? The remaining ffprobe and completed-recording render helper is intentionally tracked separately in trycua/cua#2413 and is not required for ordinary action dispatch or recording capture.