OpenClaw Multiplayer Shared Agents: Two Devices, One Context

Two devices can share one OpenClaw agent safely, but only when you treat the queue as text and persistence as a separate job. The shared session holds the context; files like active-tasks.md hold the commitments.

That distinction is the whole trick. OpenClaw 2.0 (release v2026.8.1, announced August 30, 2026) added multiplayer shared sessions on top of a Gateway that remains one shared trust domain, so two phones, two laptops, or two people can steer the same run without each getting a private fork (docs.openclaw.ai). The official docs are explicit that ownership, presence, and roles are coordination aids, not security isolation between hostile users (docs.openclaw.ai). What the docs describe and what users actually trip over are two different things: the queue, the session lifetime, and the memory.

Phone on the couch, laptop on the desk: what actually breaks

A common two-device pattern in the wild is not two people at all. It is one person with a phone as a remote and a Mac Mini or VPS as the host, often over Telegram. One user described it plainly: asking "my openclaw agent Monica from telegram to install mem0 locally on my mac mini" (x.com).

Four failure modes reported by users show up when a second device or second person enters the same agent:

1. Messages silently vanish. The hardest-won line in the community is a checklist item: queue mode enabled so messages never silently drop, paired with active-tasks.md as persistent state for crash recovery and a Boot.md that re-reads it on restart (x.com). Without that combination, a message sent while the agent is mid-turn is conversation text at risk, not a saved work item.
2. Instructions evaporate after compaction or restart. One Reddit user put it sharply:

"There's no durable task queue — when the agent says 'I'll work on that,' it's a conversational promise." — u/Brave_Nobody_6909, r/openclaw

The same thread reports promises disappearing after compaction or restart, with the agent ignoring saved runbooks. A separate maintainer-level explainer admits the underlying pattern: an agent that "works perfectly for 20 minutes" then "silently forgets your instructions and goes rogue" when memory handling is misunderstood (x.com).

1. The session resets under you. Telegram channel defaults have included thread: { mode: "idle", idleMinutes: 180 }, which resets the session after a few idle hours; one user changed it to 4 days after hitting the forgetfulness on a phone-as-second-screen setup (x.com). Context overflow makes it worse: excessive tool use can cause the last message to be re-injected so the agent "responds to the same thing over and over" and then "silently degrades" (x.com).
2. Pairing breaks before multiplayer even starts. After one upgrade, paired devices lost operator.read/operator.write scopes and fell into an infinite pairing loop with dead tools; the founder replied "This was me being overzealous in fixing a potential security issue" (x.com). Chinese-language users hit the same wall as 1008: pairing required, with the local device stuck in a Pending queue until openclaw devices list plus devices approve <UUID> (x.com).

Presence shows when someone is typing, but no indicator turns a queued message into a saved task.

One Gateway, one trust domain: shared session, separate agents, and who owns what

OpenClaw 2.0's headline change is shared sessions: another person can join active work with its context preserved, which independent reviews framed as the shift from single-operator to collaborative work (eesel.ai). Underneath, two concepts from the official docs decide your setup.

Multi-user mode means several trusted people operate one agent. Every shared session records three layers: an immutable creator (createdActor, write-once), an assignable owner (like a GitHub assignee, changeable anytime), and a participant history of who actually prompted it (docs.openclaw.ai). Presence shows viewers and typists, but typing drafts never reach the model or transcript, and turn attribution is explicitly best-effort because steering can merge several people's input into one turn (docs.openclaw.ai). In practice, a follow-up sent from a second channel while the agent is mid-tool-call lands in the transcript, but the running turn finishes first, so the second instruction reads like a steering note, not an interrupt (docs.openclaw.ai).

Multi-agent mode means one Gateway process hosts multiple isolated brains, each with its own workspace, agentDir (auth profiles, model registry), and SQLite session store at <agentDir>/openclaw-agent.sqlite (github.com). A binding routes each inbound channel event to an agent, most-specific match wins; never reuse one agentDir between agents or they overwrite each other's auth-profiles.json (stack-junkie.com). Minimal example: { agentId: "coding", match: { channel: "telegram", accountId: "coding-bot" } } routes one bot to one agent.

The trust sentence to memorize: "A gateway is one trust domain" (docs.openclaw.ai). Roles, owner filters, and avatars do not isolate hostile users; mutually untrusted users need separate Gateways, ideally separate OS users or hosts.

For two devices belonging to one person, pick the left column. For two people who should not routinely see each other's history, pick the right column; when access must be enforced against untrusted users, use two Gateways. Reddit advice for couples sharing one bot converges here: "create 2 agents, same auth profile, but 1 geared towards you... and the other to your wife" (u/mr-cto-apps, r/openclaw). In one thread about sharing a single Telegram bot, a user advises that "most people in your situation just run two instances" (u/dertobi, r/openclaw) — advice that still holds for separate private work after 2.0 added shared sessions.

Where your second message goes while the agent is busy

Think of three buckets, because users keep confusing them and losing work at the boundary.

Bucket 1: the session queue. Text you send while the agent works is appended to the current session. Queue mode makes it wait instead of dropping, and presence tells you when the agent is mid-turn: your message then steers the next turn rather than interrupting this one. Draft typing previews are ephemeral and never enter context (docs.openclaw.ai). Keep second-device messages short and explicit ("after this finishes, do X; do not restart Y") because the docs describe turn attribution as best-effort when steering merges several users' input (docs.openclaw.ai).

