Contents

Claude Code's agent view (opened with claude agents) is the place where you start independent sessions one after another in the background and manage them from a single screen. In the official wording, it lets you "dispatch and manage many Claude Code sessions from one screen" (Manage multiple agents with agent view).

This article sticks to the mechanics and the safety model. The real danger is not "the AI going rogue" — it is lining up ten sessions without knowing how far the isolation reaches or what permissions they are running under while you are not watching. The short version: the isolation is built with real care — but three things leak out of it. That is the part worth your attention.

📌 Where these facts come from: every behaviour, version number and setting name below was checked against the official documentation as of 9 August 2026. Agent view is a research preview and requires Claude Code v2.1.139 or later. Preview features move, so check your own build with claude --version and confirm the details against the current docs.

🔀 If you came here searching for "Dispatch". Claude has two different features with confusingly similar names. Dispatch in the desktop app's side panel is the feature that lets you message Claude from your phone and have it work on your own computer, and it is not what this article is about — that one is covered in how Dispatch works and how safe it is. This article is about agent view, a Claude Code terminal feature; the names collide because the official documentation calls the operation you perform there "dispatch".

1. What agent view is — the operation the docs call "dispatch"

Let us pin the name down first. Inside Claude Code, "dispatch" is the name of an operation you perform in agent view, not a separate feature that goes by that name. Here is how the official documentation puts it.

"Agent view, opened with claude agents, is a single screen showing all of your background sessions — what is running, what is waiting on your input, and what has finished." (Agent view)

The docs are equally clear about when to reach for it: when you have several independent tasks, want to hand them off, want to see their state at a glance, and want to step in only when you have to. A bug fix, a PR review, an investigation into a flaky test — throw those three in as three rows, carry on with your own work in another window, and go look when a row turns into "needs you".

✅ Work that suits it

Tasks that are independent of one another and that you do not need to watch in progress. Work where receiving the result at the end is enough, and you can be doing something else meanwhile.

❌ Work that does not

Anything whose direction needs re-deciding halfway, anything that fights over the same files, and anything containing an irreversible action (a deploy, the production database, sending something outside).

2. One prompt equals one session, not a follow-up

This is the first thing that catches people out. The documentation spells it out: every prompt you type here starts its own new session. Type a second prompt and press Enter and you get a second session beside the first, not an extra instruction added to it.

Type "one more thing about that last one" out of ordinary chat reflex and you have not added a note — you have added a job. That is design rather than accident, because agent view exists to line up independent tasks in the first place. When you do want to send a further instruction, you send it from the peek panel, described below.

Action What happens
Prompt in the input box → Enter Starts one new session (they accumulate in parallel)
Space Opens the peek panel. You get the latest output or the question it is waiting on, not the full transcript
Reply in the peek panel → Enter Answers that session without leaving agent view
→ or Enter (with a row selected) Enters that session (attach)
Ctrl+X Stops it. Press it again and it deletes (which leads straight into the trap in section 6)
Ctrl+S / Ctrl+T / Ctrl+R Grouping (by state or by directory) / pin / rename

One more thing: the subagents and teammates a session spawns for itself do not appear as separate rows. What the screen lists is only the units you dispatched.

3. How the isolation works — it moves to a worktree before it writes

This is where the safety model lives. A background session moves into a git worktree of its own before it edits any file. The official description reads as follows.

"Every background session starts in your working directory, whether it was launched from agent view or with /bg or claude --bg. Before editing files, Claude moves the session into an isolated git worktree under .claude/worktrees/. That way parallel sessions read the same checkout but each writes to its own." (Agent view)

What makes this design work is that reads are shared and writes are separated. Parallel sessions can read each other's code, so their assumptions do not drift apart, while their writes cannot collide. Three sessions running in the same directory and overwriting each other's files — the worst version of this accident — is structurally impossible.

And then there is the sentence that matters most. "Once a session is in a worktree, Claude Code blocks file edits and commands that would reach the main checkout — both for that session and for any subagent it spawns." The isolation is inherited by the children. If a dispatched session calls up five subagents internally, all five are inside the same wall.

4. The three checks that hold the isolation up

The docs are specific about what "blocks" means. There are three kinds of check.

1. File edits

Blocks Edit, Write and NotebookEdit aimed at a path inside the main checkout.

