Claude Code grows a fleet console

Agent view is shipping in v2.1.139. It's not a UI tweak — it changes what "running Claude Code" means.

3 min

For two years, "running Claude Code" has meant attaching one terminal to one session. The new agent view, shipping in v2.1.139, breaks that 1:1 assumption — and the upgrade isn't a UI tweak, it's a different default.

claude agents opens a single screen listing every background session under your config directory. Rows show what each session is doing right now, whether it needs your input, and what's already finished. You dispatch new sessions from the same screen, peek at any of them with Space, type a quick reply without leaving the table, and only attach the full terminal when one genuinely needs you. Sessions persist on disk and survive your terminal closing.

The shift this enables is the interesting part. Claude Code used to be a thing you talked to. Agent view turns it into a fleet you supervise.

The unit of work moves up

If you've used tmux for the same purpose — five panes, five claude invocations, mental tracking of which one needs you — you already know the cost. The constraint isn't the model; it's that you have to keep five concurrent conversations in your head. Most people don't, so they don't run five sessions. Agent view removes the cognitive overhead by surfacing only what each session needs.

The signal-design is doing a lot of work here. Each row carries two pieces of information packed into one glyph: an indicator color for what state the session is in, and an icon shape for whether the underlying process is still resident in memory. A green is a finished session whose process is still live; a green is the same, but the supervisor has reaped the process and will restart it on demand the next time you attach. You learn the icons once and never have to read the state column again.

Haiku-generated summaries are the killer feature

The row description in agent view — "Edit src/physics/CollisionSystem.ts", "needs input: double jump or wall climb?" — is auto-generated by a small Haiku-class model at most once every 15 seconds, plus once when each turn ends. This is the thing that makes the screen scannable. Without it you'd be staring at a list of session names and timestamps with no idea what any of them are actually doing.

It's also a tell about how the team thinks about cost. The summaries are cheap enough to run on every agent's turn but throttled enough that you don't pay for them while a session is mid-tool-call. This is exactly the right place to spend cents on a smaller model to save dollars of your attention.

The supervisor changes the deployment model

Background sessions aren't child processes of your terminal. They're owned by a per-user supervisor that starts itself the first time you background anything and keeps a roster at ~/.claude/daemon/roster.json. Close your terminal, log out and back in, let the auto-updater swap the binary underneath you — your sessions are still there. The supervisor watches the binary on disk and reparents itself across upgrades. Background sessions are detached processes, so they ride through the restart and reconnect cleanly on the other side.

The one boundary the supervisor can't cross is your laptop going to sleep. Sessions stop on sleep or shutdown, and you re-hydrate them with claude respawn --all. For a local-first tool that's the correct call; the alternative is renting a managed cloud session, which Claude Code on the web already does separately.

Worktree isolation makes parallel safe

The reason five Claude sessions used to be a bad idea is that the second one would step on the first one's file edits. Agent view fixes this by automatically moving any background session that needs to write into its own .claude/worktrees/<id>/ git worktree, while still letting it read the original checkout. Parallel agents can now happily edit overlapping files without trampling each other; you merge or push the worktree branches you want to keep, and the worktree is reaped when you delete the session.

The block only applies to writes inside the working directory — a session that wants to drop a binary into your scratch dir still can. This is a behavioral fix to a problem that previously required developer discipline, and it's what makes the whole feature actually shippable.

What changes downstream

Two implications worth pulling on.

The first is that "I dispatched it to think about that" becomes a normal sentence among Claude Code users. The CI-style PR rows in agent view — each one showing check status as the dispatched session finishes — pull the workflow toward dispatching on commit-time intent and reviewing at merge-time. Whether that's good is a different question. But the friction to try working that way just dropped to zero.

The second is that anyone building tools on top of Claude Code now has a primitive to lean on. claude --bg "<prompt>" returns a session ID immediately. Cron jobs, shell scripts, GitHub Actions runners — none of them previously had a polite way to ask Claude Code to go off and think. They do now.

If this is what shipping under the "research preview" label looks like, the v2.x default is going to be interesting.

Written by

More to read

  • Coming soon

    This is LLMs Blog, a brand new site by a-x-c that's just getting started. Things will be up and running here shortly, but you can subscribe in the meantime if you'd like to stay up to date and receive emails when new content is published!

    1 min