Índice

O agent view do Claude Code (aberto com claude agents) é o lugar onde você inicia sessões independentes uma atrás da outra em segundo plano e as gerencia a partir de uma única tela. Nas palavras oficiais, ele permite "despachar e gerenciar muitas sessões do Claude Code a partir de uma só tela" (Manage multiple agents with agent view).

Este artigo fica no mecanismo e no modelo de segurança. O perigo real não é "a IA sair do controle" — é enfileirar dez sessões sem saber até onde o isolamento alcança nem sob quais permissões elas estão rodando enquanto você não está olhando. A versão curta: o isolamento foi construído com cuidado de verdade — mas três coisas vazam dele. É essa parte que merece a sua atenção.

📌 De onde vêm estes dados: cada comportamento, número de versão e nome de configuração abaixo foi conferido na documentação oficial em 9 de agosto de 2026. O agent view é um research preview e exige o Claude Code v2.1.139 ou posterior. Recursos em preview mudam, então confira a sua própria build com claude --version e confirme os detalhes na documentação atual.

🔀 Se você chegou aqui procurando por "Dispatch". O Claude tem dois recursos diferentes com nomes confusamente parecidos. O Dispatch do painel lateral do aplicativo de desktop é o recurso que permite mandar uma mensagem ao Claude pelo celular e fazer com que ele trabalhe no seu próprio computador, e não é sobre ele que este artigo trata — esse está coberto em como o Dispatch funciona e o quanto ele é seguro. Este artigo é sobre o agent view, um recurso de terminal do Claude Code; os nomes colidem porque a documentação oficial chama de "dispatch" a operação que você executa ali.

1. O que é o agent view — a operação que a documentação chama de "dispatch"

Vamos primeiro fixar o nome. Dentro do Claude Code, "dispatch" é o nome de uma operação que você executa no agent view, e não um recurso separado que se chama assim. Veja como a documentação oficial coloca a coisa.

"O agent view, aberto com claude agents, é uma única tela que mostra todas as suas sessões em segundo plano — o que está rodando, o que está esperando pela sua resposta e o que já terminou." (Agent view)

A documentação é igualmente clara sobre quando recorrer a ele: quando você tem várias tarefas independentes, quer entregá-las, quer ver o estado delas de relance e quer intervir só quando for necessário. Uma correção de bug, uma revisão de PR, uma investigação sobre um teste instável — jogue essas três como três linhas, siga com o seu próprio trabalho em outra janela e vá olhar quando uma linha virar "precisa de você".

✅ Trabalho que combina com ele

Tarefas independentes entre si e que você não precisa acompanhar em andamento. Trabalho em que receber o resultado no fim já basta, e você pode estar fazendo outra coisa enquanto isso.

❌ Trabalho que não combina

Qualquer coisa cuja direção precise ser redecidida no meio do caminho, qualquer coisa que dispute os mesmos arquivos e qualquer coisa que contenha uma ação irreversível (um deploy, o banco de produção, enviar algo para fora).

2. Um prompt equivale a uma sessão, não a um complemento

Essa é a primeira coisa que pega as pessoas de surpresa. A documentação soletra: cada prompt que você digita aqui inicia uma nova sessão própria. Digite um segundo prompt, aperte Enter e você ganha uma segunda sessão ao lado da primeira, não uma instrução extra somada a ela.

Digite "mais uma coisa sobre aquela última" por reflexo de conversa comum e você não acrescentou uma observação — você acrescentou um trabalho. Isso é projeto, e não acidente, porque o agent view existe justamente para enfileirar tarefas independentes. Quando você de fato quiser mandar uma instrução adicional, mande pelo painel de espiada, descrito abaixo.

Ação O que acontece
Prompt na caixa de entrada → Enter Inicia uma nova sessão (elas se acumulam em paralelo)
Space Abre o painel de espiada. Você recebe a saída mais recente ou a pergunta pela qual ela está esperando, não a transcrição inteira
Responder no painel de espiada → Enter Responde àquela sessão sem sair do agent view
→ ou Enter (com uma linha selecionada) Entra naquela sessão (attach)
Ctrl+X Para a sessão. Aperte de novo e ela é excluída (o que leva direto à armadilha da seção 6)
Ctrl+S / Ctrl+T / Ctrl+R Agrupamento (por estado ou por diretório) / fixar / renomear

Mais uma coisa: os subagents e os teammates que uma sessão gera para si não aparecem como linhas separadas. O que a tela lista são apenas as unidades que você despachou.

