← Writing

Claude Code Agent View: managing parallel agents without leaving the terminal

I spent months managing many Claude Code agents by hand. Agent View now does it: my terminal-native workflow with Warp and Neovim, and the gaps I patch.

I work with several Claude Code agents in parallel every day. For months the hard part wasn't getting them running, it was not losing track of them: no screen told me which sessions were alive, or in what state.

So I built my own. A command to recover conversations by their directory. A directory of symlinks to start sessions in any repo. A skill to prepare worktrees. My own answers to gaps Claude Code didn't cover.

Then Agent View arrived: a single screen for every agent, showing what's running, what's waiting on you, and what's finished. Exactly the gap I'd spent months covering on my own.

My take: it was essential, it just shipped and it shows, and it's heading the right way. This article doesn't list its features; that's in the Agent View tip. Here I cover how I actually use it, in a fully terminal-based workflow, and the gaps I'm still dealing with.

What Agent View is

claude agents opens a screen with all your background sessions, grouped by state: the ones waiting on you at the top, then the ones working, and the finished ones at the bottom. A supervisor process keeps them alive even if you close the view or the terminal. You can review a session without entering it, reply to it, or open it in full.

That's the essential part. For the full tour of keys and commands, there's the tip. And to place Agent View against the other ways of sending Claude Code to the background (headless, /loop, Routines), the background agents map sorts it out. Don't confuse it with the Tasks panel: Tasks shows what happens inside one session; Agent View shows all your sessions from the outside.

Claude Code Agent View in 3 points: one screen for every agent with claude agents inside the terminal, a terminal-native workflow with Warp and Neovim, and the gaps I patch with /color, cs, ~/workspace and bgIsolation

My read

It was an obvious gap. There's a whole genre of third-party apps trying to fill it: Conductor and the like, dashboards for orchestrating several agents at once. Most are built on Electron (Crystal being the clear example) and they're a separate application, with the usual care Electron apps get, which isn't quite Visual Studio Code's.

Agent View does the same thing inside the terminal, without leaving your harness. To me that's the difference: I don't depend on an external tool that might disappear or start charging tomorrow, and it gets updates from the same team that builds Claude Code.

There's one sore point worth stating plainly, because it cost me time. Agent View's documentation, in an area where Anthropic is usually excellent, falls short. It's a complex feature and I had to read it several times to understand how the pieces fit. Part of why the gaps below are surprising is that the documentation doesn't explain them well.

One clarification, so I don't overstate it: when I say "without leaving the ecosystem," I mean the agent-management layer. My terminal is Warp, not an Anthropic app. Agent View runs inside Warp. It's not "all Anthropic," it's "all in the terminal."

My stack: everything in the terminal

My terminal is Warp, and in day-to-day use it's well ahead of the rest, for me. It recently went open source (April 2026, AGPL license), so the telemetry concern loses force: the code can be inspected now. Its AI-agent integration is first-rate.

Neovim runs on top of it, so I never leave the terminal. Warp already includes enough multiplexer features for me, so I don't need a separate tmux. With that setup, claude agents isn't one more tool to switch windows for: it's the screen I run work from, in the same place I write code.

The gaps and my workarounds

This is what the article adds over the tip: every gap I've run into, and how I handle it.

Finding and recovering sessions

This was my biggest problem with Claude Code well before Agent View: conversations belong to a directory. To recover one, you had to go to that directory and start it from there. If you didn't remember where you began it, you lost the trail.

