Содержание

Agent view в Claude Code (открывается командой claude agents) — это место, где вы одну за другой запускаете независимые сессии в фоне и управляете ими с одного экрана. В официальной формулировке этот режим позволяет «диспетчеризовать множество сессий Claude Code с одного экрана и управлять ими» (Manage multiple agents with agent view).

Эта статья держится механики и модели безопасности. Настоящая опасность здесь не в том, что «ИИ пойдёт вразнос», а в том, что вы выстраиваете десяток сессий, не понимая, докуда достаёт изоляция и с какими правами они работают, пока вы на них не смотрите. Если коротко: изоляция сделана по-настоящему аккуратно, но три вещи из неё утекают наружу. Вот на это и стоит потратить внимание.

📌 Откуда взяты эти факты: всё описанное ниже поведение, номера версий и названия настроек сверены с официальной документацией по состоянию на 9 августа 2026 года. Agent view — это research preview, для него нужна версия Claude Code v2.1.139 или новее. Предварительные функции меняются, поэтому проверьте свою сборку командой claude --version, а детали — по актуальной документации.

🔀 Если вы пришли сюда по запросу «Dispatch». У Claude есть две разные функции с обманчиво похожими названиями. Dispatch в боковой панели десктопного приложения — это функция, которая позволяет написать Claude со смартфона, чтобы он выполнил работу на вашем собственном компьютере, и статья не о ней — про неё есть отдельный разбор: как устроен Dispatch и насколько он безопасен. Эта же статья — про agent view, терминальную функцию Claude Code: названия пересеклись потому, что официальная документация называет выполняемую там операцию словом «dispatch».

1. Что такое agent view — операция, которую документация называет «dispatch»

Сначала закрепим название. Внутри Claude Code «dispatch» — это название операции, которую вы выполняете в agent view, а не отдельная функция с таким именем. Вот как это формулирует официальная документация.

«Agent view, открываемый командой claude agents, — это единый экран, показывающий все ваши фоновые сессии: что выполняется, что ждёт вашего ввода и что уже завершилось» (Agent view)

Не менее ясно документация говорит и о том, когда за этим стоит тянуться: когда у вас есть несколько независимых задач, вы хотите их передать, видеть их состояние одним взглядом и вмешиваться только там, где без вас не обойтись. Починка бага, ревью пул-реквеста, разбирательство с нестабильным тестом — забросьте эти три вещи тремя строками, продолжайте свою работу в другом окне и загляните туда, когда строка перейдёт в состояние «нужны вы».

✅ Работа, которая сюда подходит

Задачи, независимые друг от друга, за ходом которых не нужно следить. Работа, где достаточно получить результат в конце, а вы тем временем занимаетесь чем-то другим.

❌ Работа, которая не подходит

Всё, где направление приходится переопределять по ходу дела, всё, что дерётся за одни и те же файлы, и всё, что содержит необратимое действие (деплой, боевая база, отправка чего-либо наружу).

2. Один промпт равен одной сессии, а не дополнению к предыдущей

Первое, на чём здесь спотыкаются. Документация проговаривает это прямым текстом: каждый введённый здесь промпт запускает собственную новую сессию. Введёте второй промпт и нажмёте Enter — получите вторую сессию рядом с первой, а не дополнительное указание к первой.

По привычке обычного чата пишете «ещё кое-что по предыдущей задаче» — и вы не добавили примечание, а добавили работу. Это не сбой, а замысел: agent view для того и существует, чтобы выстраивать независимые задачи в ряд. Когда вам действительно нужно послать дополнительное указание, вы отправляете его из панели быстрого просмотра, о которой ниже.

Действие Что происходит
Промпт в поле ввода → Enter Запускается одна новая сессия (они копятся параллельно)
Space Открывает панель быстрого просмотра. Вы видите последний вывод или вопрос, ответа на который она ждёт, а не всю переписку
Ответ в панели быстрого просмотра → Enter Отвечает этой сессии, не покидая agent view
→ или Enter (при выделенной строке) Входит в эту сессию (подключение)
Ctrl+X Останавливает. Нажмёте ещё раз — удалит (отсюда прямая дорога к ловушке из раздела 6)
Ctrl+S / Ctrl+T / Ctrl+R Группировка (по состоянию или по каталогу) / закрепление / переименование

