Can Claude Code work on multiple tasks at the same time?

The short answer

Claude Code is, by design, single-conversation and single-cwd. The thread state, the context window, and the permission model all assume one root directory and one stream of user turns. There is no built-in “branch this conversation off and work on something else in parallel” mode — not because that would be impossible, but because it would make the trust model (file edits, bash commands, tool approvals) ambiguous.

The safe way to multiplex Claude across multiple tasks is to treat each task as its own repo. git worktree add lets you do that without copying the repo on disk: a second working tree backed by the same .git object database, on its own branch, totally isolated for filesystem purposes. Run claude -p in each and you have N independent Claudes that cannot collide.

How it actually works under the hood

The Claude Code CLI is a Node program that spawns an inference loop against the Anthropic API. Inside that loop it issues tool_use requests for Read, Edit, Write, Bash, Glob, Grep, etc., and waits for tool_result values. The model holds the conversation state in its context window; the CLI holds the working-directory state on disk.

Two Claudes running in the same directory will absolutely race each other — not in the API (each one has its own conversation) but on the filesystem. They will both Read the same file, both write competing edits, both run npm install against the same node_modules, and one of their changes will silently win. That is the failure mode worktrees fix.

A git worktree gives Claude a real working directory that points back to the shared object store, branched off any ref you choose:

# in your main repo
git worktree add ../task-1 -b task/auth-refresh main
git worktree add ../task-2 -b task/migrate-orm   main

# each task is an independent Claude
( cd ../task-1 && claude -p "fix auth refresh in api/auth.ts" --output-format stream-json ) &
( cd ../task-2 && claude -p "migrate orm to drizzle"           --output-format stream-json ) &
wait

Both processes write to disjoint directories. Both create commits on their own branch. Both stream NDJSON to stdout (with --output-format stream-json) so you can capture the full transcript for each. Neither one knows the other exists.

Why the alternatives are worse

There are three obvious not-quite-right ways to do this:

• Subagents inside one Claude session.Claude can spawn task agents via its Task tool. Useful for “go grep and summarize” jobs, useless for “go write a feature end-to-end.” They share one context window, do not get their own working tree, and they finish back inside the parent conversation. Not a multiple-tasks-at-once tool.
• Tmux / multiplexed terminals on the same checkout. Two claude panes sharing one working directory. They will fight over files. The first time two of them both Edit package.json, you will lose work and not know it.
• nohup claude -p > out.log & in the background. Fine for fire-and-forget batch runs. Awful for anything that pauses on a decision prompt — you cannot answer it without an interactive surface. Also lossy: if a process dies, you have a log file and no way to resume.

Worktrees are the only option that gives you real source isolation, real branch isolation, and a real path back to a clean merge.

How KanBots does this specifically

KanBots is the supervisor that turns “put Claude Code on N tasks at once” into one product surface. Each card on the kanban board is one potential agent run. Click Dispatch and the desktop app:

• Creates .kanbots/worktrees/issue-<n>-<runId>/ off the repo’s default branch.
• Names the branch kanbots/issue-<n>-<runId> so a global pre-push hook can guard against accidental remote pushes.
• Spawns claude -p --output-format stream-json --verbose --permission-mode bypassPermissions against the worktree.
• Parses every NDJSON event line (system, assistant, tool_use, tool_result, result) and rerenders the live agent thread on the card.

You can do this on as many cards as you want simultaneously. The board updates live; each card shows its own status dot (running, awaiting decision, in review, failed). Per-card cost accrues from the usage data in each result event. The supervisor itself runs in the Electron main process; the Claude processes are real OS children of it and exit cleanly when you stop a run.

Autopilot stacks a loop on top. Feature-devmode picks a parallelism (up to 4) and round-robins through your personas — product author, engineer, reviewer, tester — so four cards work on different angles of the same parent issue at the same time, and the parent issue gets split into subtasks as the agents discover them. QA mode runs typecheck, tests, lint, build, and e2e check commands, dispatches a Claude run against whatever fails, then re-runs the checks.

A concrete walkthrough

Three tasks, three Claudes, one board. Suppose your backlog has #88 add toast component, #89 deflake the auth test, #90 audit unused dependencies.

1. In KanBots, drag #88, #89, #90 into the Todo column. Click Dispatch on each.
2. The desktop creates three worktrees under .kanbots/worktrees/ and spawns three claude -p processes. The cards switch to In progress with a pulsing orange dot.
3. The toast card asks: “Use Radix or build from scratch?”You answer “Radix.” The other two cards do not pause.
4. The dependencies card finishes in 90 seconds, hits In review, shows a diff deleting six packages. The flaky-test card takes 8 minutes and lands a fix to one timer. The toast card asks two more decisions before finishing.
5. From each card you choose Open draft PR (GitHub mode) or Promote (commit onto a real branch). The worktrees stay on disk until you discard.

Common failure modes

One run leaves the working tree dirty

A run can die mid-edit (process killed, machine slept). The worktree is left with uncommitted changes on the agent branch. KanBots displays this on the card; the fix is either Promote (commit and continue) or Discard (remove the worktree). Doing this by hand: git -C ../path stash or git -C ../path reset --hard, depending on whether you want to keep the changes.

Two agents touch the same shared file

Worktrees isolate file contents per branch, but they share the same node_modules, the same OS environment, and the same running dev server if you happen to have one open. If two agents both run npm install simultaneously, one of them will lose. Fix: either pre-install in the main checkout once before dispatching, or use pnpm, which is much safer about concurrent installs.

Branch name collisions

Running the “dispatch on issue 42” flow twice in a row can collide on kanbots/issue-42. KanBots disambiguates with a runId suffix — the real branch name is kanbots/issue-42-7, where 7 is the run primary key. If you are doing this by hand, you will eventually hit fatal: a branch named ‘X’ already exists and need to pick a fresh suffix.

When this is the wrong tool

Running Claude on multiple tasks at once is the right pattern when the tasks are independent. It is the wrong pattern when:

• You actually want collaborationbetween agents on one task. That is multi-persona orchestration on a single card — see spawn multiple coding agents.
• You want one big agent that thinks across the whole repo. One Claude with deeper permissions on the main checkout is the right shape for that — not N small Claudes.
• The tasks have hard ordering. Multiplexing buys nothing when task 2 needs task 1’s output.

For everything else, the worktree-per-task pattern is the safe answer. Read the Claude Code + git worktree workflow for the exact commands, or how to run Claude Code in parallel for the kanban-driven version of the same thing.