3. Como funciona o isolamento — ele muda para um worktree antes de escrever

É aqui que mora o modelo de segurança. Uma sessão em segundo plano se muda para um git worktree próprio antes de editar qualquer arquivo. A descrição oficial é a seguinte.

"Toda sessão em segundo plano começa no seu diretório de trabalho, tenha ela sido iniciada pelo agent view, por /bg ou por claude --bg. Antes de editar arquivos, o Claude move a sessão para um git worktree isolado dentro de .claude/worktrees/. Assim, sessões paralelas leem o mesmo checkout, mas cada uma escreve no seu." (Agent view)

O que faz esse desenho funcionar é que as leituras são compartilhadas e as escritas são separadas. Sessões paralelas conseguem ler o código umas das outras, então as premissas delas não se afastam, enquanto as escritas não podem colidir. Três sessões rodando no mesmo diretório e sobrescrevendo os arquivos umas das outras — a pior versão desse acidente — é estruturalmente impossível.

E então vem a frase que mais importa. "Depois que uma sessão está em um worktree, o Claude Code bloqueia as edições de arquivo e os comandos que alcançariam o checkout principal — tanto para aquela sessão quanto para qualquer subagent que ela gere." O isolamento é herdado pelos filhos. Se uma sessão despachada chamar cinco subagents internamente, os cinco estão dentro do mesmo muro.

4. As três verificações que sustentam o isolamento

A documentação é específica sobre o que "bloqueia" significa. São três tipos de verificação.

1. Edições de arquivo

Bloqueia Edit, Write e NotebookEdit apontados para um caminho dentro do checkout principal.

2. Diretório de trabalho do comando

Bloqueia comandos cujo diretório de trabalho resolve para o checkout principal e comandos que não dá para verificar que ficam fora dele.

3. Redirecionar o git

git -C, --git-dir, GIT_DIR, GIT_WORK_TREE, um cd antes do git — todos são cortados.

Fechar o terceiro caso é sinal de trabalho sério. Não é só "não escreva no principal", é também "não engane o git para que ele aponte para o principal". E a decisão é tomada pelo lado seguro: um comando que não pode ser verificado não roda.

⚠️ Dito isso, isto não é um muro no nível do sistema operacional. As três verificações funcionam inspecionando o que uma chamada de ferramenta está pedindo, e não confinando um processo. O que elas protegem é o checkout principal do mesmo repositório, e arquivos fora do repositório, além da rede, não estão no escopo de nenhuma das três.

A documentação também afirma sem rodeios que comandos do PowerShell recebem apenas a verificação 2, a do diretório de trabalho. Se o PowerShell é o seu shell principal no Windows, não conte com a terceira proteção. Confinar o próprio processo não é tarefa do worktree, e sim do sandbox.

5. De onde vêm as permissões

Enquanto você não está olhando, sob qual modo de permissão aquela sessão está rodando? Enfileirar sessões sem uma resposta para essa pergunta é a coisa mais perigosa que dá para fazer aqui.

A regra oficial não deixa margem. Quando você despacha pela caixa de entrada do agent view, ou roda claude --bg a partir de um shell, é usado o defaultMode das configurações daquele diretório. Se o que você despachou foi um subagent, é usado o permissionMode do frontmatter dele.

Em outras palavras, as permissões não são escolhidas na hora; elas são herdadas da sua configuração. Quanto mais frouxo for o seu defaultMode habitual no settings.json, mais literalmente verdadeiro fica que no momento em que você despacha nascem dez sessões sem supervisão e com permissões frouxas. Acertar seus modos de permissão e suas regras de permissão antes é pré-condição, não refinamento.

Onde deve parar, no entanto, ele para direito. Quando uma sessão precisa de algo que só você pode fornecer — uma resposta a uma pergunta, uma decisão de permissão, a próxima instrução —, a linha muda para "Needs input". Esse estado é o único ponto de controle que sobrou para você. É por isso que o agent view não é "uma tela onde você enfileira coisas e vai embora", e sim "uma tela à qual você volta para recolher as linhas que esperam por uma resposta".

6. As armadilhas fáceis de deixar passar

O isolamento é cuidadosamente construído. Mesmo assim, três coisas vazam dele. Esta é a parte que morde no trabalho real.

1. Uma aprovação do tipo "não pergunte de novo" sai do worktree