И ещё одно: subagents и участники команды, которых сессия породила сама, отдельными строками не появляются. Экран перечисляет только те единицы, которые диспетчеризовали вы.

3. Как устроена изоляция — сессия уходит в worktree до того, как начнёт писать

Вот где живёт модель безопасности. Фоновая сессия переходит в собственный git worktree раньше, чем отредактирует хоть один файл. Официальное описание звучит так.

«Любая фоновая сессия стартует в вашем рабочем каталоге — неважно, запущена она из agent view, командой /bg или claude --bg. Перед редактированием файлов Claude переносит сессию в изолированный git worktree внутри .claude/worktrees/. Благодаря этому параллельные сессии читают один и тот же checkout, но каждая пишет в свой собственный» (Agent view)

Работает этот замысел за счёт того, что чтение общее, а запись разделена. Параллельные сессии могут читать код друг друга, так что их представления о происходящем не расходятся, а вот записи столкнуться уже не могут. Три сессии в одном каталоге, затирающие файлы друг друга, — худший вариант такой аварии — становятся структурно невозможными.

И дальше идёт фраза, которая важнее всего. «Как только сессия оказалась в worktree, Claude Code блокирует правки файлов и команды, которые дотянулись бы до основного checkout, — и для самой сессии, и для любого subagent, которого она породит». Изоляция наследуется потомками. Если диспетчеризованная сессия вызовет внутри себя пять subagents, все пять окажутся за той же стеной.

4. Три проверки, на которых держится изоляция

Что именно означает «блокирует», в документации расписано конкретно. Проверок три вида.

1. Правки файлов

Блокируются Edit, Write и NotebookEdit, нацеленные на путь внутри основного checkout.

2. Рабочий каталог команды

Блокируются команды, чей рабочий каталог разрешается в основной checkout, и команды, про которые нельзя проверить, что они останутся снаружи.

3. Перенаправление git

git -C, --git-dir, GIT_DIR, GIT_WORK_TREE, cd перед вызовом git — всё это отсекается.

То, что закрыт и третий пункт, — признак серьёзной работы. Это уже не просто «не пиши в main», а ещё и «не обманывай git, заставляя его смотреть на main». И решение принято в пользу безопасности: команда, которую нельзя проверить, не выполняется.

⚠️ При этом стеной уровня ОС здесь и не пахнет. Три проверки работают через разбор того, что запрашивает вызов инструмента, а не через изоляцию процесса. Защищают они основной checkout того же репозитория, а файлы за пределами репозитория и сеть не входят в область действия ни одной из трёх.

Документация также прямо указывает, что к командам PowerShell применяется только проверка 2, про рабочий каталог. Если PowerShell — ваша основная оболочка в Windows, на третью защиту не рассчитывайте. Изоляция самого процесса — задача не worktree, а песочницы.

5. Откуда берутся разрешения

Пока вы не смотрите, в каком режиме разрешений работает эта сессия? Выстраивать сессии в ряд, не имея ответа на этот вопрос, — самое опасное, что здесь можно сделать.

Официальное правило однозначно. Когда вы диспетчеризуете из поля ввода agent view или запускаете claude --bg из оболочки, берётся defaultMode из настроек этого каталога. Если вы диспетчеризовали subagent, вместо него берётся permissionMode из его фронтматтера.

Иначе говоря, разрешения не выбираются на месте — они наследуются из вашей конфигурации. Чем свободнее ваш обычный defaultMode в settings.json, тем буквальнее становится утверждение: в момент диспетчеризации возникают десять беспризорных сессий с широкими правами. Привести в порядок режимы разрешений и правила разрешений — не приятное дополнение, а предварительное условие.

Впрочем, там, где остановиться нужно, всё останавливается как следует. Когда сессии требуется то, что можете дать только вы: ответ на вопрос, решение по разрешению, следующее указание, строка переходит в состояние «Needs input». Это состояние — единственная точка контроля, которая у вас осталась. Поэтому agent view — не «экран, где всё выставили и ушли», а «экран, на который возвращаются, чтобы разобрать строки, ждущие ввода».

6. Ловушки, которые легко не заметить

Изоляция сделана аккуратно. И всё же три вещи из неё утекают. Вот эта часть и кусается в реальной работе.

1. Согласие «больше не спрашивать» уходит за пределы worktree

