[FEATURE] Multi-device Cowork: Allow concurrent Cowork agents on multiple machines under a single account

Status Open
Maintainer reply None cached
Activity 8 comments · opened Apr 5, 2026

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

Cowork currently enforces a single-device lock per account. If a Cowork agent is running on Machine A, attempting to start Cowork on Machine B (same account) presents:

"Another device is connected" A Cowork agent is already running on [Machine A]. Quit the Claude app on that device, then restart this one to take over.

The only option is "Disconnect all and retry" — a destructive action that kills the session on Machine A.

This is a hard blocker for users who operate across a stationary workstation and a portable laptop — a common setup for remote-first professionals, consultants, and anyone doing substantive knowledge work.

My setup: I run an AI consulting practice and have built an agentic operating system on top of Claude's ecosystem (Claude Code, Cowork, Dispatch, MCP connectors). My infrastructure spans two machines:

  • Cynapse4eva (home workstation, always-on) — runs Cowork as the primary command center with Dispatch, scheduled tasks, and full MCP connector access.
  • - CynapsePro (Surface Pro laptop, travel/on-the-go) — currently locked out of Cowork entirely because the workstation holds the agent lock.

The workstation is the right home for Dispatch and scheduled tasks. But when I'm traveling or working from a client site, I have zero access to Cowork's agentic capabilities on my laptop. I'm forced back to standard Chat mode — no file system access, no autonomous multi-step execution, no connectors. The delta between Chat and Cowork is massive, and losing it on the road is a real productivity hit.

Proposed Solution

Allow multiple Cowork agents to run concurrently on different devices under the same account, with each agent operating independently against its own local file system and session state.

Key design points:

  1. Independent agents, shared account. Each device runs its own Cowork VM with its own folder access, session history, and task queue. No cross-device sync is required (and per Anthropic's own docs, this isn't currently supported anyway). The agents simply need to coexist.
  2. Dispatch binds to one device. Dispatch (mobile → desktop) should remain single-target. Let the user designate which machine receives Dispatch tasks — most likely the always-on workstation. This avoids routing ambiguity.
  3. Usage limits are shared. Both agents draw from the same account's token budget. This is already the implicit contract — the user is paying for a plan, not a per-device allocation. Anthropic can throttle or flag abuse if concurrent usage exceeds reasonable thresholds.
  4. MCP connectors are per-device. Each Cowork instance configures its own connectors independently. This is already how it would work given that connector auth is stored locally.

Possible implementation approaches:

  1. Remove the device lock, keep sessions independent. The simplest path. Each Claude Desktop install registers its own Cowork agent. No sync, no shared state — just lift the mutex. Dispatch remains pinned to one device via a user setting.
  2. Device registry with role assignment. The account maintains a registry of authorized devices. Each device is assigned a role (e.g., "Primary — receives Dispatch" vs. "Secondary — local Cowork only"). This gives users explicit control and prevents accidental Dispatch routing.
  3. Session handoff (less preferred). Allow a Cowork session to be "transferred" between devices without killing it. This is more complex and less useful than true concurrency, but could be a stepping stone.

Alternative Solutions

  • "Disconnect all and retry": The current escape hatch. Destructive — it kills the workstation session, cancels any running tasks, and breaks scheduled task continuity. Not viable for a setup where the workstation needs to stay alive.
  • Dispatch from mobile while traveling: This partially works — I can send tasks from my phone to the home workstation. But it requires the workstation to be awake, introduces latency, and doesn't help when I need to point Cowork at local files on my laptop (e.g., a client deliverable I'm iterating on at their office).
  • Separate accounts: I could pay for a second Max subscription. But this fragments my MCP connector auth, memory, conversation history, and preferences across two accounts. It's a $100-200/mo workaround for what should be a platform capability.
  • Cloud-synced working directory: Tools like Fast.io or a shared Google Drive folder could give both machines access to the same files. But this doesn't solve the core problem — the Cowork agent itself is locked to one device. The files are accessible; the agent is not.

Priority

Critical - Blocking my work

Feature Category

CLI commands and flags

Use Case Example

_No response_

Additional Context

Who this impacts:

This isn't an edge case. The two-machine setup (workstation + laptop) is standard for:

  • Consultants and freelancers who work from home and travel to client sites
  • - Remote-first professionals with a desk setup and a portable machine
  • - - Power users building agentic workflows where Cowork is infrastructure, not a nice-to-have

The current single-device lock treats Cowork as a casual productivity tool. For users who've built real workflows around it, it's a hard constraint that forces a binary choice between mobility and capability.

---

Filed from claude.ai using Claude in Chrome after being blocked by the device lock on Claude Desktop. Which kind of proves the point.

View original on GitHub ↗

6 Comments

AppFzx · 4 months ago

This is my exact scenario and the proposed solutions solves it. I don't want anything shared between the laptop and my always on desktop. I demo Claude Cowork for clients and it's a bad look when I have to explain this issue.

mauserbow · 3 months ago

I'm very similar, still looking at how I can have my always on PC perfoming functional tasks regularly using cowork while having the freedom to do other or related tasks on my laptop. Mobility is key, but so is being able to schedule and trust background execution on the pc while I am mobile.

drmathbelanger · 3 months ago