Segundo a documentação, escolher "Sim, não pergunte de novo" para um comando Bash em uma sessão dentro de um worktree salva essa regra no .claude/settings.local.json do checkout principal. O resultado: ela vale no checkout principal e em todos os outros worktrees, e sobrevive à remoção do worktree em que foi criada.
Ou seja, uma única decisão de permissão tomada dentro de um lugar isolado vira configuração permanente fora dele. Um "não pergunte de novo" apertado enquanto você não estava olhando, dentro do que você imaginava ser uma área de rascunho, vale dali em diante. Não recorra ao "não pergunte de novo" de forma leviana quando o painel de espiada de uma sessão despachada pedir permissão.

2. Excluir uma sessão leva junto o trabalho não commitado

Está dito às claras nas limitações oficiais: "Os worktrees criados pelo Claude são excluídos junto com a sessão quando você a exclui no agent view. Faça commit das suas alterações antes de excluir uma sessão que editou arquivos no worktree dela."
O Ctrl+X é parar no primeiro toque, excluir no segundo. Aperte duas vezes enquanto arruma uma sessão já terminada e o resultado vai embora com ela. "Terminado" e "recolhido" não são a mesma coisa — assim que tiver o resultado, faça commit ou merge antes de excluir.

3. O .worktreeinclude entrega os seus segredos a todos os worktrees

Um worktree é um checkout novo, então um .env ignorado pelo git não está nele. Como nada roda sem esse arquivo, você o lista no .worktreeinclude e ele passa a ser copiado automaticamente toda vez que um worktree novo é criado.
Conveniente — mas, virando do avesso, isso significa que mais uma cópia das suas credenciais cai no disco a cada sessão que você despacha. Se você roda essas coisas em paralelo, o sensato é distribuir chaves de desenvolvimento, não as de produção.

Outras três limitações constam da documentação oficial. A cota se esgota de forma multiplicativa ("rodar dez agentes em paralelo consome a sua cota cerca de dez vezes mais rápido do que rodar um"). As sessões rodam localmente — elas sobrevivem à suspensão, mas desligar a máquina as interrompe. E o próprio fato de que isto é um research preview.

7. Escolhendo entre eles — há quatro formas de paralelizar

A documentação oficial organiza a paralelização em quatro abordagens. O dispatch (agent view) é apenas uma delas, então escolher a errada custa caro sem disfarce.

Abordagem Quem conduz o trabalho Quando escolher
Subagents O Claude delega dentro de uma conversa e recolhe o resultado Você não quer que a saída do trabalho lateral (resultados de busca, logs, arquivos) polua o contexto principal
Agent view (dispatch) Você entrega e vai olhar depois Várias tarefas independentes. Este artigo. Research preview
Agent teams O Claude planeja, atribui e supervisiona Você quer que a divisão de trabalho e a sincronização sejam resolvidas por você. Experimental, desativado por padrão. Coberto em artigo próprio
Fluxos de trabalho dinâmicos Um script guarda o plano Uma auditoria da base de código inteira, uma migração de 500 arquivos — uma escala que nenhum turno único consegue conduzir. E quando os resultados precisam ser conferidos uns contra os outros

A linha divisória é quem conduz o trabalho. Se termina dentro de uma conversa, subagents. Se você conduz e recolhe depois, agent view. Se você quer que o Claude conduza, agent teams. Se a escala pede um procedimento fixo em vez de julgamento na hora, fluxos de trabalho dinâmicos.

Os worktrees, aliás, são posicionados não como uma forma de paralelizar, mas como uma ferramenta de isolamento. O agent view os usa automaticamente. Para sessões paralelas que você mesmo inicia, você nomeia um explicitamente, como em claude --worktree <nome>.

8. Uma rotina para rodar isso com segurança

Antes de despachar

  • Confira o defaultMode daquele diretório. Ele vira, ao pé da letra, o nível de permissão de uma sessão que ninguém está olhando
  • Não entregue trabalho que contenha ações irreversíveis. Deploys, o banco de produção e envios para fora pertencem a uma sessão que você está acompanhando
  • As tarefas são mesmo independentes? Se dependem da mesma decisão de projeto, resolva essa decisão primeiro e só então entregue
  • O que está no seu .worktreeinclude? Suas chaves são copiadas uma vez por sessão que você enfileira

Enquanto elas rodam

  • Volte para as linhas em "Needs input". Esse é o único ponto de controle
  • Quando pedirem permissão, não escolha "não pergunte de novo". Essa decisão sobrevive ao worktree
  • O paralelismo se converte diretamente em cota. Dez de uma vez consomem dez vezes mais rápido