2. Command working directory

Blocks commands whose working directory resolves to the main checkout, and commands that cannot be verified to stay outside it.

3. Redirecting git

git -C, --git-dir, GIT_DIR, GIT_WORK_TREE, a cd before git — all of them are cut off.

Closing off the third one is a sign of serious work. It is not just "do not write to main" but also "do not fool git into pointing at main". And the call is made on the safe side: a command that cannot be verified does not run.

⚠️ That said, this is not an OS-level wall. The three checks work by inspecting what a tool call is asking for, not by confining a process. What they protect is the main checkout of the same repository, and files outside the repository, plus the network, are not in scope for any of the three.

The docs also state plainly that PowerShell commands get only check 2, the working-directory one. If PowerShell is your main shell on Windows, do not count on the third protection. Confining the process itself is not the worktree's job but the sandbox's.

5. Where the permissions come from

While you are not looking, which permission mode is that session running under? Lining sessions up without an answer to that question is the most dangerous thing you can do here.

The official rule is unambiguous. When you dispatch from agent view's input box, or run claude --bg from a shell, the defaultMode from that directory's settings is used. If what you dispatched is a subagent, the permissionMode in its frontmatter is used instead.

In other words the permissions are not chosen on the spot; they are inherited from your configuration. The looser your usual defaultMode in settings.json, the more literally true it becomes that the moment you dispatch, ten unattended sessions with loose permissions come into being. Sorting out your permission modes and permission rules first is a precondition, not a nicety.

Where it should stop, though, it does stop properly. When a session needs something only you can supply — an answer to a question, a permission decision, the next instruction — the row changes to "Needs input". That state is the one control point you have left. Which is why agent view is not "a screen where you line things up and walk away" but "a screen you come back to in order to pick up the rows waiting on input".

6. The traps that are easy to miss

The isolation is carefully built. Even so, three things leak out of it. This is the part that bites in real work.

1. A "don't ask again" approval walks out of the worktree

According to the documentation, choosing "Yes, don't ask again" for a Bash command in a worktree session saves that rule to the main checkout's .claude/settings.local.json. The result: it applies in the main checkout and in every other worktree, and it survives the removal of the worktree it was made in.
So a single permission decision made inside an isolated place becomes permanent configuration outside it. A "don't ask again" pressed while you were not watching, inside what you thought was a scratch workspace, is in force from then on. Do not reach for "don't ask again" casually when a dispatched session's peek panel asks you for permission.

2. Deleting a session deletes the uncommitted work with it

It is stated outright in the official limitations: "Worktrees created by Claude are deleted along with the session when you delete it in agent view. Commit your changes before deleting a session that edited files in its own worktree."
Ctrl+X is stop on the first press, delete on the second. Press it twice while tidying up a finished session and the output goes with it. "Finished" and "collected" are not the same thing — once you have the result, commit or merge it before you delete.

3. .worktreeinclude hands your secrets to every worktree

A worktree is a fresh checkout, so a gitignored .env is not in it. Since nothing runs without one, you list it in .worktreeinclude and it is copied in automatically every time a new worktree is created.
Convenient — but turned around, it means one more copy of your credentials lands on disk for every session you dispatch. If you are running these in parallel, the sane thing is to hand out development keys, not production ones.

Three further limitations are listed officially. Quota drains multiplicatively ("running ten agents in parallel uses your quota roughly ten times as fast as running one"). Sessions run locally — they survive sleep, but shutting the machine down stops them. And the fact that this is a research preview at all.

7. Choosing between them — there are four ways to parallelise

The official documentation sorts parallelisation into four approaches. Dispatch (agent view) is only one of them, so picking the wrong one costs you plainly.

Approach Who runs the show When to pick it
Subagents Claude delegates within one conversation and collects the result You do not want side-work output (search results, logs, files) polluting the main context
Agent view (dispatch) You hand it off and go look later Several independent tasks. This article. Research preview
Agent teams Claude plans, assigns and supervises You want the division of labour and the syncing handled for you. Experimental, disabled by default. Covered in its own article
Dynamic workflows A script holds the plan A whole-codebase audit, a 500-file migration — a scale no single turn can direct. And when results have to be cross-checked

