OpenClaw cloud sessions let a session run its coding work somewhere else without becoming a different conversation. The Gateway keeps the transcript, model credentials, placement record, and reconciled workspace. A paired device or cloud worker does the commands and edits. That split matters when a task needs more capacity, a different machine, or a tighter isolation boundary, but you still want one durable session to own the work.
The feature is a better fit for long-running coding work than treating a remote machine as a second, disconnected agent. It also gives operators a clear recovery model: the session stays with the Gateway even if a disposable worker is reclaimed.
In this guide
- What OpenClaw cloud sessions are
- Where a session can run
- What stays on the Gateway
- A practical dispatch checklist
- Failure and recovery boundaries
- FAQ
What OpenClaw cloud sessions are
OpenClaw cloud sessions separate the conversation from the machine that performs the work. In the official cloud sessions documentation, a cloud session is an ordinary session whose coding work runs remotely while the Gateway remains the owner of the conversation and durable state.
That is different from copying a prompt into a VPS and hoping the result makes it back. The remote placement is part of the same session: it remains visible in the sidebar, streams progress into chat, and reconciles completed workspace changes into the managed worktree owned by the Gateway.
OpenClaw v2026.8.1 made this model more explicit with paired-device and cloud-worker placements, workspace moves, warm machines, and project seeds for later sessions. The release notes describe the product behavior; the docs explain the operational boundary underneath it.
Where a session can run
A session uses the same conversation and placement control, but the destination changes the operating tradeoff.
| Destination | Best use | What changes |
|---|---|---|
| Gateway | Everyday work near the host | Commands and files run on the Gateway machine |
| Paired device | A spare Mac, build machine, or server you already own | Work runs on that connected device and can wait for it to return |
| Cloud worker | Burst capacity, long jobs, or disposable execution | Work runs on an on-demand worker that is reclaimed after the session stops |
A paired device is useful when you own a machine with the right environment already installed. The cloud-session docs show the opt-in path as openclaw connect <join-url> --service --session-host. It exposes worker capacity to the Gateway without turning that device into a second Gateway.
Cloud workers have a different job. The bundled Crabbox provider provisions a throwaway machine, runs profile setup, enrolls it as a temporary node, and removes it at the end of the session. The cloud workers reference is clear on the design: the worker is disposable, while the transcript, placement records, and last reconciled workspace live with the Gateway.
If you are deciding between a managed always-on agent and operating your own infrastructure, compare OpenClaw Cloud and self-hosting. For the broader model of how a Gateway coordinates sessions and connected surfaces, start with How OpenClaw works.
What stays on the Gateway
The useful security and recovery property of OpenClaw cloud sessions is that the remote host does not become the long-term source of truth.
The Gateway retains:
- the canonical transcript and session identity
- provider credentials and model authentication
- the last reconciled workspace and placement history
- the policy boundary that governs the session
- the result needed to resume or redispatch work
The remote machine receives the work it needs to perform. For cloud placements, model inference stays proxied through the Gateway, so provider credentials do not need to live on the cloud worker. When the work is complete, the worker’s changes reconcile into the managed worktree.
This is also why a cloud worker is not a shortcut for running arbitrary local directories remotely. The worker docs require a live, registry-owned session managed worktree. OpenClaw’s managed worktrees documentation explains why: each agent task gets a recorded Git checkout and branch outside the source repository, which makes reconciliation and recovery tractable.
That division gives you a concrete rule: choose a remote placement for execution capacity or isolation, not because you want a second place for durable credentials and state.
A practical dispatch checklist
Before moving a session off the Gateway, verify the placement rather than treating remote execution as an invisible implementation detail.
- Choose the right destination. Use a paired device when the existing machine and its environment are the advantage. Use a cloud worker when the task benefits from disposable capacity or isolation.
- Confirm the worktree is managed. Cloud dispatch expects a session-managed worktree, not an arbitrary folder. That is the anchor for workspace reconciliation.
- Check the worker prerequisites. Cloud worker images need a supported Node.js version, npm, registry access, and any tools your setup command needs. If GitHub operations are in scope, the official docs call out
ghon the worker path. - Verify the Gateway is publicly reachable where needed. A cloud node enrolls back to the Gateway over an authenticated outbound connection. A reverse proxy needs the documented public origin, trusted-proxy configuration, and bootstrap route forwarding.
- Watch the placement and result. Keep the session visible through the Control UI and inspect conflicts rather than retrying blindly. A finished turn can have reconciled non-conflicting edits while retaining a local version for a conflicted path.
For teams that already use a long-lived Gateway plus an interactive coding surface, OpenClaw Attach is the adjacent pattern. Attach keeps a coding harness on the existing Gateway session. Cloud sessions decide where that session’s execution happens.
Failure and recovery boundaries
Cloud sessions are designed around the idea that placement can fail without deleting the session. That does not mean every failure is automatic or lossless.
A reclaimed or idle-suspended cloud worker can be replaced on the next message. The Gateway uses the reconciled workspace and retains the transcript. A failed placement, by contrast, exposes its diagnostic and requires cleanup before an explicit redispatch. The distinction is useful: it prevents an opaque retry from creating two competing remote environments.
Paired devices behave differently. If a paired device goes offline, the placement stays associated with that device and waits for it to reconnect. Operators can continue on the Gateway from the last synchronized workspace, but edits made on the device after the latest reconciliation are the loss window. That is a real tradeoff, not a detail to bury in a retry message.
The same caution applies to attachments. OpenClaw can stage images and PDFs for remote work, but the docs set explicit file and transfer limits and preserve the canonical transcript references at the Gateway. Treat those limits as part of the workflow design when a job depends on large media assets.
When cloud sessions are worth the extra setup
OpenClaw cloud sessions are worth the setup when session continuity matters as much as compute location. A disposable worker is useful for a long build, a resource-heavy coding task, or a job that should not run beside your personal environment. A paired device is useful when an existing build box already has the right tools and repositories.
They are a poor fit for a task that does not need remote execution or for a workflow that has no managed workspace to reconcile. In those cases, a normal Gateway session is simpler and has fewer moving parts.
The practical gain is not “run an agent in the cloud.” It is moving execution while preserving the state that makes a session worth resuming.
FAQ
Are OpenClaw cloud sessions a separate type of conversation?
No. A cloud session is an ordinary OpenClaw session with a remote execution placement. The Gateway retains the transcript and session identity while the remote destination performs the coding work.
Do cloud workers receive model-provider credentials?
No. The cloud-sessions docs state that model inference remains proxied through the Gateway, so provider credentials stay on the Gateway rather than the remote worker.
What happens if a cloud worker stops?
After a clean reclaim or idle suspension, the next message can provision a replacement. A failed placement keeps its diagnostic visible and needs cleanup plus explicit redispatch.
Can I use my own machine instead of a cloud worker?
Yes. Pair a device and opt it into session hosting. That works well for a spare Mac, a build server, or another machine you already control.
Sources: OpenClaw cloud sessions · OpenClaw cloud workers · Managed worktrees · OpenClaw v2026.8.1 release notes