Согласно документации, выбор варианта «Да, больше не спрашивать» для Bash-команды в сессии внутри worktree сохраняет это правило в .claude/settings.local.json основного checkout. В результате оно действует и в основном checkout, и во всех остальных worktree, и переживает удаление того worktree, в котором было принято.
То есть одно решение о разрешении, принятое в изолированном месте, становится постоянной настройкой за его пределами. Нажатое «больше не спрашивать», пока вы не смотрели, внутри того, что вы считали временной площадкой, действует с этого момента всегда. Не хватайтесь за «больше не спрашивать» бездумно, когда панель быстрого просмотра диспетчеризованной сессии спрашивает у вас разрешение.

2. Удаление сессии уносит с собой незакоммиченную работу

Это сказано без обиняков в официальном списке ограничений: «Созданные Claude worktree удаляются вместе с сессией, когда вы удаляете её в agent view. Коммитьте изменения, прежде чем удалять сессию, которая редактировала файлы в собственном worktree».
Ctrl+X — это остановка на первое нажатие и удаление на второе. Нажмёте дважды, прибираясь за завершённой сессией, — результат уйдёт вместе с ней. «Завершено» и «забрано» — не одно и то же: получив результат, закоммитьте или влейте его до удаления.

3. .worktreeinclude раздаёт ваши секреты каждому worktree

Worktree — это свежий checkout, поэтому попавшего в gitignore .env в нём нет. А без него ничего не запускается, поэтому вы вписываете его в .worktreeinclude, и он копируется автоматически при каждом создании нового worktree.
Удобно — но, если перевернуть, это значит, что на диск ложится по одной лишней копии ваших учётных данных на каждую диспетчеризованную сессию. Если вы гоняете это параллельно, разумно раздавать ключи для разработки, а не боевые.

Официально перечислены ещё три ограничения. Квота расходуется мультипликативно («запуск десяти агентов параллельно расходует вашу квоту примерно в десять раз быстрее, чем один»). Сессии выполняются локально — они переживают спящий режим, но выключение машины их останавливает. И, наконец, сам факт того, что это research preview.

7. Что из этого выбрать — способов распараллелить четыре

Официальная документация раскладывает распараллеливание на четыре подхода. Dispatch (agent view) — лишь один из них, так что выбрать не тот — прямой убыток.

Подход Кто всем распоряжается Когда выбирать
Subagents Claude делегирует внутри одного диалога и забирает результат Вы не хотите, чтобы вывод побочной работы (результаты поиска, логи, файлы) засорял основной контекст
Agent view (dispatch) Вы передаёте задачу и заглядываете позже Несколько независимых задач. Эта статья. Research preview
Команды агентов Claude планирует, распределяет и надзирает Вы хотите, чтобы разделение труда и синхронизацию взяли на себя. Экспериментально, по умолчанию отключено. Разобрано в отдельной статье
Динамические рабочие процессы План держит скрипт Аудит всей кодовой базы, миграция на 500 файлов — масштаб, которым не порулить за один ход. И когда результаты надо перепроверять между собой

Разделительная линия — кто всем распоряжается. Если укладывается в один диалог — subagents. Если распоряжаетесь вы, а забираете потом, — agent view. Если распоряжаться должен Claude — команды агентов. Если масштаб требует фиксированной процедуры, а не решений по обстановке, — динамические рабочие процессы.

Worktree, кстати, позиционируется не как способ распараллелить, а как инструмент изоляции. Agent view пользуется им автоматически. Для параллельных сессий, которые вы запускаете сами, worktree называется явно — например, claude --worktree <имя>.

8. Порядок работы, при котором это безопасно

Перед диспетчеризацией

  • Проверьте defaultMode для этого каталога. Он дословно станет уровнем прав сессии, за которой никто не следит
  • Не передавайте работу, содержащую необратимые действия. Деплой, боевая база и отправка наружу — дело сессии, за которой вы наблюдаете
  • Действительно ли задачи независимы? Если они висят на одном и том же проектном решении, сначала примите его, а потом передавайте
  • Что лежит в вашем .worktreeinclude? Ваши ключи копируются по разу на каждую выстроенную сессию

Пока они работают

  • Возвращайтесь за строками «Needs input». Это единственная точка контроля
  • Когда у вас спрашивают разрешение, не выбирайте «больше не спрашивать». Это решение переживёт worktree
  • Параллелизм ложится напрямую на квоту. Десять сразу расходуют её в десять раз быстрее