Agent View helps, though not entirely. You can filter by state (s:working, s:blocked), by agent (a:<name>), or by PR (#<number>), but there's no search by name or content. With four or five agents on the table, finding the one you want takes time.

My visual fix is /color. From inside each conversation, /color tints the prompt bar a color (red, blue, green, yellow, purple, orange, pink, cyan), so I tell sessions apart at a glance without reading names.

My deeper fix is a command I built before any of this: cs, for "Claude session." It's a session browser on top of fzf: fuzzy search across all my conversations and every profile (I keep a personal one and a work one, and cs sees both). You pick one and it resumes in its original directory. It's a rough, earlier version of Agent View, with no supervisor and none of the rest, but it does something Agent View still doesn't: search by text and resume any conversation, not just the backgrounded ones. They're complementary, not substitutes.

@repo needs a parent directory

One of the most useful features: you type @ and a repository name, and a new session starts inside it. The catch is that it only works if you opened claude agents in a directory that contains that repo. If your repositories are spread across the disk, like mine, it doesn't help.

My fix is somewhat handmade: a ~/workspace directory with symlinks to the two folders where most of my repos live. I open Agent View there and can use @ with any of them. It has an intermittent side effect: sometimes it shows the workspace path instead of the symlink's target. I hope they fix it.

(You can also narrow the list with claude agents --cwd <dir>, or launch straight from the shell with cd <dir> && claude --bg "<task>".)

Entering and leaving sessions

To bring an open conversation into the view: /bg (alias of /background), or press on an empty prompt, which backgrounds it and opens the view in one step.

To take it out, watch one confusing detail. Ctrl+X stops the session; Ctrl+X again within two seconds deletes it. A stopped session stays in the list, greyed out, until you delete it; hence the "I hit stop and it won't go away" feeling: it did stop, it's just still listed on purpose. And detaching (, Ctrl+Z, /exit) stops nothing; to end a session from inside it, use /stop.

When the exit hangs

A minor detail that cost me time. You leave a session with , but sometimes, if a dialog has focus, doesn't respond and it seems to freeze. The definitive exit is Ctrl+Z. It's documented, though it's easy to run into before you read it.

Worktrees my way

By default, Agent View isolates each session in its own git worktree, and it does so lazily: it creates the worktree right before editing files. It's a reasonable choice for running work in parallel without sessions colliding.

I turn it off. In .claude/settings.json:

{
  "worktree": {
    "bgIsolation": "none"
  }
}

With this, background sessions edit your working copy directly, without moving into a worktree. I create them myself, on demand, with my own skill (worktree-setup) that runs on Haiku, a simple model, and leaves the worktree ready to boot: it links dependencies, copies configuration, and generates a .worktreeinclude, the file (Claude-Code-only) that determines which gitignored files, your .env for example, get copied into the new worktree.

If you want to replicate it, here's the gist of the skill (it runs on Haiku):

---
name: worktree-setup
description: Prepare a worktree for development and ensure the project can run
model: haiku
disable-model-invocation: true
argument-hint: "<branch-name>"
allowed-tools: Read, Bash, Glob, Grep, Write, EnterWorktree
---

1. Ensure you're in a worktree (git worktree list; if not, EnterWorktree).
2. Make it runnable: read .gitignore and .env; for each missing gitignored
   resource, symlink (deps), copy (config), or create (dirs).
3. Verify with the project's smoke check; on failure, fix and repeat.
4. Generate a .worktreeinclude listing what you copied, for future worktrees.
5. Report: stack, what was linked/copied/created, and whether it boots.

Why by hand? Because, in my view, parallelizing is for agents, not for humans. But that's material for another article.

Closing

What I really take away is this: the level of abstraction keeps rising. With a good system, good planning, and good infrastructure, more and more implementation details stop needing a human supervising them one by one. Agent View is, at heart, an interface for that direction: stop watching each terminal and start directing a set of agents.

It's still far from polished, but it's moving the right way. And if Claude Code is your main harness, like mine, you won't give this up. I stay in the terminal, with Warp and Neovim, and let Agent View bring order to what I used to handle on my own.

Free guide

51 tips to master Claude Code.

One page per tip. Five chapters. What I actually use daily in production — no theory, no fluff.

  • I. Getting started 10 tips
  • II. Awareness 3 tips
  • III. Mastery 22 tips
  • IV. Autonomy 10 tips
  • V. Comparison 6 tips
Are you a professional Web developer?

You'll receive the guide by email · You join the Gravitas newsletter · Unsubscribe anytime

of 51
#

Wmedia · 51 Tips
Free guide · 51 tips · 5 chapters

51 tips to master Claude Code.

Are you a professional Web developer? · Unsubscribe anytime