Running several AI agent terminals without losing track

Running several AI agent terminals without losing track takes three habits: tie each terminal to exactly one task, name everything after that task, and close every session with a short record of what it did. With two terminals you can hold the state in your head. With five, you will look at a window and not remember whether it was the one fixing the export bug or the one writing tests, whether it finished, or whether you already reviewed it. The agents will not help: each session knows only its own conversation, not what the others are doing. The techniques below are deliberately low-tech (Git branches and worktrees, terminal titles and a small ledger) and they work with Claude Code, Codex CLI or any mix. For the coordination problem itself, overlapping scopes and ordering between tasks, see multi-agent project coordination.

One terminal, one task, one working tree

Every terminal gets one task, and the task gets an ID. If a session starts drifting into a second problem, stop it, write the second problem down as its own task, and bring the session back. Mixed sessions are what make tracking impossible later: their diffs cannot be reviewed against a single set of criteria.

Give each write task its own working tree. Git worktrees let several checkouts of the same repository exist side by side, each on its own branch, so terminal A's half-finished edits never appear in terminal B's test run. A typical layout is a sibling folder per task, created with git worktree add and a branch named after the task, such as eng-14-export-rounding. When the task merges, remove the worktree.

This also limits damage. An agent in its own worktree cannot quietly break the build another agent is testing against, and when you need to discard a session's work you delete one branch rather than unpicking changes from a shared checkout. The setup takes a minute per task and pays for itself the first time two sessions would have collided.

Name everything after the task

Names are how you find things at the end of the day. Use the task ID everywhere: the terminal tab title, the branch, the worktree folder, commit message prefixes and any log file you save. A tab titled ENG-14 codex work tells you in one glance what a window is for; a tab titled after the default shell tells you nothing.

Include the agent and the mode when it matters. ENG-14 claude plan and ENG-14 codex work are different sessions with different authority, and you want to know which one produced which output.

Keep a small ledger outside the agents, a text file or a board, with one line per running session: task ID, agent, working tree, when it started and its current state. Update it when you start or stop a session, not from memory at the end of the day. The ledger is what you read when you come back after lunch, and it tells you how many sessions are open. If the answer is more than you can review today, stop starting new ones. A WIP limit makes that rule explicit.

Knowing which session did what

Git records commits, not sessions. If two sessions commit to the same branch, or you commit an agent's work under your own name without a note, the history can no longer tell you which session made a change. Keep one branch per task and commit per task, and the branch becomes the session's record.

Do not rely on agents to identify themselves. A line in a commit message saying which agent wrote it is a label someone typed, not proof. Process IDs are not much better on their own: operating systems reuse them, so an ID seen this afternoon may belong to something else tonight. In development builds of BRAIN FLUID, a launched agent is recorded by process ID, creation time and executable path together, and a reused process ID is treated as a different process that is never killed [D5]. The general lesson applies anywhere: identity needs more than one attribute.

Save what the session printed if you may need it later. A final summary that scrolls away is gone; a saved log file named after the task is evidence you can return to. Run history and reports covers what is worth keeping.

Closing the loop when a session ends

Treat the end of every session as a small checklist. Read the agent's final message. Run git status in the worktree and look at the diff. Run the task's check yourself. Then update the ledger with one of three states: ready for review, needs another session, or abandoned. Write the next step in one line while you still remember it.

A session that ended is not a task that finished. The agent may have stopped because it believed it was done, because it hit a limit, or because it crashed. Only the check and your review say which.

Sessions that died abruptly need extra care. If a terminal was closed or the computer restarted mid-run, you may not know which edits landed. Do not simply rerun the same prompt: inspect the working tree first, decide what to keep, and start a new session from that known state. Recovering interrupted agent work walks through this.

Finally, close the terminal. An idle window that looks active is how forgotten sessions pile up, and the next morning you will not know whether it is safe to type into.

QUESTIONS

How many AI coding agent sessions should I run at once?

As many as you can review the same day, which for most people is fewer than they can start. Each session produces a diff that someone has to read and check. If finished sessions are already waiting for review, starting another adds to the queue rather than to progress. Pick a number, write it down and stop starting sessions when you reach it.

Should each AI agent terminal use its own Git worktree?

For write sessions, yes. A worktree per task keeps each agent's edits, test runs and build output separate, so one session's half-finished work cannot break another's tests. Read-only planning or review sessions can share a checkout because they do not change it. Name the worktree and its branch after the task, and remove both after the merge.

What should I do when an agent terminal crashes mid-task?

Do not rerun the same prompt straight away. Look at the working tree first: git status and git diff show which edits landed. Decide whether to keep, finish or discard them, commit or reset to a known state, and record what happened. Then start a fresh session from that state with the task text and a note on what the crashed session had done.

RELATED GUIDES

• How to find and organize work across projects
• How to read BRAIN FLUID reports and provenance

RELATED HARNESS PAGES

• multi-agent project coordination Multi-agent project coordination: keep Claude and Codex work on one project organized with shared cards, scope, authority and review.
• WIP limits for AI agent work WIP limits for AI agent work: why agents make starting too easy, and why the limit belongs on review capacity rather than on running sessions.
• Recovering interrupted AI agent work Recovering interrupted AI agent work: inspect what was written, check what is still running, refuse blind replays and resume with a fresh authorization.
• agent run history and reports Agent run history and reports: what to record about AI agent runs, how to read usage coverage honestly and where unknown differs from zero.
• Switching a task between Claude Code and Codex Switching a task between Claude Code and Codex mid-way: what carries over, what stays behind in the old session, and a handoff checklist.