How to Manage and Review Multiple Agent Sessions

Running several coding agents at once is easy to start and hard to keep hold of. Within an hour you have five sessions, two of them stopped on a permission prompt you did not notice, one that finished and reported success, one still working, and one you cannot remember the purpose of. The work of parallel agents sits in knowing which one needs you, what each of them actually did, and whether the change is good enough to keep.

This guide covers that loop with concrete commands, for Claude Code and Codex, plus what a visual workspace changes about it.

Quick answer

• Name every session at the start. claude -n auth-refactor or /rename auth-refactor. An unnamed session is unfindable by hour three.
• Use a status view, not terminal tabs. claude agents groups sessions by state and puts the ones waiting on you at the top.
• Read the transcript, not just the diff. The commands an agent ran, and the approaches it tried and abandoned, exist only in the session record.
• Review scope before content. git diff main --stat and git status --short together tell you whether the agent stayed inside the task before you read a single line.
• Verify tests rather than believing them. A session summary saying the tests pass is a claim, not evidence.
• Cap concurrency at your review rate. Starting a sixth agent does not help if you cannot read five diffs.

Part 1: see which sessions are waiting on you

Sessions fail at different rates depending on whether you notice them. A session waiting on a permission prompt burns no tokens and makes no progress, and there is nothing in a terminal tab to tell you it has been sitting there for twenty minutes.

Claude Code

Agent view lists every session in one place, grouped by state:

claude agents          # open the view
claude agents --json   # structured output for scripts and status lines
claude attach <id>     # jump into a specific session

The states that matter are Needs input (waiting on your answer or a permission decision), Working, Idle, Completed, and Failed. Sessions needing input group at the top, and an attached session shows a footer hint such as ← 2 agents when others are waiting. Scanning that view every ten or fifteen minutes replaces the habit of alt-tabbing through terminal windows looking for a blinking cursor.

Background sessions run under a supervisor process rather than your terminal, so they survive closing the view. Their state lives at ~/.claude/jobs/<id>/state.json, which is what agent view reads.

Codex

Codex resumes recent chats from the current repository:

codex resume           # pick from recent sessions in this repo
codex resume --last    # reopen the most recent one

--last skips the picker, and --all widens it to include non-interactive codex exec runs, which the picker leaves out by default. A session can be resumed by its UUID or by its session name, and codex archive <session> clears finished ones out of the picker.

Inside a session, /status prints the current configuration, including the approval and sandbox settings that determine whether the session will stop and ask you or proceed on its own. If your Codex sessions rarely seem to need you, check /status before concluding they are going well.

Name sessions, or you will not find them

Both agents generate labels for unnamed sessions, and generated labels are fine for one session and useless for six. Name them:

Agent	At start	Mid-session
Claude Code	claude -n auth-refactor	/rename auth-refactor
Codex	Name the task in your first prompt so codex resume shows something legible	Start a new session with a clearer opening prompt

In Claude Code, a named session resumes directly by name with claude --resume auth-refactor, across worktrees of the same repository. In the /resume picker, Ctrl+W widens to every worktree of the repository, Ctrl+A widens to every project on the machine, and Ctrl+B filters to the current branch.

In a visual workspace

Nimbalyst puts each session on a kanban board with its status visible without attaching to anything, and alerts you when a session completes or hits a permission prompt. Sessions carry tags and group into workstreams, so ten sessions across three projects stay legible. Push notifications reach the iOS app when a session finishes or needs approval, which matters mainly because the alternative is discovering a stalled session an hour later.

Part 2: read what the agent actually did

A finished session gives you two artifacts: a summary it wrote about itself, and a diff. Neither tells you what happened. The summary is the agent’s account of its own work, and the diff is the end state with every wrong turn already erased.

What you usually want to know sits in between: which commands did it run, what did it try that did not work, and did it verify anything or just assert that it had.

The commands are in the transcript, not your shell history

The agent runs commands in its own process, so history in your shell shows nothing. In Claude Code, export the conversation, including tool calls and their output, as readable text:

/export                    # menu: copy to clipboard or save to a file
/export session-notes.txt  # write straight to a file

Transcripts are stored as JSONL at ~/.claude/projects/<project>/<session-id>.jsonl, where <project> is the working directory path with non-alphanumeric characters replaced by -. The line format is internal and changes between versions, so read it by eye when you need to and use /export or the scripted interfaces below when you need something durable.

Codex writes its session files under ~/.codex/sessions/, organised by date. For scripted work, codex exec --json emits newline-delimited JSON events instead of formatted text, which is the interface to build on rather than parsing the stored files.

Ask the finished session what it did

The cheapest summary is the one the session generates against its own full context:

claude -p --resume <session-id> --output-format json \
  "list every command you ran and every file you changed, with one line on why" \
  | jq -r '.result'

Treat the answer as a lead, not evidence. It is the agent describing itself, and it will occasionally describe work it intended rather than work it did. Its value is telling you where to look in the diff.

Three questions worth asking of any finished session

Did it stay inside the task? An agent asked to change the auth module that also edited the build config did something you have not been told about.

Did it verify, or assert? Look in the transcript for the test command and its output. A session that says “tests pass” without a visible test run has told you nothing.

