How to run multiple Claude Code agents without losing track of them

Anthropic documents five ways to run multiple Claude Code agents at once, and a git worktree per session keeps their file edits apart. Starting the agents stopped being the hard part a while ago. Now two of them run migrations against the same dev database, and five sessions want a permission answer in the same minute, all of them from me. I checked every command here against Anthropic's docs on November 13, 2026, because this corner of Claude Code moves fast.

Claude Code has five ways to run agents in parallel

Anthropic's comparison sorts the five approaches by who coordinates the agents, and for independent tasks you hand off, the coordinator is you, in the agent view.

Worktrees give each session its own checkout, cross-session messaging lets sessions pass findings to each other, and the /batch command splits one large change across 5 to 30 worktree-isolated subagents.

My default is the agent view with one worktree per task, and subagents for side errands. Agent teams are the most interesting of the five and the least settled. They ship disabled, and teammates don't get worktrees at all, so the docs tell you to partition the work until each teammate owns its own set of files.

A worktree gives each agent its own files and shares everything else

A git worktree started with claude --worktree <name> gets its own checkout under .claude/worktrees/ on a branch named worktree-<name>, and Anthropic's worktree docs say that worktrees isolate file edits. File edits are all they isolate.

The repository's .git directory is shared. So is a permission approval, since choosing "Yes, and don't ask again" in one worktree saves the rule to the main checkout's .claude/settings.local.json, and every other worktree inherits it. Anything running on the machine is shared too. Five worktrees of one app still point at the same Postgres on port 5432 until something tells them otherwise.

• Dependencies. A worktree is a fresh checkout, so node_modules and the build output start empty. Run the install in each one, or make it the agent's first step.
• Env files. A .worktreeinclude file in the repository root copies gitignored files such as .env into every new worktree. Without one, each agent starts with no secrets and fails in ways that look like bugs.
• Ports. Give each worktree its own port range in its env file, so the third dev server doesn't die on a port the first one holds.
• Databases. Give each worktree its own database, created by the same setup step. Two agents migrating one schema leave it in a state neither of them wrote.

I learned the database rule the slow way, with two parallel projects that shared one datastore and failures that looked random for longer than I like to admit. Running each agent in a sandbox solves the same problem from the other end, since a sandbox brings its own services along with its own files.

Your attention runs out before the agents do

Claude Code's agent view sessions report results only to you, so five background sessions mean five streams of permission prompts and finished branches aimed at one person.

Anthropic also warns that running several sessions multiplies token usage, but the context switches cost me more than the bill. Each prompt pulls me out of whatever diff I was reading, and each finished branch is a review I owe. At five agents I am the slowest part of the system.

On one machine I name every session after its task, so the agent view list reads like a to-do list. I also review finished branches in two batches a day instead of the moment each one lands.

The agent view is one person's screen. When three engineers each run five agents, each of them sees five sessions and none of the other ten, and a question an agent asks waits until its owner looks. Claude Code rollouts across a team break on this same queue, and it is why I stopped treating parallel agents as a terminal problem.

How parallel Claude Code agents work in Aldena

Aldena gives each project its own sandbox for its Claude Code or Codex agents, so a project does the job of a worktree with the services included.

Aldena is my product, so read this section as the pitch it is. Two projects never share a filesystem, and you can connect the same repository to both, so each clones its own copy into its own sandbox and opens its own pull requests. Every project has a setup script that runs once on each new sandbox, with sudo and the project's environment variables, and you install and start PostgreSQL or Redis in that script. The database then runs inside that project's own sandbox, and credentials stay with the project that set them. Claude Code runs on each member's own Claude plan or the team's Anthropic key, and Codex on the team's OpenAI key. The team plan covers 20 projects, and business covers 100.

Inside one project the org chart decides who works. The Delivery agent hands work to one report at a time, so two agents never edit the project's checkout at once, and no agent hands out more than 3 pieces of work in a turn.

The attention problem gets one queue. Every project chat whose agent is waiting on a person lands in the team inbox, grouped by project and oldest first, and any member of the team can answer it. Questions and approvals wait seven days. The aldena page lists recent agent chats across projects with their status, and it can message an agent or stop its run. The Delivery agent opens a pull request and stops there, because no agent merges its own work.

I still run the agent view and worktrees on my own laptop. They cost nothing beyond my Claude plan and run locally, and for one developer they are enough. Aldena is for the point where the agents need their own services and more than one person has to answer them.

Split the files between agents before they start

Anthropic wrote the partition rule for agent teams, whose teammates share one checkout, but the same split keeps worktree branches from colliding when they merge.

Two branches that never touch the same file merge without a conflict in either order, and each diff stays in a part of the code I already have in my head when I review it.