Claude Code's agent view, and the two things it deliberately doesn't do

For most of the last year, "how do I keep track of six Claude Code sessions" was a question you answered yourself — with tmux, with a wall of terminal tabs, or with a naming scheme you forgot by Thursday.

That's no longer true. Claude Code ships a built-in dashboard, opened with claude agents, called agent view. It's free, it's part of the standard install, and it runs on Linux, macOS, Windows and WSL. If you're managing multiple sessions and haven't tried it, try it before you install anything else.

It's also, by design, not the whole problem. Worth being precise about where the line falls.

What agent view gives you

Agent view is a dashboard of background sessions, grouped by state. You dispatch new work from an input at the bottom, and the list shows you everything running:

• Needs input — sessions waiting on you, floated to the top
• Working — actively running tools or generating
• Ready for review — sessions with an open PR
• Completed — finished, failed, or stopped
• Pinned — high-priority sessions you want kept up

Each row carries a one-line summary of what that session is doing (generated by Haiku), an age counter, and a PR label where relevant. You navigate with arrow keys, press Space to peek at the latest output or a pending question, type a reply inline, press Enter to attach to the full conversation, and ← to detach again while it keeps running.

That is a genuinely good answer to "which of my agents needs me right now?" — the question that used to require alt-tabbing through twelve identical windows. And sessions keep running after you close the view.

Anthropic labels it a research preview, so expect the keys and layout to move around.

The first thing it doesn't do: talk to more than one session at a time

The documented loop is one session at a time: you select a row, press Space, and the reply you type goes to that session. The prompt box at the bottom isn't a broadcast either — as the docs put it, "every prompt you enter here starts its own new session" rather than sending a follow-up to a running one. There's no documented way to address several at once, so a message reaches exactly one session.

For dispatching independent work, that's correct behaviour — you don't want six agents receiving the same prompt when they're on six different tasks.

It stops being correct the moment your agents share a situation. git pull --rebase after you merge something they're all built on. "Stop what you're doing." "The API contract changed, re-read schema.ts before continuing." Those are one instruction with six recipients, and one-at-a-time means typing it six times, or typing it five times and forgetting the sixth — which is the failure that actually costs you, because the forgotten agent keeps confidently working against a stale assumption.

The shell approximation is a loop over tmux panes:

fleet() {
  for p in $(tmux list-panes -s -F '#{pane_id}'); do
    tmux send-keys -t "$p" "$*" Enter
  done
}

Crude, and it fires at everything, which is why in practice you want to address a named subset rather than "all". But it closes the gap for the three or four commands that are always safe.

The second thing: it's a list, not a view of the work

This is the subtler one, and whether it matters depends entirely on how you work.

Agent view compresses each session to a row and a one-line summary. That's the right compression when you dispatched five background tasks this morning and you're checking in on them — you want density, and you want the "needs input" ones surfaced.

It's the wrong compression when you're sitting in front of the agents while they work. Watching an agent's output scroll is how you catch it going down a wrong path in the second paragraph instead of the twentieth — before it's written four hundred lines you now have to read. A one-line summary can't carry that. Neither can peeking at one session at a time, because by the time you've peeked at the fifth, the first has moved on.

Two different jobs, then:

• Dispatching — fire off background work, come back later, review PRs. Agent view is built for this and costs nothing.
• Driving — six agents running, you watching, steering all of them. This wants live terminals side by side, and it wants one instruction to reach a chosen set.

Most people do both, at different times of day.

Two smaller gaps worth knowing about

Sessions don't survive a shutdown. Background sessions run on your machine. They're preserved across sleep, but they stop if the machine shuts down. If you close the lid and reopen tomorrow, you're fine; if you reboot, you're restarting from scratch. Worth knowing before you leave a long task running overnight through a software update.

It's Claude Code only. Reasonably enough — it's a Claude Code feature. But if your actual fleet is four Claude sessions, a Codex run and a npm run test:watch, agent view sees four of the six. The remaining two go back to being terminal tabs, and you're maintaining two mental models at once.

Which half do you have?

Straightforward test. Think about the last time you had five or more agents going, and ask what you were doing while they ran.

If the answer is "something else, and I checked back every twenty minutes" — you're dispatching. claude agents is the right tool and you're done; there's nothing to buy.

If the answer is "watching them, and pasting the same correction into each one" — you're driving, and you'll keep hitting both limits above every session. That's the shape of the problem Agent Tile was built for: live terminals tiled on one canvas, ⌘-click to select a set and type into all of them at once, and every session relaunched with --resume in its original directory when you reopen the app. It's macOS, and it ships as full Electron source, so the parts you don't like are yours to change.

Either way, run claude agents first. Knowing exactly which half of the job you have is worth more than any tool.