The dividing line is who runs the show. If it finishes inside one conversation, subagents. If you run it and collect later, agent view. If you want Claude to run it, agent teams. If the scale calls for a fixed procedure rather than on-the-spot judgement, dynamic workflows.

Worktrees, incidentally, are positioned not as a way to parallelise but as a tool for isolation. Agent view uses them automatically. For parallel sessions you start yourself, you name one explicitly, as in claude --worktree <name>.

8. A routine for running this safely

Before you dispatch

  • Check the defaultMode for that directory. It becomes, verbatim, the permission level of a session nobody is watching
  • Do not hand off work containing irreversible actions. Deploys, the production database and outbound sends belong in a session you are watching
  • Are the tasks genuinely independent? If they hang on the same design decision, settle that one first, then hand them off
  • What is in your .worktreeinclude? Your keys are copied once per session you line up

While they run

  • Come back for the "Needs input" rows. That is the only control point
  • When asked for permission, do not choose "don't ask again". That decision outlives the worktree
  • Parallelism maps directly onto quota. Ten at once drains it ten times as fast

After they finish

  • Commit before you delete. The second Ctrl+X deletes, and the worktree's contents go with it
  • Do not take the results on trust. Everything you ran in parallel added one more unverified claim

The last point deserves emphasis as a rule of thumb. Parallelising increases the total amount of reviewing. Ten jobs come back with ten "is that actually true?" questions attached; the checking does not get parallelised along with the work. The ceiling on how many you dispatch is set by how many results you can verify.

Summary

Dispatch is the act of starting an independent background session from agent view (claude agents), and it is a research preview (v2.1.139 or later). One prompt becomes one session, never a follow-up.

The heart of the safety model is isolation by worktree. Before writing, the session moves into .claude/worktrees/, and from there reads are shared while writes are separated. Edits, commands and git redirects that would reach the main checkout are cut off by three checks, and that protection is inherited by every subagent the session spawns.

But three things get out of the isolation. A "don't ask again" approval is saved on the main side, applies in every worktree, and survives deleting the worktree. Deleting a session destroys uncommitted work. .worktreeinclude copies your secrets once per worktree. And since a worktree is not an OS-level wall, anything outside the repository and the network is unprotected — that is the sandbox's job.

FAQ

Q1. Is there a feature actually called "Dispatch" in Claude Code?

Not as a standalone feature name. Dispatch is the name of an operation inside agent view. The official documentation describes agent view as the feature that lets you "dispatch and manage many Claude Code sessions from one screen". The command that opens it is claude agents.

Q2. Are /agents and claude agents the same thing?

They are not. The documentation warns about it directly: despite the similar name, /agents is not claude agents. claude agents is the shell command that opens agent view. /agents, since v2.1.198, no longer opens a panel at all — it just tells you where your subagent definition files live.

Q3. Can a dispatched session break my main working copy?

As far as the main checkout of the same repository goes, you are protected structurally. File edits, command working directories and git redirects are blocked by the three checks, and the same protection covers any subagent the session spawns. However, files outside the repository and the network are out of scope, and under PowerShell only the working-directory check applies.

Q4. What does running them in parallel do to cost?

It goes up roughly in proportion to the number. The official limitations say as much: running ten agents in parallel uses your quota roughly ten times as fast as running one. Background does not mean cheap.

Q5. Is it fine to delete a session once it has finished?

Commit first, then delete. The documentation states that worktrees created by Claude are deleted along with the session when you delete it in agent view. Ctrl+X stops on the first press and deletes on the second. Having received the result is not the same as having taken it in.

Q6. Can I choose the permission mode each time I dispatch?

Not on the spot. The defaultMode from that directory's settings is used — or, if you dispatched a subagent, the permissionMode in its frontmatter. If your usual defaultMode is loose, that looseness is what runs unattended. Review your permission settings before you start using dispatch.

Q7. How is this different from subagents?

The difference is who runs the show. With subagents, Claude delegates within one conversation and returns the result to that conversation. With agent view, you hand off independent tasks and collect the results afterwards. Subagents spawned by a session are not shown as rows in agent view.

Q8. What happens if I close my laptop?

They stop. The official limitations say background sessions run on your machine: they survive sleep, but shutting the machine down stops them. Nothing runs in the cloud, so this is not the tool for throwing a long job over the wall and going home.

Related articles