How to Manage Multiple Claude Code Sessions Without Losing Track

Claude Code spends most of its time working without you — which means the natural next step is running two, three, or five sessions at once. The hard part isn't starting them. It's isolating their work so they don't trample each other, and knowing at a glance which one is waiting on you. This guide covers both.

Why run sessions in parallel at all

A single Claude Code turn on a non-trivial task — implementing a feature, running a test suite, refactoring across files — can take several minutes. If you sit and watch, you're the idle one. Common parallel patterns:

• Independent tasks in one repo — a bugfix in one session, a doc update in another.
• Different repos — your API server and your frontend, each with its own session.
• Exploration + implementation — one session investigates a design question while another executes an approved plan.

Step 1: Isolate the work — git worktrees

Two sessions editing the same checkout is the classic failure mode: one session's git status fills with the other's half-finished edits, and builds pick up mixed state. The fix is git worktree: one clone, multiple working directories, each on its own branch.

# From your main checkout
git worktree add ../myapp-fix-auth  -b fix-auth
git worktree add ../myapp-new-onboarding -b new-onboarding

# One Claude Code session per worktree
cd ../myapp-fix-auth        && claude   # terminal tab 1
cd ../myapp-new-onboarding  && claude   # terminal tab 2

Each session now has a clean tree, its own branch, and its own build artifacts. When a branch merges, git worktree remove ../myapp-fix-auth cleans up. Worktrees share the object store, so this costs far less disk than extra clones.

Step 2: Give each session a home — terminal layout

Any multiplexer or tab-capable terminal works. What matters is that each session has a stable, findable place.

tmux

# One named window per session
tmux new-window -n fix-auth
tmux new-window -n onboarding

# Or split one window into panes
tmux split-window -h

Window names in the status bar double as a crude session list. tmux also survives SSH disconnects, which makes it the default choice for remote machines.

iTerm2 / Terminal.app / your IDE

Tabs or split panes work the same way: one session per pane, named after the task. VS Code and Cursor users often run one Claude Code session per editor window, scoped to that window's workspace — the integrated terminal keeps session and code side by side.

Two habits make any layout easier to navigate: rename tabs after the task (in tmux, tmux rename-window fix-auth), and give each session a status line — the /statusline command sets up a custom line under the prompt (model, git branch, context usage), so every session is self-describing when you land in it.

Step 3: The real problem — knowing who needs you

Isolation and layout are solved problems. The one that actually costs you time is attention routing. A Claude Code session blocks in specific, easy-to-miss moments:

• It wants permission to run a tool — an edit, a shell command, a network call.
• It finished a plan and wants approval before touching code.
• It asked you a clarifying question with a few options.
• It simply finished, and the next prompt is on you.

With one session, you notice. With four, one of them is silently stalled behind the others' output — five minutes of wall-clock time gone because a yes/no dialog sat unseen. Cycling through tabs to check (Cmd+Tab, click, read, repeat) is exactly the kind of polling loop you'd never accept in code.

Terminal-native signals

You can get partial signal from the terminal itself: tmux's monitor-activity flags a window on new output (noisy — any output triggers it), and iTerm2 badges tabs on activity or bell. These tell you something happened, not Claude is blocked waiting for you — you still have to look.

Hook-based signals

Claude Code's hooks fire shell commands on lifecycle events — including Notification (Claude needs input) and Stop (Claude finished). Wiring those to macOS notifications gets you real push signal; our macOS notifications guide has copy-paste setup. The remaining gap: notifications tell you about events, but not state — "which of my five sessions are blocked right now?" still requires something that aggregates.

Step 4: A status board for all sessions

That aggregation is the piece we ended up building an app for. AgentManager is a macOS menu bar app that shows every Claude Code session on the machine in one small always-on-top floating window:

• Each session is a row with a status lamp — waiting for input, running, done, idle.
• Waiting rows say what kind of answer is needed — a yes/no approval, a plan review, or a multiple-choice question — so you can triage before switching.
• The window surfaces automatically when a session starts waiting, and hides when everything is clear.
• Clicking a row jumps to the exact terminal pane running that session — iTerm2, Terminal.app, Ghostty, and VS Code-family editors (tmux sessions are tracked with full status, but pane jumping isn't supported for tmux yet).

It works via the same public hooks API described above (setup is one click, and the hooks are cleanly removable), so it composes fine with your own hook scripts. Sessions run in worktrees, tabs, tmux — anywhere — and still land on the same board.

Practical tips that keep parallel sessions sane

• Name things. Session lists (and AgentManager rows) show the working directory's name — myapp-fix-auth reads better than myapp (2).
• Keep a per-repo CLAUDE.md so every session starts with the same conventions — build commands, test commands, style rules — without re-explaining.
• Match session count to your review bandwidth. Each parallel session produces diffs you must read. Two to four is the sweet spot for most people; past that, review becomes the bottleneck, not generation.
• Prefer plan approval for bigger tasks. Reviewing a plan for 30 seconds beats reviewing a 40-file diff that went the wrong direction.
• Close finished sessions. Ending the session (rather than abandoning the tab) keeps every list you look at truthful.