Running parallel coding sessions with Claude Code Agent View

Published 2026-05-14 by Owner

Agent View shipped in Claude Code on May 11 as a Research Preview. It solves a specific friction: when you’re running more than one Claude session, there was no consolidated way to see which ones needed your attention. You either watched each session in its own terminal tab or missed Claude’s prompts for input.

For context on what Agent View is and what was released, see Claude Code ships Agent View.

The problem it solves

The typical multi-session workflow before Agent View:

1. Start a Claude Code session on Task A
2. Reach a waiting point (Claude needs you to review something)
3. Open a new tab, start a session on Task B
4. Forget about Task A until you notice the tab title changed

The cost is context-switching overhead — you’re either babysitting sessions or missing progress. Agent View makes the state of every session visible in one place without requiring you to maintain the sessions in the foreground.

Starting your first background session

claude --bg "write unit tests for src/auth/token.ts covering expiry and refresh logic"

This starts a session immediately in the background. Claude begins working on the task. You get your shell back. The session ID is printed to stdout.

To see it in the list:

claude agents

You’ll see output like:

SESSION ID        STATUS          LAST MESSAGE                           TIME
sess_abc123       working         Analyzing token.ts structure...        0:42

Sending an existing session to the background

If you started a session normally (foreground) and want to background it without losing progress:

/bg

Type /bg inside the session. Claude continues working; you return to your shell. The session appears in claude agents with its current status.

Jumping back into a session

When a session shows waiting status in claude agents, Claude has reached a decision point and is blocked until you respond. To open it:

claude agents
# press Enter on the waiting session row to open it

You’ll see Claude’s last message and can respond. When you’re done, /bg it again or let Claude finish.

When parallel sessions actually help

Parallel sessions work well for:

• Independent tasks — running tests on one component while Claude writes code for another. No shared state, no ordering dependency.
• Long autonomous tasks — migrations, test generation for a whole module, refactoring a large file. These take long enough that waiting in the foreground is wasteful.
• Tasks with predictable waiting points — Claude writes a plan, waits for your approval, continues. Backgrounds cleanly at the wait.

Parallel sessions add friction for:

• Tasks that depend on each other — if Session B needs the output of Session A, running them in parallel doesn’t help and introduces coordination complexity.
• Exploratory or ambiguous tasks — Claude will hit unclear decision points more often and the back-and-forth is better handled in the foreground where you’re watching.
• Short tasks — anything under 5 minutes of Claude work. The overhead of setting up a background session and checking the list isn’t worth it. Just wait.

Checking in without interrupting

claude agents is read-only — looking at it doesn’t interrupt working sessions. You can run it as often as you want to check progress without affecting the sessions’ state. It’s the equivalent of glancing at a progress bar.

The four signals per row (ID, status, last message, timestamp) are usually enough to decide whether a session needs your attention. A session showing working with a recent timestamp and a sensible last message can be left alone. A session showing waiting for more than a few minutes has been blocked waiting for you.