OpenClaw Main Adds Shared Browsers and Nested Cloud Sessions

OpenClaw’s experimental Cloud Worker Desktop has moved beyond passive observation. A merged main feature adds provider-attested Browser and Terminal launchers, and lets the worker’s agent use the same visible, lease-scoped browser that an operator can watch and control.

That is genuinely useful for debugging browser work. It also turns one remote desktop into a shared authority surface: agent tools, operator input, browser state and cloud-workspace custody can now meet on the same disposable machine.

Availability: this remains an opt-in Labs path on main. The reviewed evidence does not identify a containing stable package. Windows Gateway hosts do not support Desktop observe and app launch.

One browser, two actors

PR #121475 extends a desktop-capable Crabbox lease with an advertised closed set of apps. The official docs say the Browser launcher starts one visible Chrome or Chromium process on the worker display, with raw CDP bound to loopback and a fresh lease-scoped user-data directory.

The operator toolbar and the cloud-worker agent share that process. An agent receives the ordinary browser tool only when all of these remain true:

• the lease advertises Browser capability;
• the bundled Browser plugin is active; and
• ordinary tool policy allows browser for that turn.

The feature does not import cookies, attach the Chrome extension relay or use Chrome MCP. Provider credentials and model inference remain Gateway-side under the existing cloud-worker architecture.

Interpretation: visibility improves auditability, but seeing a browser is not equivalent to controlling its policy. A human can race an agent, mutate page state between snapshots or submit a form the agent only prepared. Operating procedures need an explicit handoff.

Launchers are provider-attested

The Control UI shows only apps reported by the worker provider and launches them through the Gateway-owned worker desktop method. That is better than accepting an arbitrary UI command, but it still grants significant capability to anyone with the required administrative scope.

Connections begin view-only. Taking control creates one active controller; another take-control request displaces the previous controller. The VNC path stays behind the Gateway’s pinned SSH transport rather than opening a worker-network listener.

PR #121671 repairs the browser-session recovery scope for trusted-proxy and other authorised Control UI sessions. Operators behind an identity-aware proxy should include this in acceptance testing: cloud recovery must be bound to Gateway-issued principal scope, not credentials a browser can inspect or derive.

Workspace scale changed too

PR #121262 expands cloud-workspace transport for large Git repositories. That removes a practical blocker, but larger workspaces increase sync time, reconciliation complexity and the amount of source available to the leased machine.

Do not infer that “ephemeral” means “no custody.” The worker has the workspace while the lease is active, and the Gateway later adopts commits and reconciles results.

Cloud sessions can delegate to cloud children

PR #121846 extends cloud sessions so they can spawn and message cloud child sessions when the parent has the required placement and delegation authority. A cloud worker is no longer necessarily a leaf in the task graph.

The important boundary is inherited placement, not a child choosing its own provider. The Gateway must preserve the parent cloud context, workspace custody and requester identity while creating the child. Messaging between those sessions also needs the same delegated authority that admitted the relationship; a visible session ID is not permission to contact it.

This amplifies both utility and cost. One remote turn can now fan out into several leased workers, each with workspace and model usage. Operators should set concurrency, budget and teardown expectations before enabling nested cloud work.

Rollout checklist

Use a disposable repository and non-production accounts:

1. leave Cloud Worker Desktop disabled until the operator role and lease provider are reviewed;
2. enable cloudWorkers.desktop and the profile’s settings.desktop only on a test profile, then provision a fresh lease;
3. verify Browser and Terminal appear only when the provider advertises them;
4. confirm VNC and CDP remain loopback/tunnel-only from the worker network;
5. allow browser for one test agent, open a harmless page and prove the operator and agent see the same tab;
6. pause human input during an agent action, then test an explicit handoff in both directions;
7. revoke browser-tool policy mid-lifecycle and require the next turn to lose browser authority;
8. restart the Gateway behind the real trusted proxy and prove cloud recovery stays with the same authenticated principal; and
9. spawn one cloud child from a cloud parent and verify placement, requester identity and workspace scope cannot be widened by child input;
10. reject a direct message from an unrelated session that merely knows the child ID;
11. exercise concurrency and budget limits with synthetic work; and
12. terminate the leases and confirm desktop, browser, tunnels, child messaging and recovery handles become unusable.

Never validate shared-browser control against email, banking, cloud consoles or production admin sessions.

Bottom line

The shared visible browser makes remote agent work less opaque, while nested cloud sessions make it more scalable. Both increase authority on leased machines. Roll them out only with one-controller rules, current tool-policy checks, explicit placement limits, bounded fan-out, tunnel-only exposure and tested recursive teardown.