OpenClaw's July cloud-session change: the work moved, the session stayed

Published July 16, 2026 · OpenClawBlog Team

If a coding task can run on a throwaway machine, the first operator question is not whether SSH works. It is what remains attached to the session when that machine disappears.

OpenClaw's July record answered that question by separating conversation ownership from execution location. A feature issue opened on July 11 described full agent sessions running on ephemeral machines while remaining visible in the Control UI. A placement and routing PR merged on July 13 supplied the durable machinery behind that idea. Then the v2026.7.2-beta.1 release, published on July 15, listed remote coding sessions and cloud-worker dispatch among its changes.

The practical change was narrower than a new hosted service. OpenClaw gave eligible sessions another place to execute work, while leaving the Gateway responsible for the conversation, routing, credentials, and recovery record.

The event was a placement layer

The July PR described the gap plainly: cloud workers could already run agent turns on ephemeral boxes, but there was no durable record connecting a session to a worker, no dispatch flow, and no recovery path when the Gateway restarted during dispatch.

The PR added those pieces together. It introduced a placement state machine, workspace synchronization, session attachment, one-shot worker turns, dispatch and turn routing, and a session-placement RPC surface with startup reconciliation. That combination matters more than any individual command. The system now had to remember whether a session was local, being provisioned, syncing, active on a worker, draining, or recovering.

Turn admission was also narrowed. The worker was bound to both a sessionId and a runId. In plain terms, a worker could not simply reconnect and start doing work because it still knew the session name. It had to be admitted for the particular run it was asked to execute. The design used atomic admission so local and remote execution would not both own the same turn.

There was an important staging note. The PR itself said it had no user-visible change yet: the RPC existed only when a cloud-worker profile was configured, and the UI and dispatch tool were still to follow. Two days later, the beta release presented remote coding sessions in the Control UI as an operator-facing capability. That sequence separates implementation foundation from a feature that users could begin evaluating.

What stayed with the Gateway

The cloud-session documentation describes a cloud session as an ordinary session whose coding work runs elsewhere. It keeps the transcript in the same conversation surface and leaves the Gateway as the owner of the conversation, reconciled workspace, model credentials, and placement records.

The execution boundary moves, but the control boundary does not. The cloud-workers documentation separates the two sides like this:

This is useful, but it is not a privacy guarantee. Keeping model credentials at the Gateway limits one exposure. The worker still handles source files, command output, and tool results during the task. An operator must trust the worker provider and decide which repository and workspace are safe to send there.

The same distinction applies to availability. The session can remain durable when the remote machine fails, but that does not mean an in-flight model call or command will be replayed transparently. Session durability preserves the place to continue; it does not promise that every active turn completed.

What operators had to add to the runbook

1. Record the destination before dispatch. A cloud worker is not the default Gateway. The documentation says cloud workers are opt-in, and clients hide the Cloud destination until a profile is configured. Keep the profile, repository, branch or source ref, Gateway version, and intended model route with the test record.

2. Track placement, not just the worker process. A running machine is only one part of the state. The authoritative question is whether the Gateway considers the session active on that worker and whether the current run was admitted there. This is the operational consequence of the session-plus-run admission rule.

3. Make workspace movement explicit. The July implementation used Git bundles for Git workspaces and a manifest mirror for plain directories. The parent design described version one as a one-way move from local to worker. Moving back required a stopped session and reconciliation. A local folder should therefore not be treated as instantly identical to the worker copy.

4. Test the restart path before trusting a long job. Startup reconciliation exists because a Gateway restart can happen while a worker is being provisioned or a workspace is syncing. The expected result is one recoverable placement state, not a second worker silently taking the same turn.

Proposed operator check, not a test run for this article: use a disposable repository and a configured cloud profile. Submit one bounded edit, record the session identity and source revision, interrupt the Gateway during dispatch, and inspect the resulting placement after restart. Then verify the transcript, the reconciled change, the absence of a duplicate turn, and the provider-side teardown. This would test the documented contract. It would not prove reliability for every provider or workload.

The limits were part of the story

First, the July feature was a beta capability. The v2026.7.2-beta.1 page labels the release as a pre-release. Operators evaluating it had to treat provider support, workspace transfer, and recovery as things to verify in their own environment.

Second, the design did not promise live movement in both directions. The parent issue listed symmetric live handoff as a later milestone. The first dispatch path used a migration barrier, then required the session to stop and reconcile before it could return to the Gateway. That makes a cloud session closer to a selected execution placement than to a freely movable process.

Third, remote execution did not remove the Gateway as a failure dependency. The July design stated that Gateway loss during an active provider call would fail that call, with no transparent replay. A durable transcript is valuable after recovery, but an operator still needs a policy for unfinished work and partial file changes.

Finally, the change did not alter every OpenClaw installation. The cloud-workers documentation says profiles are opt-in. The practical inference is simple: an operator who only runs sessions on the local Gateway does not need to migrate existing work because of this beta. The people affected first are those running long or parallel coding workloads and those willing to lease or operate separate execution machines.

What July changed

Before this work, the useful mental model was that an agent turn ran on the Gateway host. In July, a session gained a durable execution placement. The conversation could remain in the sidebar while commands and edits ran on an ephemeral worker, with the Gateway deciding who owned the turn and what state survived the machine.

That is the part operators needed to track: where the work runs, which system owns the session, how workspace changes return, and what happens after an interruption. It is a more concrete contract than simply calling something a cloud session. It also leaves the hard questions visible, which is where a useful release note should end.

Sources

All sources were accessed on 2026-09-13. The documentation pages did not show publication dates in the opened records.

1. Cloud workers feature issue #104294, opened 2026-07-11. Defines the proposed ephemeral-session model, Gateway-proxied inference, credential boundary, workspace transfer, and staged milestones.
2. Session placement, dispatch, and worker turn routing PR #106332, merged 2026-07-13. Documents the placement state machine, workspace sync, session-plus-run admission, startup reconciliation, and staged user-facing scope.
3. OpenClaw v2026.7.2-beta.1 release record, published 2026-07-15. Records the pre-release status and the remote coding session and cloud-worker routing changes.
4. OpenClaw Cloud Sessions documentation. Describes Gateway ownership of conversation state and credentials, remote execution, session durability, and placement destinations.
5. OpenClaw Cloud Workers documentation. Describes worker and Gateway responsibilities, opt-in profiles, remote execution modes, and retained session state.