После завершения

  • Коммитьте до удаления. Второе нажатие Ctrl+X удаляет, и содержимое worktree уходит вместе с ним
  • Не принимайте результаты на веру. Всё, что вы запустили параллельно, добавило по одному непроверенному утверждению

Последний пункт заслуживает того, чтобы выделить его как эмпирическое правило. Распараллеливание увеличивает суммарный объём проверки. Десять задач возвращаются с десятью вопросами «а так ли это на самом деле»; проверка вместе с работой не распараллеливается. Потолок числа диспетчеризуемых задач задаётся тем, сколько результатов вы способны проверить.

Итоги

Dispatch — это запуск независимой фоновой сессии из agent view (claude agents), и это research preview (версия v2.1.139 или новее). Один промпт становится одной сессией, а не продолжением предыдущей.

Ядро модели безопасности — изоляция через worktree. Перед записью сессия переходит в .claude/worktrees/, и с этого момента чтение общее, а запись разделена. Правки, команды и перенаправления git, которые дотянулись бы до основного checkout, отсекаются тремя проверками, и эта защита наследуется каждым subagent, которого породит сессия.

Но три вещи из изоляции выбираются наружу. Согласие «больше не спрашивать» сохраняется на основной стороне, действует во всех worktree и переживает удаление worktree. Удаление сессии уничтожает незакоммиченную работу. .worktreeinclude копирует ваши секреты по разу на каждый worktree. А поскольку worktree — не стена уровня ОС, всё за пределами репозитория и сеть остаются без защиты: это уже задача песочницы.

FAQ

Q1. Есть ли в Claude Code функция, которая так и называется — «Dispatch»?

Как самостоятельного названия функции — нет. Dispatch — это название операции внутри agent view. Официальная документация описывает agent view как функцию, позволяющую «диспетчеризовать множество сессий Claude Code с одного экрана и управлять ими». Открывается командой claude agents.

Q2. /agents и claude agents — это одно и то же?

Нет. Документация предупреждает об этом напрямую: несмотря на похожее название, /agents — это не claude agents. claude agents — команда оболочки, открывающая agent view. А /agents, начиная с версии v2.1.198, вообще не открывает никакой панели — она просто сообщает, где лежат файлы определений ваших subagents.

Q3. Может ли диспетчеризованная сессия сломать мою основную рабочую копию?

Что касается основного checkout того же репозитория — вы защищены структурно. Правки файлов, рабочие каталоги команд и перенаправления git блокируются тремя проверками, и та же защита распространяется на любого subagent, которого породит сессия. При этом файлы за пределами репозитория и сеть в область действия не входят, а в PowerShell применяется только проверка рабочего каталога.

Q4. Что параллельный запуск делает со стоимостью?

Она растёт примерно пропорционально количеству. Официальный список ограничений говорит ровно это: запуск десяти агентов параллельно расходует вашу квоту примерно в десять раз быстрее, чем один. «В фоне» не означает «дёшево».

Q5. Можно ли удалять сессию, когда она закончила?

Сначала коммит, потом удаление. В документации сказано, что созданные Claude worktree удаляются вместе с сессией, когда вы удаляете её в agent view. Ctrl+X останавливает на первое нажатие и удаляет на второе. Получить результат — это ещё не забрать его к себе.

Q6. Можно ли выбирать режим разрешений при каждой диспетчеризации?

На месте — нет. Берётся defaultMode из настроек этого каталога, а если вы диспетчеризовали subagent — permissionMode из его фронтматтера. Если ваш обычный defaultMode свободный, именно эта свобода и будет работать без присмотра. Пересмотрите настройки разрешений до того, как начнёте пользоваться диспетчеризацией.

Q7. Чем это отличается от subagents?

Разница в том, кто распоряжается. В случае subagents Claude делегирует внутри одного диалога и возвращает результат в этот же диалог. В agent view независимые задачи передаёте вы, а результаты забираете потом. Порождённые сессией subagents отдельными строками в agent view не показываются.

Q8. Что будет, если я закрою ноутбук?

Они остановятся. Официальный список ограничений говорит, что фоновые сессии выполняются на вашей машине: они переживают спящий режим, но выключение машины их останавливает. В облаке ничего не крутится, так что это не тот инструмент, чтобы перебросить длинную задачу через забор и уйти домой.

Похожие статьи