The session is not a browser tab

The 2026.8.1 release connects three changes. Sessions can run on paired devices or cloud workers. Their workspaces can move with them. Durable progress cards survive reloads and show subagent activity and accumulating edits.

OpenClaw's session attachment documentation supplies the underlying model. The Gateway owns session rows, transcript history, routing metadata, and active runs. The Control UI, mobile clients, ACP, openclaw tui, and openclaw attach show or update that state; they do not keep independent copies.

Calling this “sync” understates the design. Sync suggests several peers reconciling local truth. OpenClaw has one session owner and several views. A terminal attachment does not clone the transcript. A phone does not become another owner. The Gateway resolves the session key and applies its access rules.

That eliminates the awkward ritual of exporting context from one client and rebuilding it elsewhere. It also concentrates failure and trust. A stale, unreachable, misconfigured, or broadly authenticated Gateway affects every client connected to it.

A handoff exchanges authority

The terminal continuation path keeps credentials out of the copied command. The Control UI produces an opaque handoff argument containing the exact session key and Gateway WebSocket URL. The terminal authenticates independently, and the Gateway canonicalizes the key before attaching. If the session is missing, the command provides recovery guidance instead of silently creating a replacement.

openclaw attach grants a coding harness more carefully. The Gateway resolves the session, mints a temporary grant limited to it, and passes the bearer token through the child environment rather than the command line. A normal launch revokes that grant when the harness exits.

“Continue this work over there” is therefore a capability exchange. The destination gets limited, temporary authority beside one session. It does not receive a pasted transcript plus whatever ambient credentials happen to be available. This is a sound direction for agent tooling because scope and lifetime are visible parts of the handoff.

Session URLs are identifiers, not secrets. OpenClaw requires tokens or passwords to be supplied separately during pairing. A short link can locate the work without becoming a key to the Gateway.

Shared work needs roles, not one shared password

A team Gateway needs to know who each person is. OpenClaw's operator-scope documentation lets a role decide whether someone may see, suggest changes to, or write in sessions created by another person. Roles can restrict which agents a person may run and require sandboxes for their sessions.

Required sandboxes are isolated per authenticated creator. When a configured agent workspace is writable, OpenClaw reduces it to read-only for role-required sessions. That prevents a shared workspace from becoming a writable bridge between guests.

The same documentation marks an important limit. A shared Gateway token or password counts as trusted operator access. Some HTTP surfaces restore the default operator scopes even when a caller declares narrower ones. OpenClaw recommends separate Gateways where a real trust boundary is required.

“Multiplayer” should not mean distributing one bearer secret to the team. Use identity-bearing access, assign named roles, and separate Gateways when groups must not share an administrative trust domain. Our review of Agents Shipgate reached the corresponding merge-time lesson: a control is not independent when the evaluated actor can rewrite or bypass its trust root.

Incognito limits retention, not observation

The Control UI now includes Incognito threads, but the name deserves a precise reading. The Control UI documentation says the session entry, transcript, and compaction state remain in memory until the Gateway restarts. OpenClaw also skips its automatic memory flush. On a multi-user Gateway, other sessions cannot reach these threads through transcript search or agent session tools.

The agent still has its normal tools. A file write can persist data. The model provider still processes messages, content-free audit metadata remains, and the Gateway owner or process operator can observe live sessions. Incognito limits Gateway persistence and access by other Gateway-mediated users. It is not a private-computing mode.

That boundary is useful when work should stay out of ordinary transcript history. It is unsuitable for a secret that must not reach a provider, tool, host operator, or file system.

Test the ownership model

Before enabling shared or remote sessions, test more than the polished handoff:

1. Back up configuration and state before upgrading. The release includes breaking migrations for OpenProse and older OpenAI route names, and its notes explicitly recommend a backup.
2. Attach to one session from two clients. Confirm that both project the same Gateway-owned state instead of creating a duplicate.
3. Give a test identity sessions.others: "view" and confirm it cannot mutate a foreign session. Repeat with "suggest" and "write" only where collaboration needs them.
4. Require a sandbox for a guest role and verify that its shared workspace is read-only.
5. Launch openclaw attach, inspect what the harness can reach, exit it, and confirm the temporary grant is revoked.
6. Create an Incognito thread, write a harmless file through a tool, and restart the Gateway. The transcript should disappear. The surviving file shows why tool effects sit outside that promise.
7. Interrupt a remote worker. Confirm that the Gateway still resolves the session and reports its state without forcing an operator to guess whether the original prompt ran twice.

OpenClaw 2026.8.1 gives operators a clearer answer to where agent work lives. Gateway-owned sessions bring continuity across devices and workers, but they also make identity, role design, retention, recovery, and service boundaries part of the deployment. Portable agents are only as dependable as the place that remembers who may resume them.