Depois que terminam

  • Faça commit antes de excluir. O segundo Ctrl+X exclui, e o conteúdo do worktree vai junto
  • Não confie nos resultados de graça. Tudo o que você rodou em paralelo acrescentou mais uma afirmação não verificada

O último ponto merece destaque como regra prática. Paralelizar aumenta o volume total de revisão. Dez trabalhos voltam com dez perguntas do tipo "isso é mesmo verdade?" penduradas; a conferência não é paralelizada junto com o trabalho. O teto de quantos você despacha é definido por quantos resultados você consegue verificar.

Resumo

Dispatch é o ato de iniciar uma sessão independente em segundo plano a partir do agent view (claude agents), e é um research preview (v2.1.139 ou posterior). Um prompt vira uma sessão, nunca um complemento.

O coração do modelo de segurança é o isolamento por worktree. Antes de escrever, a sessão se muda para .claude/worktrees/, e a partir dali as leituras são compartilhadas enquanto as escritas são separadas. Edições, comandos e redirecionamentos do git que alcançariam o checkout principal são cortados por três verificações, e essa proteção é herdada por todo subagent que a sessão gerar.

Mas três coisas escapam do isolamento. Uma aprovação do tipo "não pergunte de novo" é salva do lado principal, vale em todos os worktrees e sobrevive à exclusão do worktree. Excluir uma sessão destrói trabalho não commitado. O .worktreeinclude copia os seus segredos uma vez por worktree. E, como um worktree não é um muro no nível do sistema operacional, tudo o que está fora do repositório e a rede ficam desprotegidos — isso é trabalho do sandbox.

FAQ

Q1. Existe mesmo um recurso chamado "Dispatch" no Claude Code?

Não como nome de um recurso autônomo. Dispatch é o nome de uma operação dentro do agent view. A documentação oficial descreve o agent view como o recurso que permite "despachar e gerenciar muitas sessões do Claude Code a partir de uma só tela". O comando que o abre é claude agents.

Q2. /agents e claude agents são a mesma coisa?

Não são. A documentação avisa diretamente sobre isso: apesar do nome parecido, /agents não é claude agents. O claude agents é o comando de shell que abre o agent view. Já o /agents, desde a v2.1.198, não abre mais painel nenhum — ele apenas informa onde ficam os seus arquivos de definição de subagents.

Q3. Uma sessão despachada pode quebrar a minha cópia de trabalho principal?

No que diz respeito ao checkout principal do mesmo repositório, você está protegido estruturalmente. Edições de arquivo, diretórios de trabalho de comandos e redirecionamentos do git são bloqueados pelas três verificações, e a mesma proteção cobre qualquer subagent que a sessão gere. Porém, arquivos fora do repositório e a rede estão fora do escopo, e no PowerShell só vale a verificação do diretório de trabalho.

Q4. O que rodar em paralelo faz com o custo?

Ele sobe mais ou menos em proporção ao número. As limitações oficiais dizem exatamente isso: rodar dez agentes em paralelo consome a sua cota cerca de dez vezes mais rápido do que rodar um. Segundo plano não significa barato.

Q5. Posso excluir uma sessão assim que ela terminar?

Faça commit primeiro, depois exclua. A documentação afirma que os worktrees criados pelo Claude são excluídos junto com a sessão quando você a exclui no agent view. O Ctrl+X para no primeiro toque e exclui no segundo. Ter recebido o resultado não é o mesmo que tê-lo incorporado.

Q6. Posso escolher o modo de permissão a cada dispatch?

Não na hora. É usado o defaultMode das configurações daquele diretório — ou, se você despachou um subagent, o permissionMode do frontmatter dele. Se o seu defaultMode habitual é frouxo, é essa frouxidão que roda sem supervisão. Revise as suas configurações de permissão antes de começar a usar o dispatch.

Q7. Qual é a diferença em relação aos subagents?

A diferença é quem conduz o trabalho. Com subagents, o Claude delega dentro de uma conversa e devolve o resultado àquela conversa. Com o agent view, você entrega tarefas independentes e recolhe os resultados depois. Subagents gerados por uma sessão não aparecem como linhas no agent view.

Q8. O que acontece se eu fechar o notebook?

Elas param. As limitações oficiais dizem que as sessões em segundo plano rodam na sua máquina: elas sobrevivem à suspensão, mas desligar a máquina as interrompe. Nada roda na nuvem, então esta não é a ferramenta para jogar um trabalho longo por cima do muro e ir para casa.

Artigos relacionados