Claude Code's agent view: dispatch, peek and reply without opening a terminal per session

If you already run several Claude Code sessions in parallel, you know the real cost isn’t the agents. It’s the tab-hunting: which terminal was waiting on a permission prompt, which one finished twenty minutes ago. Agent view is Claude Code’s answer, and it’s worth setting up properly. It’s a research preview, and the docs say it needs v2.1.257 or later.

Dispatch

Open it with claude agents. Type a prompt at the bottom and press Enter, and you get a new background session named from the prompt. The same thing works from a shell:

claude --bg --name "auth-fix" "fix the flaky refresh-token test"

Mid-session, /background (or /bg <prompt>) pushes the current conversation out of your terminal. /fork copies it to the background and lets you keep going in the original, which is handy when you’ve built up context and want two attempts at the same problem.

The triage loop

Each row shows a state: working, needs input, idle, completed, failed or stopped. Sessions are grouped so that anything waiting on you sits above anything still working.

Press Space on a row to peek at the latest output or question without opening the transcript, and type a reply right there. If the session is working, your reply queues. If it’s waiting on you, it lands immediately. A decent rhythm is: dispatch three or four tasks, do something else, then work down the “needs input” group.

The catch: permission prompts, sandbox requests and other dialogs can’t be answered from peek. You have to attach (Enter or the right arrow), answer, and detach with the left arrow. Detaching never stops the session.

To find things later, type a filter into the input. s:blocked lists everything waiting on you, and s:blocked a:reviewer narrows that to sessions running a subagent named reviewer.

Where the files go

This is the part to understand before you dispatch five tasks at one repo. According to the docs, a dispatched session moves into its own git worktree under .claude/worktrees/<name>/ before it first edits a file, so parallel sessions don’t collide. Two exceptions matter: a session you backgrounded with the left arrow or /background keeps editing the original checkout, and a session already inside a linked worktree uses that one. If you want no isolation at all, set worktree.bgIsolation to none in .claude/settings.json, and then you own the collision risk. For the manual version of the same idea, see our piece on --worktree .

When a task finishes, the docs say Claude commits and pushes, and opens a draft PR where appropriate. It won’t push to main or master, force-push or merge. If your team has stricter rules, put them in the task prompt or CLAUDE.md, since the docs say Claude follows git instructions from either.

Three ways to lose work or money

Deleting a session from agent view removes its worktree, uncommitted changes included. Commit first, or use claude rm, which keeps a worktree that has uncommitted changes.

Idle sessions stop after about an hour. Pin a session with Ctrl+T if you want its process kept alive. The conversation stays on disk either way.

Usage adds up. Per the docs, background sessions draw on your subscription usage independently, so ten parallel sessions burn quota roughly ten times as fast. Four well-scoped tasks beat ten vague ones.

Scripting it

claude agents --json prints your sessions as a JSON array with a state field (working, blocked, done, failed or stopped) and, for blocked sessions, a waitingFor field. The docs tell you to use this rather than reading the files under ~/.claude/jobs/, which aren’t a stable interface. Since 2.1.290, claude attach and claude logs accept partial session names, so claude logs auth is enough to read what the auth-fix session last said.

Start with one habit: dispatch tasks that each end in a draft PR, and review those PRs the way you’d review a colleague’s.