Did it work around a problem instead of solving it? Deleted assertions, skipped tests, widened types, and new try/catch blocks around the failure are the common shapes. All of them are visible in the diff once you know to look, and none of them appear in a summary.

In a visual workspace

Nimbalyst keeps the full transcript per session alongside a sidebar listing every file that session read or wrote, so the jump from “what did it do” to “show me that file” is one click rather than a search through terminal scrollback. Transcripts are searchable across sessions, which is how you answer “which session touched this file last week” without reconstructing it from git.

Part 3: review the diff before you accept it

Review agent output in a fixed order. The order matters because the cheap checks eliminate most bad changes before you spend attention on reading logic.

Scope first

git diff main --stat     # tracked changes against your merge target
git status --short       # staged, unstaged, and untracked

Both commands, every time. git diff compares tracked content, so a file the agent created and left unstaged is invisible to it, and a new file is the change you least want to miss. Substitute your own merge target for main where the repository uses master, develop, or a release branch; without a local ref of that name git answers fatal: ambiguous argument.

You are checking one thing: does the file list match the task. A single-module task that touched twenty files is a finding on its own, and it is worth resolving before reading any content.

Then the changes that fail quietly

Read these before the logic, because they are the ones that break things far from where they were edited:

git diff main -- package.json package-lock.json   # new or bumped dependencies
git diff main -- '*.config.*' '*.env*'            # configuration
git diff main -- 'migrations/*' '*.sql'           # schema

New dependencies deserve a moment of scepticism. Agents add packages readily, and a package added to solve a five-line problem is worth questioning.

Then the logic

git diff main -- src/
git log main..HEAD --oneline --reverse    # commits unique to this branch, oldest first
git diff main --diff-filter=D --stat      # files removed outright

--oneline alone prints newest first, so add --reverse when you want to follow the order the agent actually worked in.

--diff-filter=D lists files the agent deleted in full. It does not surface deleted lines inside surviving files, which are the more common and easier-to-miss loss; those show up as red lines in the ordinary diff, and the --stat deletion counts are what tell you where to look.

Then confirm the tests

Run them yourself, from the merge target, after merging one branch:

git merge feat/auth-refactor
npm test

One branch at a time, tests between merges. Two agent branches that each pass alone can fail together, and attributing that is trivial when only one landed since the last green run.

Get a second opinion cheaply

Codex ships a non-interactive reviewer that reads the diff for you and reports back, without a session to steer:

codex review --base main        # everything on this branch against the merge target
codex review --uncommitted      # staged, unstaged, and untracked changes
codex review --commit <sha>     # one commit

Run it from inside the worktree. Use it as a first pass that flags where to look, not as the review itself, and be most interested in the objections you disagree with: a confident complaint about correct code usually means the code is unclear.

Risk-weight your attention

Not every change needs the same scrutiny. A rough split that holds up:

Read closely	Spot-check	Skim
Auth, permissions, payments	New feature code with tests	Formatting and imports
Deletions and schema changes	Refactors inside one module	Generated files
Dependency additions	Test changes	Documentation

The one exception is test changes. A refactor that also edits its own tests deserves a close read, because a passing suite that the agent adjusted to pass is worse than a failing one.

In a visual workspace

Nimbalyst shows every file a session changed with red/green inline diffs, file by file, with the session’s transcript still attached, so you can review and then commit without leaving the workspace. It covers non-code artifacts too, so a change to a markdown plan, a diagram, or a mockup gets the same review step as a change to a TypeScript file. The agent can also draft the commit message from the staged diff once you have accepted the change.

Part 4: accept, revert, or send it back

Three outcomes, and it helps to decide which one you are choosing before you start typing.

Accept. Merge the branch, run the tests, remove the worktree.

Send it back. Resume the session and give it the specific correction. Resuming keeps the context that produced the work, which is almost always cheaper than describing the whole problem again to a fresh session. claude --resume <name> or codex resume.

Try a different approach. In Claude Code, /branch copies the conversation so far and switches you into the copy, leaving the original intact, so you can attempt a second approach without losing the first. From the command line, claude --continue --fork-session does the same, and codex fork --last is the Codex equivalent. To step back inside one session rather than branching, Claude Code’s checkpointing rewinds code and conversation to an earlier point.

Throw it away. Delete the branch and the worktree. A session that went wrong early is usually cheaper to restart with a better prompt than to correct turn by turn.

A routine that holds up

Every fifteen minutes or so, in this order. It takes about two minutes once it is habit.

1. Check the waiting group. Anything in Needs input, answer it. Stalled sessions are pure waste.
2. Check what finished. For each completed session, read the --stat, then the transcript’s test output, then the diff.
3. Merge one thing. Merge a single reviewed branch, run the tests, and stop if they fail.
4. Clean up. Remove the worktree, delete the branch, and archive the session so it drops out of the resume picker (codex archive <session>, or archive the card in a session board).
5. Start the next one only if step 2 is empty. The queue of unreviewed finished sessions is the number to keep at zero, not the number of running agents.

The habit this replaces is starting a new session whenever you feel idle, which produces a pile of finished work nobody has read. Parallel agents pay off when the review keeps up with them and cost you when it does not.

Related reading

• How to run coding agents in parallel with git worktrees
• Best Claude Code session manager (2026)
• How to review AI code changes before applying
• How to track what your AI coding agent changed
• Claude Code kanban: best session boards