Can You Run Multiple Instances of Claude Code? Yes, Here's How

Yes. Claude Code has no cap on concurrent instances. Open a second terminal, run claude again, and you have two fully independent sessions. The limits you actually hit are your account’s usage quota and what the two sessions share on disk.

The mechanics

A Claude Code instance is one process attached to one terminal, rooted at whatever directory you started it in. To run a second one:

# terminal 1
cd ~/projects/api
claude

# terminal 2
cd ~/projects/web
claude

That’s the whole trick. Two processes, two working directories, two context windows. Neither one knows the other exists.

If you want both agents inside the same project rather than two different projects, don’t do the obvious thing. Give each one its own checkout with a git worktree:

cd ~/projects/api
git worktree add ../api-auth -b feature/auth
git worktree add ../api-tests -b chore/test-refactor

Then start an instance in ../api-auth and another in ../api-tests. One repository, one shared history, two separate working trees and staging areas. Full command set in the git worktree guide.

What the two sessions share, and what they don’t

This is the part that trips people up, because the boundary isn’t where you’d guess.

Not shared:

• Context. Each session has its own context window. Instance A cannot see what you told instance B, cannot read its plan, and will happily contradict it.
• Transcripts. By default each session writes its own ~/.claude/projects/<project>/<session-id>.jsonl. Resuming one never resurrects the other.
• MCP servers. Each session starts its own connections. Two instances with the same .mcp.json means two sets of server processes running.
• Todos and plans. Per session, unless you’re explicitly using a shared-task feature.

Shared:

• Config on disk, though the two halves behave differently. CLAUDE.md files load at launch, so editing one mid-flight reaches the next session you start, not the ones already running. Claude Code watches settings.json and live-reloads most keys, including permissions and hooks, into sessions already in progress. A few, like model, still wait for a restart.
• Your account’s usage quota. More on that below.
• The filesystem. If two instances are pointed at the same folder, they are writing to the same files. Git does not arbitrate this for you.

The practical consequence of the first list is that “run two instances” is not the same as “run a team.” Two instances are two strangers. Any coordination between them has to come from you, or from something above them.

What breaks when two instances share a directory

Running both agents in one folder on one branch is the failure mode, and it fails quietly:

• Overwrites. Instance A reads utils.ts, edits it, and writes it back. Instance B did the same thing thirty seconds earlier. B’s work is gone, and nothing reports an error, because from A’s point of view it just wrote a file.
• Interleaved commits. git add is repository-wide. If A stages while B is halfway through an edit, the commit contains half of B’s work.
• Lock contention. Two simultaneous git operations race on .git/index.lock. One of them fails with an error the agent then tries to “fix,” which is worse than the original problem.
• Confused agents. An agent that reads a file it didn’t write, sees changes it doesn’t remember making, and starts reasoning about them. It will attempt to reconcile the mystery, and it will get it wrong.

Two directories, or two worktrees, removes all four. The longer version of this argument, with the merge strategy, is in running two agents on the same repo.

The limit that actually applies

Claude Code doesn’t ration instances. Your Anthropic account rations tokens.

Subscription plans use a rolling window (currently five hours) plus a weekly cap, and the important detail is that both are per account, not per session. Three instances burning through a large codebase draw from the same pool as one, three times as fast. They also share the pool with your normal Claude app usage. On API billing, there’s no ceiling at all, just a bill that scales with how many agents you left running.

Concurrent sessions also mean concurrent requests, so heavy parallel use hits rate limiting sooner than the same volume of work done serially.

The machine itself is rarely the constraint. Each session holds its context and its MCP server processes in memory, which adds up, but you’ll run out of quota or out of attention long before you run out of RAM. That trade is worth its own piece: how many agents can you actually run at once.

Where this gets annoying

The instances work. Managing them is what degrades. Four terminal tabs in, you cannot tell which agent is mid-edit, which is finished, and which has been sitting on an approval prompt for eleven minutes waiting for you to notice. An agent parked on a permission prompt looks exactly like an agent thinking hard.

Practical habits that help: name your tabs after the task, keep one project per window, and check on the quiet ones first, because quiet usually means blocked rather than done. Managing multiple AI sessions covers the organizational side.

Past a handful of sessions the terminal stops being the right container for this, which is what crystl is. Projects and their sessions are listed instead of hunted for, approvals surface in one place instead of inside whichever tab is asking, and isolated sessions create the worktree and branch per agent so you never run two of them in the same folder by accident. See parallel sessions for how that fits together.

For the wider field of tools built on this idea, see the best AI agent orchestration tools for coding.

The short answer stands, though: yes, you can run as many as you want. Just give each one its own directory, and remember they’re all spending from the same account.