Bucket 2: persisted tasks. A queued message is not a durable work item. If the Gateway restarts, the session compacts, or you hit /new, conversational promises can vanish. The community fix that survives restarts is a file, not a message: active-tasks.md as crash-recovery state plus a Boot.md the agent reads on session and Gateway restarts (x.com). Memory tools can re-inject context, but one widely shared explainer warns the loaded memory itself can be summarized away: "The memory exists on disk. The agent just lost the ability to walk through it" (x.com).

Bucket 3: scheduled work. Cron and Automations run while the Gateway runs; if the host sleeps, schedules stop (eesel.ai). One user reported cron runs making the agent "basically unusable during that time" as session history flooded context, and recommended isolating contexts per Telegram topic (x.com). Use scheduled jobs for recurring work, never as a substitute for queueing a follow-up instruction.

Queue inspection can lag behind reality: one thread reported requests visibly queueing while /subagents and /tasks showed nothing (reddit.com). Treat the file in bucket 2 as the restart-safe survival check, independent of what the queue UI shows.

The two-device setup that does not lose instructions

This is the configuration for one person on a laptop plus a phone, or two trusted teammates on one shared session. It follows the official quick-setup and production runbooks (docs.openclaw.ai) with the loss-prevention patches the community converged on.

1. Put the Gateway on an always-on host, access it by identity. A small VPS, office Mac, or Mac Mini works; bind the Gateway to loopback and front it with Tailscale Serve or Cloudflare Access rather than a public port or a shared token. Identity-backed access is what gives per-person attribution in sessions and commit credit; a shared token makes everyone the same owner profile (docs.openclaw.ai).
2. Join both devices to the same session, not two sessions. Open the Control UI or chat channel on each device, assign the session owner explicitly (Control UI Assign to me / Assign to, or the sessions tool assign_owner), and use @mentions for handoffs. DMs versus group rooms need separate allowlists (docs.openclaw.ai). Owner reassignment changes responsibility, not creator-bound sharing or archive authority, so keep the creator stable.
3. Turn the queue on and make work survive restarts. Switch the shared session to queue mode so a message sent mid-turn waits instead of competing — without it, users report messages can silently drop. Keep an active-tasks.md in the workspace with one line per commitment (done / doing / next), and add a Boot.md that instructs the agent to read it on startup (x.com). Verify the model responds before relying on the second device, since saving credentials alone does not verify success (docs.openclaw.ai).
4. Lengthen the session lifetime on phone-facing channels. If Telegram is the second screen and your thread uses the reported thread: { mode: "idle", idleMinutes: 180 } reset, raise it for long-running work (one user went to 4 days) and keep topics separated so cron output does not flood the shared context.
5. Give each person their own model account. Gateway profiles can hold personal credentials; new sessions prefer the personal default without changing the Gateway default, and other users see only a person-level label rather than email or account ID (docs.openclaw.ai). Credentials must be entered through protected UI or hidden terminal prompts, never pasted conversationally where they would land in the shared transcript.
6. Verify end to end. From the second device, send a message mid-turn and confirm it is retained and processed after the active turn, then restart the Gateway and confirm active-tasks.md restores the commitment. The official production checklist ends the same way: verify the complete flow before calling it done (docs.openclaw.ai).

Rules that keep shared context from rotting

Three rules cover most of the rot users describe.

Sign every memory write. The quietest failure mode is unattributed rules accumulating until nobody dares delete them: "six months in the shared context is full of rules nobody can trace to a person, so nobody feels allowed to delete them," with the suggested fix "author on every memory write" (x.com). The pattern is shared writes without authorship. Prefix durable notes with who asked and when; prune monthly.

Sandbox the lower-trust seat. Roles can limit session access, permitted agents, and operator scopes, and guest sessions can be forced into sandboxes with workspaceAccess: "none" so file and shell tools get a private workspace instead of the shared agent workspace (docs.openclaw.ai). Keep private drafts in Draft sessions, remembering that drafts stay out of other users' sidebars but are never hidden from admins (docs.openclaw.ai).

Know when to stop sharing. One multi-agent operator called context bleed the "biggest practical challenge," saying agents "drift into each other's territory" (u/BP041, r/openclaw). Chinese-language builders converge on a blunter rule: tune one agent, then clone it per machine — "help it clone to a new device" so a tuned setup becomes "one per person" (x.com) — syncing only memory and dotfiles while leaving credentials and live sessions behind (x.com). That maps to the docs' own escape hatch: per-agent Memory Wiki vaults (vault.scope = "agent"), explicit shared Markdown directories instead of cross-agent transcript search, and separate Gateways when isolation must be real (github.com).

FAQ

Can two devices share one OpenClaw agent session at the same time?

Yes. Both devices join the same session; the session, not the device, holds the context. Assign an owner and use queue mode so the second device's message waits (docs.openclaw.ai).

Why do instructions disappear after compaction, /new, or a restart?

Because a chat message is not a stored task. Compaction summarizes context, /new starts fresh, and restarts drop in-memory state. Keep commitments in active-tasks.md with a Boot.md re-reader (x.com).

Should two people share one agent or run one agent each?

Share one agent when both people need the same thread, memory, and queue. Run one agent each (or one Gateway each) when histories, credentials, or permissions must not mix; multi-user features do not provide security isolation (docs.openclaw.ai). Shared steering can carry Co-authored-by commit trailers when GitHub attribution is configured (docs.openclaw.ai).

Share one or clone one: pick in 30 seconds

Queue mode keeps two typists from talking over each other, but it does not settle conflicting instructions — merged input can still mix. The file keeps their instructions alive after the restart.