Cowork's single-device lock fails silently across multiple installs. No warning that another machine already holds the lock, no way to transfer it, no UI signal that I'm on the wrong machine — the wrong machine just sits there blocking everything. The task isolation between devices already exists in the code (new tasks on machine A don't appear on machine B and vice versa), so just let the agents run independently. Until multi-device ships, at the very minimum show users which machine holds the lock and give us a one-click transfer. Costing me an hour+ daily as a Max 20x subscriber.

kcarriedo · 3 months ago

The single-device Cowork lock is a real blocker for anyone running a desk+laptop setup — the "take over" flow breaks async work entirely if you haven't explicitly cleaned up the other session first.

The multi-machine case is also where you start wanting out-of-process state coordination anyway: if your home workstation runs overnight agents and you pick up on your laptop the next morning, there's no reliable way to see what the agents actually completed vs. what they said they completed. Cowork's single-device lock masks a deeper gap — no shared, durable session-state surface that survives across machines.

A few patterns I've seen people use as workarounds today:

  • Keep a state/last-cycle.json in the repo (committed or in a shared Dropbox/iCloud-synced path), written atomically by the on-device orchestrator, read on resume from the second machine
  • Use Claude Code's --from-pr flag when your overnight session was branch-scoped, then manually reconstruct the context summary on the new machine
  • Run the agents on a always-on server/NAS and use the remote-control flow from the laptop — which still isn't "local" in the way you want

None of these are the seamless cross-device handoff you're describing. The core missing piece is a session state surface that's account-scoped and device-independent — which is also what would make the multi-device Cowork story work properly.

---

Building infrastructure around exactly this portability problem. (claudeverse.ai) — if this gets traction with Anthropic I'd be curious to hear how the design lands.

wpstbffm · 2 months ago

+1 for this feature request.

My setup: Claude Desktop on both a Mac Mini (primary workstation) and a Windows notebook. Currently, scheduled tasks created on one device are invisible and non-executable on the other due to the single-device lock.

Concrete impact: I have a recurring weekly task (IFRS/auditing news → LinkedIn drafts) that has no dependency on local files. There is no technical reason this task requires local execution — it could run cloud-side and deliver results to whichever device I'm actively using.

Proposed solution priorities:

  1. Cloud-hosted scheduler: Store task definitions account-wide, not device-local. Execute server-side where no local resources are needed.
  2. Task sync across devices: Make scheduled tasks visible and editable from any paired device.
  3. Device handover: If the primary device is asleep, delegate execution to an available device or cloud fallback.

Dispatch (mobile → desktop) is a good step, but the missing piece is desktop-to-desktop continuity and cloud execution for tasks that don't require computer use or local file access.

cklockner54-ux · 2 months ago

FEATURE REQUEST: Cross-Device Cowork Session Sync via User-Defined Sync Folder
GitHub: anthropics/claude-code | Related: Issue #43698

---

NOTE TO READERS

I am not a developer and have very limited GitHub experience — I have posted here only once before, and needed step-by-step guidance to do so. I am a regular Cowork power user submitting this as a product feedback and feature request. I apologize in advance if the format or placement of this post is not quite right. I believe the idea has merit and wanted to make sure it reached the right people.

---

SUMMARY

Allow Cowork session data (projects, task history, threads, memory) to be stored in a user-defined folder rather than a fixed app-local path. The user points two or more Cowork installs at the same folder — synced via OneDrive, Dropbox, Google Drive, or any cloud storage they already use — enabling continuity across multiple PCs without Anthropic needing to build or maintain cloud infrastructure.

---

USE CASE

Power users who run Cowork on two or more Windows PCs (e.g., home desktop and work laptop) currently have no way to continue an ongoing project or review task history from their second machine. Sessions are siloed to the device where they were created. Dispatch (phone → desktop) partially addresses cross-device access but does not solve PC-to-PC continuity.

---

PROPOSED IMPLEMENTATION

  1. Add a setting in Cowork: "Session data location" — defaults to the current local path, but allows the user to point it to any folder on their system (including a cloud-synced folder).
  1. Both PCs are configured to point at the same synced folder. When Cowork opens, it reads session data from that location. When tasks complete, it writes back to the same location. The cloud sync provider handles replication between machines.
  1. File-lock / exclusive access mechanism to prevent simultaneous write conflicts:
  • When Cowork opens and loads the session database, it writes a lightweight lock file (e.g., cowork.lock) to the folder containing: machine ID, timestamp, and app version.
  • If a second Cowork instance opens and detects an existing lock file, it enters read-only mode and displays a clear warning: "Session data is currently in use by [Machine Name]. Open in read-only mode, or wait for that session to close."
  • The lock is released when Cowork closes cleanly. A stale lock (e.g., from a crash) is auto-cleared after a configurable timeout (suggested default: 30 minutes), with a user-visible prompt before clearing.
  • The user is responsible for not running both instances in active (write) mode simultaneously — the lock mechanism enforces this and makes the risk transparent rather than silent.

---

WHAT THIS SOLVES

  • Full project and task history available on any configured PC.
  • No new Anthropic cloud infrastructure required.
  • Works with whatever sync provider the user already has.
  • Simple mental model: one "active" machine at a time, others are read-only until the lock clears.

---

WHAT THIS DOES NOT SOLVE

  • True real-time collaboration or simultaneous multi-machine active sessions — that is a different and more complex feature.
  • This is intentionally a pragmatic, user-managed solution, not a fully automated sync service.

---

PRIORITY RATIONALE

Multi-PC professional workflows are common. Dispatch is a useful feature but addresses a different problem (mobile task assignment). There is currently no solution for users who move between two desktops and need continuity of their Cowork context.

Showing cached comments. Read the full discussion on GitHub ↗