Running multiple Claude Code sessions without losing track

One Claude Code session is easy to watch. The moment you run two or three in parallel (a refactor here, a test suite there, a bug fix in a third), the bottleneck stops being the work and becomes keeping track of the work. Which one is waiting on a permission? Which one finished five minutes ago? Which one quietly errored?

Here is how to run several Claude Code sessions cleanly, and how to always know which one wants your attention.

Give each session its own working copy

The biggest source of trouble with parallel agents is two of them editing the same files. Git worktrees solve it: each session gets a separate checkout of the same repository, on its own branch, in its own folder.

# from your repo
git worktree add ../myapp-feature-a -b feature-a
git worktree add ../myapp-bugfix-b  -b bugfix-b

Now open a terminal in each folder and start Claude Code there. The agents never step on each other, and you can merge each branch when it is ready. When you are done, clean up with git worktree remove ../myapp-feature-a. There is a fuller walkthrough in Claude Code with git worktrees, including how to carry over the untracked files a fresh worktree lacks.

Watch out for shared resources

Isolated folders still share one machine. Two dev servers on port 3000, two test runs hitting the same local database, two agents writing the same Docker volume: each of these produces a failure that looks like a bug in the code. Give each worktree its own port and its own database name through its .env, and your parallel runs stop poisoning each other's results.

Name your terminals

A wall of identical terminal tabs is its own kind of blindness. Give each tab or pane the name of its task, so the tab bar itself tells you what is running where. In tmux:

tmux rename-window feature-a

In most terminal emulators you can set a tab title per shell; a single echo -ne "\033]0;feature-a\007" at the top of each session does it. If you live in tmux, one window per session with a stable naming scheme beats splitting panes: you can jump straight to feature-a by name instead of hunting a grid.

Scope each session narrowly

Parallel sessions work best when each has a single, well-bounded task. An agent told to "improve the app" will wander into files another session is touching; an agent told to "add pagination to the users table" stays in its lane. Narrow scope also makes each run shorter, so you are juggling finished work instead of five open-ended jobs.

The practical limit is not your machine, it is your reviewing capacity. Three sessions producing three diffs you actually read is worth more than six producing six you skim, and unreviewed agent output has a way of becoming next week's bug.

Widen permissions so they stop asking

Every permission prompt is a session parked until you notice it. Running several at once multiplies that cost, so it is worth going through permissions.allow in your settings.json and letting the safe, repetitive commands through: your test script, your linter, reading source. Keep deny tight around secrets and destructive commands. Fewer interruptions per session is the single change that makes parallelism feel light rather than frantic.

The hard part: knowing which one needs you

Even with worktrees and good names, the real cost of parallelism is attention. A session that needs a permission is blocked until you notice, and every minute it waits is a minute wasted.

You can wire the Notification and Stop hooks to fire desktop alerts (see getting notified when Claude Code needs you), and the payload carries cwd, so a small script can put the project name in the message:

#!/usr/bin/env bash
payload=$(cat)
project=$(basename "$(echo "$payload" | jq -r '.cwd')")
notify-send -u critical "Claude Code" "$project needs you"

That helps. But with several sessions the alerts still pile up in a notification centre that collapses them, they arrive in the order they fired rather than the order that matters, and a "needs you" from twenty minutes ago looks exactly like one from ten seconds ago. You end up alt-tabbing anyway to find out what is still true.

See every session at a glance

This is precisely the problem Blooby was built for. It gives each Claude Code session its own animated desktop mascot, driven by Claude Code's own hooks, so the current state of every session is visible at once in the corner of your screen:

• busy while it works,
• looking up the instant it needs a permission,
• celebrating the moment it finishes,
• dozing off when a session goes idle.

The difference from notifications is that a mascot shows state, not history: nothing to dismiss, nothing to miss, nothing stale. Run five agents across five worktrees and you no longer hunt through terminals: you glance, you see the one looking up, and you go unblock it. No polling, no config: Blooby sets up its own hooks and reads the sessions for you.