Can I use Claude Code on multiple computers at the same time?

Yes. Give each computer its own local clone of the code and make a git remote the source of truth, then connect every machine to one shared task queue. Each machine works at local-disk speed with its own Claude account, and the shared queue leases tasks so two machines never pick up the same work.

Can I use Dropbox or iCloud to share files between machines for Claude Code?

It is not recommended. Consumer sync tools have no file locking, so an agent writing a file while the sync daemon rewrites it can lose or corrupt work. They also sync node_modules and build output, which is slow and unnecessary, and they resolve conflicts by creating duplicate files rather than merging. Use git as the source of truth instead: it merges properly and never silently overwrites.

Should I use a shared network drive instead?

Usually not for coding agents. Builds, git operations and file watching are dramatically slower over a network mount, and concurrent writes from two machines can corrupt files. A shared filesystem only makes sense when every session runs on one host machine and the other computers connect to it by SSH, so there is still exactly one filesystem in play.

How to use Claude Code on multiple computers

Q: How do I stop two computers doing the same task?

Use a shared queue with leasing. Because the queue lives on a server rather than on any one machine, a task leased by a laptop is already invisible to a desktop. Add path claims to reserve the files you are about to edit, and other machines see the conflict before they start.

Q: Does each computer need its own Claude account?

Each machine signs in separately, and it can be the same account or a different one. For a team, each person uses their own account on their own machine. Coordination does not depend on the accounts being shared — it comes from the queue, which every machine reads regardless of who is signed in.

Two laptops and a desktop. Or five people, each with their own Claude account. They all need one source of truth — but the obvious answer, syncing a folder, is the one that breaks. Here's what to use instead.

The short answer: don't sync files — share a queue and a git remote. Git holds the canonical code; every machine keeps a fast local clone; one shared, leased task queue stops two machines doing the same work. Setup is one command per machine.

Open the board — free →

Why syncing a folder is the wrong instinct

Putting your repo in Dropbox, iCloud Drive or OneDrive looks like the answer: every machine sees the same files. In practice it's the worst option for agent work.

What goes wrong: no file locking — an agent writes a file while the sync daemon rewrites it underneath, and edits vanish mid-session · node_modules and build output get synced, so you push gigabytes to move kilobytes of real change · conflicts produce file (conflicted copy).ts instead of a merge · .git itself can be corrupted by two machines touching it at once.

The deeper issue: these tools resolve conflicts by duplicating. Git resolves them by merging. When two agents are writing code in parallel, that difference is everything.

The two architectures that actually work

Approach	How it works	Best when
Git remote as truth (recommended)	Each machine has its own local clone. Pull before working, push after. A shared queue coordinates who does what.	Multiple people · multiple accounts · working offline · anything team-shaped.
One host, others SSH in	One always-on machine holds the files; other computers connect to it. There is only ever one filesystem.	A solo operator with one strong desktop who wants zero sync and 24/7 runs.

Both give you one source of truth. The difference is where it lives — in the remote, or on one host. What they share is the thing that matters: no file is ever written by two machines at once.

Set it up

Push every repo to git. GitHub or GitLab — the remote is now canonical, not any one laptop. If work only exists locally, commit and push it first; that's the step people skip and regret.
Clone locally on each machine. Onto real local disk, never into a synced folder. Local disk is what keeps builds, git and file-watching fast.
Connect each machine to the shared queue. Once per computer:
```
curl -fsSL https://taskpeace.com/install.sh | bash
```
Sign in on each machine. Run claude, then /login. Same account or different ones — coordination doesn't depend on it.
Work the queue. Each session calls get_next_task, which leases the task. Because the queue is server-side, a task taken by the laptop is already invisible to the desktop.
Pull before, push after. The habit that keeps the source of truth true.

Why a shared queue solves this and a shared folder doesn't

The queue lives on a server, not on a machine. That single fact is what makes it work across computers with no extra setup:

Task leases are already cross-machine. When any session pulls a task it's marked in progress for a few minutes. A second machine — different city, different account — simply doesn't see it and pulls the next one down.
Path claims cover the file half. Call claim_paths before editing and you reserve those files. Another machine calling list_claims sees the overlap before it starts, instead of discovering it in a merge.
Overlap means collaborate, not queue up. Two machines on the same project is the good case — it's how a project gets finished twice as fast. Nobody waits: the second machine claims a different slice (other files, the next task on that board) and ships in parallel. Only the exact claimed files are off-limits, never the project.
Crash-safety. A laptop that dies mid-task drops its lease; the work returns to the queue for another machine.
One cockpit for all of them. The Sessions view shows every connected agent across every computer — who's on what, what's idle, throughput.

For teams

The same model scales to people. Each teammate works on their own machine with their own Claude account and their own clone; the shared board is what makes them one team rather than several people guessing.

Rank once, centrally. "What's next?" has one answer for everyone — no standup required to avoid overlap.
Specialize with roles. Tag tasks by role and let a teammate's session pull only review or only build work.
Name the sessions. Call name_session with the machine or person ("Ana · MacBook") so the cockpit is readable when six agents are live at once.

One gotcha worth knowing

Sessions auto-detect which project they're in from the working directory. If teammates keep the repo at different paths, that detection can miss — pass project explicitly, or set each project's working directory to match. Two minutes of setup that saves a confused afternoon.

Frequently asked questions

Can I use Claude Code on multiple computers at once?

Yes. Local clone per machine, git remote as the source of truth, one shared leased queue so no two machines take the same task.

Can I just use Dropbox or iCloud?

Not recommended. No locking, so live agent writes can be lost; it syncs build output; and conflicts duplicate files instead of merging. Git merges properly.

How do I stop two computers doing the same task?

Leasing, plus claim_paths for the files. Both are server-side, so they work across machines with no extra configuration.

Does each computer need its own Claude account?

Each signs in separately — same account or different. Coordination comes from the queue, not the login.

What about a shared network drive?

Slow for builds, git and file watching, and risky under concurrent writes. Prefer git — or the one-host-plus-SSH model, where there's still only one filesystem.

Run a fleet free → Multiple sessions on one machine →