Running several coding agents in parallel without babysitting terminals

Give every agent its own git worktree, keep one list that shows which agents are working and which are waiting on you, and only get interrupted when one of them actually needs you. The rest of this post is how to set that up for Claude Code and Codex.

One coding agent is easy to supervise: you watch it work. Three agents is a different job. One is refactoring the checkout flow, one is writing tests in another repo, and a Codex session is migrating a table. Each runs for a few minutes at a time, then stops, either because it finished or because it wants permission to run a command. If you are not looking at that tab at that moment, it just sits there.

That is the real cost of parallel agents. It isn’t the tokens. It’s the time an agent spends blocked on a prompt nobody saw, and the attention you burn checking tabs that are still busy.

1. Give each agent its own working copy

Two agents editing the same checkout will step on each other: one runs the formatter while the other is halfway through a change, or both edit the same file. The cheapest fix is a git worktree per task. Worktrees share one repository but each has its own directory and branch:

git worktree add ../shop-checkout -b agent/checkout
git worktree add ../shop-tests -b agent/tests
cd ../shop-checkout && claude

Each agent now has its own files, its own branch and its own diff to review. When a task is done, merge or open a PR from that branch and remove the worktree with git worktree remove ../shop-checkout. If tasks live in different repos anyway, separate clones work just as well.

2. Keep sessions where you can find them

Pick one layout and stick to it, so you never have to hunt for a session. Common setups:

• One terminal tab per agent, named after the task. iTerm2, Terminal.app and Ghostty all let you rename tabs.
• tmux, with one window per agent: tmux new -s agents, then Ctrl-b c for each new session.
• One editor window per worktree in Cursor or VS Code, with the agent in its built-in terminal.

Whatever you choose, the hard part comes next: knowing which of those tabs needs you right now.

3. Know when an agent is done or waiting

Both Claude Code and Codex can run a command when something happens. Claude Code has hooks for the end of a turn (Stop) and for permission prompts and idle waits (Notification). Codex has a notify command that runs after each turn. We cover both in detail in Claude Code hooks explained and Codex CLI notifications.

A desktop notification per event is a fine start with one agent. With three or four, it gets noisy fast. Every short turn pings you, and a banner that says “Claude Code needs your attention” doesn’t tell you which of the four sessions it means.

What you want from alerts when several agents run at once:

• Which agent, which project. “checkout service needs your permission to use Bash” is useful; “needs attention” isn’t.
• What happened, in one line, so you can decide whether to switch now or finish what you’re doing.
• Silence for short turns. A 10-second reply you were watching doesn’t need an alert.
• No stale alerts. If you already approved the prompt in the terminal, don’t announce it a few seconds later.
• One alert at a time, even when two agents finish together.

4. One list of every agent

Alerts tell you when something changes. You also want one place that shows the current state of everything, so “is the migration still running?” takes a glance and not a tab hunt. Earpiece keeps a session list from the same hook events. In the terminal:

$ earpiece agents
STATUS    AGENT         PROJECT               AGE   LAST
● working Claude Code   checkout service      12s
◆ waiting Codex         billing               3m    billing. Should I also migrate the invoices table?
◆ waiting Claude Code   api                   8m    api needs your permission to use Bash.
✓ done    Aider         docs-site             21m   docs-site. Rewrote the navigation and fixed three broken links.

The Mac app shows the same list on its Overview page and in the notch. Clicking a session takes you to it: the exact iTerm2 or Terminal.app tab, the Cursor or VS Code window that has the project open, or the app for other terminals. earpiece where shows which terminal and tmux pane each agent is in, and earpiece jump goes to the most recent one.

5. Tell agents apart by ear

Once alerts are spoken rather than shown, you can keep working in another window and still know what happened. With two agents talking, it helps to give each its own voice, or have every line start with the agent’s name:

earpiece voices --gender female
earpiece voice <voice-id> --agent codex

Then a line sounds like “Codex, billing. Migrated the invoices table.” and you know which tab to open without looking.

6. Decide when you don’t want to hear anything

Parallel agents keep working while you’re in a meeting or asleep. Set the rules once:

• earpiece quiet 60 for an hour of silence, with updates still shown on screen.
• earpiece quiet-hours 22:00-08:00 --allow needs_input so only “I need you” gets through at night.
• earpiece off until you turn it back on.

7. Answer without switching tabs (optional)

Most interruptions are small: “can I run npm test?” With Earpiece’s Answer from the card setting (off by default), a Claude Code or Codex permission request shows up on the card in the notch with the exact command and Allow / Deny buttons, and a question from the agent gets a reply box. Nothing is approved without a deliberate click, and anything you don’t answer within about two minutes goes back to the terminal.

A setup that works

1. One worktree and branch per task.
2. One tab, tmux window or editor window per worktree.
3. Hooks on every agent, so done and waiting are reported, with short turns kept quiet.
4. One list of all sessions, and a click that takes you to the right one.
5. Quiet hours, so the agents can keep going when you can’t.

Earpiece covers steps 3 to 5 for Claude Code, Codex and anything that can run a shell command. It’s free, open source and runs on your Mac. Your code and prompts aren’t sent to us. The source is on GitHub.