OpenClaw cloud workers

Cloud workers move a session’s coding work onto a throwaway cloud machine while the session stays visible in the sidebar and its transcript remains owned by the Gateway. The bundled Crabbox provider boots the box, runs the profile setup, and enrolls it as an ephemeral node; one configured profile supports both OpenClaw worker turns and Codex remote execution over the same enrolled transport. The feature is opt-in: until a profile exists, clients hide the Cloud destination. Here is what runs where, how enrollment and cleanup stay replay-safe, the requirements, the profile, and the proxy rules.

What runs where

• In OpenClaw worker-turn mode the agent runtime and turn loop run on the cloud box in a restricted worker child, command, filesystem and HTTP work happen on the box, model inference and provider auth stay on the Gateway proxied by a provider and model reference, and the transcript is fed by the worker’s replayable event stream.
• In Codex remote-exec mode the app server and the turn loop stay on the Gateway with its model authentication, including a ChatGPT subscription, while commands run on the cloud node, a paired device, or an SSH-backed provider.
• In both modes workspace files change remotely and the Gateway reconciles them; the cloud node dials the Gateway’s public TLS endpoint over an outbound WebSocket, and worker control and workspace transfer use authenticated channels rather than a reverse tunnel or rsync.
• A cloud session can start from a GitHub repository URL and optional ref with no Gateway checkout: the node fetches the repository, pins the resolved commit and creates the session branch, while the Gateway keeps source metadata and immutable checkpoints of accepted changes; sessions from an existing checkout keep their managed-worktree mirror.

When the work is done (or the box dies), the machine is discarded. The transcript, accepted workspace changes, and placement records remain with the Gateway.

Enrollment and cleanup

Enrollment is environment-owned and replay-safe: the Gateway persists one setup identity before node enrollment, binds the first authenticated device identity to that exact environment, and reuses the durable device token when provisioning resumes. Reclaim or destroy releases the cloud lease and removes the environment-owned node pairing, and if provisioning fails before returning a lease, cleanup resolves the original operation’s handle without rerunning provisioning, setup or enrollment, completing only once the provider confirms release or absence. A missing setup value or a provider refusal does not prove an earlier attempt allocated nothing, so those failures stay retryable under the original operation identity. Worker-turn sessions can also open portals on node-backed workers through single-use tickets redeemed over a pinned WebSocket, preserving the Control UI portal experience without inbound ports.

Requirements and the profile

• A worker provider plugin, the bundled one driving the Crabbox CLI, which owns the supported cloud backends; a supported Node release and npm on the leased machine, since OpenClaw does not install Node; the GitHub CLI on the worker path for GitHub commands; and a repository session or a live managed worktree, never an arbitrary plain directory. For AWS workers the instance profile must be empty, checked before allocation.
• Profiles are managed under the connections settings in the Control UI or under the cloud-workers key in the config, writing the same keys: a provider id, an install preference, an optional suspend-after idle duration with a one-minute minimum where a suspended worker bills only snapshot storage, and provider settings with the backend, a required machine class, an operating system target that defaults to Linux and can be Windows via WSL2, native Windows or macOS, a lifetime, an idle timeout, an optional idempotent setup script, an optional desktop, and a binary path.
• Warm images capture a prepared project and node runtime before enrollment so later workers for that project start from the image; Linux only, enabled by default when a class is known, paired with suspend-after so suspended sessions wake warm, and billed as provider snapshot storage. Crabbox credentials stay in Crabbox’s own configuration for the Gateway user, never in profile settings.

OpenClaw sandboxing explained is the local answer to the same blast-radius question, and OpenClaw nodes, remote hands the peripheral model that cloud workers reuse.

The proxy rules

For a loopback Gateway behind public HTTPS ingress, the public origin setting must be the proxy’s bare origin, cloud dispatch refuses loopback, link-local or unspecified Gateway addresses before allocating a machine, and any reverse proxy in front, cloudflared, nginx or a managed Tailscale Serve, must be listed among the trusted proxies or node enrollment fails with a proxy-attribution error. The proxy must also forward the worker-bootstrap artifact route with the authorization header intact, because a new node downloads its runtime over that authenticated route before it can connect. OpenClaw sessions explains the session that stays with the Gateway throughout, and The OpenClaw Gateway explained the process that owns it.

On Diali

On Diali the instance itself is the disposable-safe box: it runs the agent loop, keeps the workspace on a persistent volume, and is replaced on every release; cloud workers are a self-run feature with no equivalent here yet. Hosted OpenClaw on Diali is the assistant and Diali security describes the boundary.

• The box is throwaway; the transcript is not.
• Worker turns run the loop on the box; Codex keeps it on the Gateway.
• Opt-in, one profile, credentials in Crabbox.