/goal no Claude Code: modo autónomo e Agent View em 2026

Documentação de referência da Ailoot: ailoot.ai/docs/.

O que é o /goal no Claude Code?#

Anteriormente, o Claude Code parava após cada resposta e aguardava pelo seu próximo prompt. Isto funcionava para tarefas curtas, mas não para as longas: uma migração de API, corrigir 12 testes com falhas, refatorar um ficheiro de 800 linhas — estas tarefas exigem 20–30 iterações e, em cada uma, tinha de voltar ao terminal.

/goal resolve este problema com uma ideia simples: separar «quem faz o trabalho» de «quem decide que está concluído». O agente principal escreve código. Um avaliador separado (o modelo rápido Haiku) lê a conversa após cada turno e responde a uma pergunta: «A condição foi cumprida?» Se não, o agente inicia outro turno. Se sim, o controlo regressa a si.

A documentação oficial da Anthropic define-o assim:

Milhares de agentes a trabalhar durante a noite a partir de um telemóvel — não é marketing, é a prática atual de um engenheiro da Anthropic. E o mecanismo que o torna possível é a combinação de /goal + Agent View, lançada na mesma versão a 11 de maio de 2026.

Por que é necessário o modo autónomo: o que existia antes e depois de 11 de maio de 2026?#

A ideia de «deixar a IA trabalhar durante a noite» existia desde o outono de 2025, quando o Cursor Composer e o modo automático do Cline já conseguiam trabalhar em segundo plano. Mas, antes de 11 de maio de 2026, o Claude Code exigia um wrapper manual para isso: uma tarefa cron que chamava claude -p a cada N minutos ou um wrapper que observava o estado do git e lançava o prompt seguinte.

Esta abordagem caseira levava regularmente a desastres. A 22 de maio de 2026, um programador deixou um script desses a correr durante a noite e acordou com uma fatura de 6 000 $. A causa principal: a Anthropic alterou silenciosamente o TTL da cache do Claude Code de uma hora para cinco minutos, sem anunciar a mudança. O cron chamava o ambiente de produção a cada 30 minutos — a cache tinha tempo para expirar entre execuções. Cada execução reconstruía de raiz um histórico de 800 000 tokens. Escrever dados novos na cache custa muito mais do que lê-los enquanto a cache está ativa.

O programador não estava a fazer nada de invulgar — estava a usar a ferramenta exatamente como a Anthropic a anunciava.

O /goal resolve este problema com uma arquitetura integrada:

1. Processo supervisor que mantém a sessão fora do terminal e sobrevive ao fecho da janela e à entrada do portátil em suspensão.
2. Avaliador Haiku — um modelo económico verifica cada turno; os tokens do avaliador custam cêntimos.
3. Limite rígido de turnos na condição — pode escrever explicitamente or stop after 20 turns, e a sessão irá parar garantidamente.
4. Isolamento por worktree para sessões em segundo plano — as alterações vão para um ramo separado sem tocar na sua cópia de trabalho.

A diferença em relação à abordagem «escreva o seu próprio script bash» é que a Anthropic tornou todos estes mecanismos componentes de primeira classe da ferramenta, em vez de hacks de terceiros.

Como ativar o /goal em 3 passos#

Passo 1. Atualize o Claude Code para a versão 2.1.139 ou posterior.

Verifique a versão:

claude --version

Se for inferior à 2.1.139, atualize:

claude update
# or force it through npm
npm install -g @anthropic-ai/claude-code@latest

As versões lançadas entre 12 e 19 de maio de 2026 corrigiram erros importantes da primeira versão. Na versão 2.1.140, corrigiram um bloqueio silencioso em que disableAllHooks bloqueava o avaliador. Na versão 2.1.143, chegaram worktree.bgIsolation: "none" e uma correção para ciclos de stop hook. Na versão 2.1.144 (19 de maio), foram adicionados --resume para sessões em segundo plano e --json para agentes usados em scripts. A versão mínima é a 2.1.143.

Passo 2. Escreva /goal com uma condição.

Abra uma sessão normal do Claude Code e introduza o comando:

/goal todos os testes em test/auth passam e o linter não apresenta problemas, ou parar após 15 turnos

Não precisa de enviar um prompt separado depois — o comando inicia o primeiro turno imediatamente. A condição pode ser escrita em russo, inglês ou numa mistura; o modelo compreende ambos os idiomas. O limite de comprimento é de até 4 000 caracteres.

Passo 3. Acompanhe através da sobreposição em tempo real.

Depois de iniciar o /goal, surge um painel em tempo real na parte inferior do terminal:

/goal active · 3 turns · 12m elapsed · 18,400 tokens · last: tests in test/auth/login.test.ts still fail

O painel mostra:

• Turnos — quantos turnos foram concluídos
• Tempo decorrido — quanto tempo passou desde o início
• Tokens — total de tokens gastos (o principal valor a acompanhar para controlar o orçamento)
• Último — o último motivo dado pelo avaliador para dizer «ainda não»

Um truque útil: se o avaliador apresentar o mesmo motivo três turnos seguidos, é sinal de que entrou num ciclo. Prima Ctrl+C ou introduza /goal clear (sinónimos: stop, off, reset, cancel), reformule a condição e volte a iniciá-la. Os guias comunitários sobre o /goal apresentam esta regra como o principal sinal de ciclo: «preso no mesmo motivo três vezes — é um ciclo, saia».

Como escrever uma boa condição: 5 regras + 5 exemplos#

A documentação da Anthropic descreve três elementos necessários para uma boa condição:

Um modelo pronto a usar reúne os três elementos numa única linha:

\n/goal [execute o trabalho] até [estado final mensurável] sem [violar as restrições a respeitar]\n

Cinco regras que costumam apanhar a maioria das pessoas:

Regra 1. O estado final tem de ser verificável através de um comando, não do gosto pessoal.

Não «faz com que pareça bom», mas npm test exits 0. Não «melhora a UX», mas Lighthouse Performance score above 90. O avaliador lê apenas a transcrição — não executa comandos nem vê capturas de ecrã. Se o resultado não puder ser registado em texto, o avaliador nunca dirá «sim».

Regra 2. As restrições têm de ser explícitas e delimitadas.

Sem restrições, o Claude poderá corrigir os testes apagando-os ou comentando as asserções que falham. Especifique without modifying any file outside /auth, without removing existing assertions, without bumping major versions of dependencies.

Regra 3. É obrigatório definir um limite rígido de turnos.

Acrescente or stop after N turns a todas as condições. É uma proteção contra ciclos intermináveis. Sem um limite:

Sem um limite, um ciclo que dura uma hora pode gastar mais tokens do que executar a mesma tarefa manualmente. Inclua isso no orçamento.

Regra 4. Descreva O QUÊ, não apenas COMO.

Se não mencionar elementos visuais na condição, o Claude não os criará. Se a condição exigir apenas «os testes passam», o Claude poderá comentar testes complexos. Descreva O QUE pretende, não apenas COMO o vai verificar.

Regra 5. Peça ao Claude que apresente provas na conversa.

O avaliador não executa comandos — apenas lê aquilo que o Claude já apresentou. Se a condição exigir que «npm test passe», mas o Claude não mostrar na transcrição o resultado de npm test, o avaliador dirá «ainda não» para sempre. Acrescente à condição a frase «mostra o resultado de <command> na conversa».

Cinco exemplos funcionais para tarefas comuns:

1. Migração de API:
/goal todas as chamadas a getUser() foram substituídas por fetchUser(), npm test passa, npm run build está verde, nenhum outro nome de API foi alterado, ou parar após 30 turnos

2. Corrigir testes:
/goal todos os testes com falhas em test/auth passam agora (npm test mostra 0 falhas na conversa), sem alterar asserções nem eliminar testes, ou parar após 20 turnos

3. Qualidade do código (tamanho do ficheiro):
/goal src/legacy/UserService.ts foi dividido em ficheiros com menos de 200 linhas cada, todas as importações foram atualizadas, npm run build está verde, ou parar após 25 turnos

4. Resolver o backlog:
/goal processar cada issue com a etiqueta 'good-first-issue': ler a descrição, implementar uma correção num ramo worktree e abrir um PR. Continuar até a fila ficar vazia ou até terem sido processados 6 issues

5. Auditoria de segurança:
/goal todas as vulnerabilidades do npm audit com gravidade >= high foram corrigidas, todos os testes existentes passam, sem alterações incompatíveis da API, ou parar após 15 turnos

Quer fazer mais do que simplesmente executar o /goal e criar uma configuração em que o modo autónomo funcione realmente no seu projeto? O /goal é apenas o último elo. Antes dele, há três pilares a preparar: um clone de IA (a sua metodologia em Skills e Subagents), um segundo cérebro (CLAUDE.md e uma pasta plans/) e engenharia de contexto (Plan Mode e /compact). Os três componentes devem ser pensados em conjunto — é essa combinação que permite trabalhar com contexto.

5 exemplos em que o /goal funciona mesmo#

A documentação da Anthropic indica quatro tipos de tarefas para as quais o /goal é adequado:

Seguem-se cinco exemplos com condições prontas a usar — adapte-os ao seu projeto.

Exemplo 1. Migrar um módulo para uma nova API.

Cenário: está a passar de REST para GraphQL ou a substituir a antiga função getUser() pela nova fetchUser(). A tarefa é mecânica, mas abrange 30–50 ficheiros.

Condição:

/goal todos os getUser() em src/ foram substituídos por fetchUser(), todas as chamadas foram atualizadas para a nova interface (id em vez de userId), npm test passa, nenhum ficheiro fora de src/ foi alterado, ou parar após 30 turnos

Por que funciona: o estado final pode ser verificado com grep -r getUser src/ | wc -l (deverá ser 0) e npm test exits 0. A restrição protege os ficheiros de teste.

Exemplo 2. Corrigir testes com falhas.

Cenário: após uma atualização de biblioteca, 15 testes falharam. Sabe que a correção é mecânica — atualizar mocks e ajustar asserções ao novo formato. Não quer fazê-lo manualmente.

Condição:

/goal todos os testes com falhas em test/ passam agora, npm test apresenta os resultados na conversa com 0 falhas, sem eliminar testes nem comentar asserções, ou parar após 25 turnos

Outro exemplo de condição:

\nCorrija todos os testes com falhas até o npm test devolver 0, sem alterar qualquer ficheiro fora do diretório /auth\n

Exemplo 3. Dividir uma classe gigante.

Cenário: um ficheiro com 1 200 linhas contém tudo — o modelo, o serviço, os utilitários e o cliente de API. Quer dividi-lo de acordo com o princípio «um ficheiro, uma responsabilidade», atualizar todas as importações e manter os testes a passar.

Condição:

/goal src/legacy/UserService.ts foi dividido em ficheiros com menos de 200 linhas, cada ficheiro trata de uma responsabilidade (model, repository, api-client, validator), todas as importações estão atualizadas, npm run build está verde, os testes existentes passam, ou parar após 25 turnos

Exemplo 4. Resolver o backlog de issues durante a noite.

Cenário: tem um repositório open-source com 20 issues identificados com a etiqueta good-first-issue. Quer que o Claude os resolva ao longo da noite.

Condição:

/goal processar todos os issues identificados com 'good-first-issue': ler a descrição, implementar uma correção num ramo worktree-issue-N separado, abrir um PR com uma descrição. Continuar até a fila ficar vazia ou até terem sido processados 6 issues, ou parar após 80 turnos

O número 6 não foi escolhido ao acaso: é um limite realista para uma noite no plano Pro.

Exemplo 5. Auditoria de segurança.

Cenário: o npm audit indica 8 vulnerabilidades de gravidade elevada. Quer que o Claude as corrija sem atualizar versões principais.

Condição:

/goal todas as vulnerabilidades do npm audit com gravidade high+ foram corrigidas, npm audit mostra 0 high na conversa, todos os testes existentes passam, sem alterações incompatíveis da API, sem atualizações das versões principais dos packages, ou parar após 15 turnos

O que NÃO fazer com o /goal:

Croucher enuncia com veemência a regra prática no seu guia de campo: não use o /goal em tarefas em que «concluído» significa «parece bom», «parece certo», «bem concebido» ou «divertido». O avaliador só lê a transcrição — não executa ferramentas e não consegue avaliar como o resultado funciona. Esta regra exclui 80% das tarefas subjetivas em que o /goal entra num ciclo sem produzir resultados úteis.

Quando o /goal gasta dinheiro sem resultado: 3 padrões a evitar#

Padrão a evitar 1. Condição vaga sem limite rígido de turnos.

O erro mais comum é uma condição como «melhora o código» / «torna-o bom» / «otimiza-o». Sem limite de turnos, o agente continuará até esgotar a sua quota.

A Findskill descreveu um caso real:

Um programador relatou ter gasto 200 $ numa sessão de 14 horas com condições vagas: uma condição fraca que leva o avaliador a responder sempre «ainda não» pode resultar em 50, 100 ou 500 turnos antes de se aperceber.

200 $ gastos em 14 horas devido a uma condição vaga correspondem ao limite semanal completo do plano Max. Acorda de manhã sem quota e sem um resultado útil.

Salvaguarda: termine todas as condições com or stop after N turns (15 para tarefas fáceis, 50 para as difíceis e um máximo de 100 para execuções durante a noite).

Padrão a evitar 2. Ciclo recursivo com a cache avariada.

Um script que corria durante a noite acumulou uma fatura de 6 000 $ após a Anthropic alterar silenciosamente o TTL da cache de uma hora para cinco minutos. O programador não estava a usar diretamente o /goal, mas a lógica era a mesma: um ciclo autónomo com um temporizador cron de 30 minutos reconstruía de raiz um histórico de 800 000 tokens em cada execução.

O problema de fundo era a automatização externa desconhecer as alterações internas do fornecedor. O mesmo poderia acontecer com o /goal se o executasse durante 8 horas sem supervisão: a utilização de tokens aumenta de forma não linear e a cache de prompts pode não funcionar como pensa.

Salvaguardas:

1. Não execute o /goal durante 8 ou mais horas sem verificações intermédias.
2. Ative limites de utilização em Settings → Usage (uma nova salvaguarda após o incidente dos 6 000 $).
3. Abra claude agents duas vezes durante a noite — espreite com Space e confirme que o número de turnos não está a aumentar mais depressa do que o esperado.
4. Para cadeias de modelos dispendiosas (Opus 4.7), defina um limite de turnos mais rigoroso — 30 no máximo.

Padrão a evitar 3. Criatividade através do /goal.

Croucher usou o /goal para criar um jogo — a condição incluía determinismo, invariantes e a verificação de que era possível completar o nível. O jogo foi criado, os testes passaram e o avaliador declarou «alcançado». O jogo não tinha elementos visuais — a condição não mencionava gráficos.

Isto ilustra a regra geral: o avaliador otimiza exatamente aquilo que mede. Se a condição não mencionar os elementos visuais, eles não existirão. Se mencionar apenas testes, o agente poderá comentar as asserções.

Salvaguarda: não use o /goal em tarefas que dependam do gosto (design, texto, UX). Regresse a uma sessão normal ou ao Plan Mode — ambos mantêm a sua participação no processo de decisão.

O que é o Agent View e como abrir o painel#

Se o /goal é o comando «trabalha até terminar», o Agent View é a sala de controlo onde pode ver todos esses comandos ao mesmo tempo. A Anthropic descreve-o assim:

Comando para o abrir:

claude agents

Abre-se uma TUI — um painel de texto no terminal. A lista de sessões fica à esquerda e o painel peek, com a mensagem mais recente da linha selecionada, fica à direita.

Seis estados de sessão:

Atalhos principais:

↑ / ↓             percorrer a lista de sessões
Space             painel peek (ver sem se ligar à sessão)
Enter / →         ligar-se a uma sessão (entrar nela)
←                 desligar-se (sair sem a encerrar)
Ctrl+T            fixar (proteger a sessão contra paragem automática)
Ctrl+X            parar a sessão; prima novamente no espaço de 2 seg para a apagar
Ctrl+R            mudar o nome
Ctrl+S            alternar o agrupamento (estado ↔ diretório)

Como iniciar uma sessão em segundo plano:

A partir do Claude Code interativo:

/bg fix the failing test test/auth/login.test.ts

Ou diretamente na shell:

claude --bg "fix the failing test test/auth/login.test.ts"

Ou com um nome (para surgir no Agent View com uma etiqueta reconhecível):

claude --bg --name "flaky-test-fix" "fix test/auth/login.test.ts"

A sessão em segundo plano é adicionada automaticamente ao Agent View — inicie-a com --bg, abra claude agents e irá vê-la na lista.

A funcionalidade principal: as sessões sobrevivem à suspensão do portátil e ao fecho da janela:

No entanto, se desligar o portátil ou reiniciar manualmente, as sessões em segundo plano terminam com o estado Failed. As execuções noturnas com muitos agentes em segundo plano só funcionam num portátil que não seja desligado.

Worktrees: como o Claude isola sessões paralelas#

Os worktrees resolvem o principal problema do trabalho autónomo em paralelo: e se duas sessões tentarem editar src/auth.ts ao mesmo tempo? Antes da versão 2.1.139, essas sessões podiam literalmente substituir as alterações umas das outras. Com o Agent View, a Anthropic introduziu o isolamento automático:

Como funciona na prática:

# Iniciadas três sessões em segundo plano:
claude --bg --name "fix-tests" "fix the failing tests in test/"
claude --bg --name "add-oauth" "add Google OAuth according to the plan in plans/oauth.md"
claude --bg --name "split-userservice" "split UserService.ts into modules"

# Estrutura de ficheiros após o início:
.claude/worktrees/
├── fix-tests/             # cópia separada do repositório no ramo worktree-fix-tests
├── add-oauth/             # cópia separada no ramo worktree-add-oauth
└── split-userservice/     # cópia separada no ramo worktree-split-userservice

Cada sessão trabalha na sua própria cópia. Quando a tarefa estiver concluída, integra no main os ramos necessários.

Armadilha perigosa — apagar uma sessão apaga o respetivo worktree.

Se terminar uma sessão no Agent View (prima Ctrl+X duas vezes), o respetivo worktree desaparece. Perde todas as alterações sem commit. Antes de apagar uma sessão no Agent View, faça sempre commit ou envie as alterações.

Desativar o isolamento (para casos raros):

Se tiver um repositório em que os worktrees git não funcionam (por exemplo, uma configuração com symlinks ou um monorepo grande com um checkout lento), pode desativar o isolamento:

// .claude/settings.json
{
  "worktree": {
    "bgIsolation": "none"
  }
}

Nesse caso, as sessões em segundo plano irão editar diretamente a sua cópia de trabalho. Esta opção chegou na versão 2.1.143 após reclamações de equipas com monorepos grandes.

O paralelismo consome quota:

Isto significa que o plano Pro (20 $ por mês) é suficiente para 1–2 sessões paralelas durante a noite, mas não para dez. Para executar muitos agentes em paralelo, precisa de Max ou Enterprise.

Combinar /goal + Plan Mode + subagents em tarefas longas#

Uma falha típica é escrever imediatamente /goal build a new feature. Não funciona porque o avaliador não sabe o que significa uma «funcionalidade concluída». Precisa de um plano com caixas que o avaliador possa verificar, uma a uma.

Camada 1. O Plan Mode escreve um plano dividido em fases.

No Plan Mode, peça ao Claude que crie um plano de alterações detalhado, dividido em 5–7 fases com caixas de verificação verificáveis. Guarde-o como plans/2026-05-24-google-oauth.md. Cada fase tem 3–7 caixas com ações concretas.

Camada 2. Os subagents dividem o trabalho por fases.

Se for possível paralelizar o plano (por exemplo, se as fases forem independentes — um endpoint de backend + um formulário de frontend + uma migração de DB), pode iniciar cada fase numa sessão separada em segundo plano através de claude --bg --name "<phase>". Cada sessão recebe o seu próprio worktree.

Camada 3. O /goal executa o ciclo até as caixas estarem concluídas.

/goal todas as fases 1–7 em plans/2026-05-24-google-oauth.md estão concluídas e assinaladas com [x], todos os testes em test/auth passam (npm test mostra 0 falhas), npm run build está verde, ou parar após 50 turnos

Após cada turno, o avaliador lê o plano, verifica que caixas estão concluídas e, se ainda houver trabalho por fazer, o agente continua.

Esta combinação depende de três componentes:

• engenharia de contexto: o contexto certo em plans/ — o avaliador lê-o
• segundo cérebro: a pasta plans/ guarda o plano entre sessões
• clone de IA: o CLAUDE.md define as regras que o agente segue

Sem CLAUDE.md, o /goal pode sugerir uma solução que comprometa a arquitetura. Sem um plano em plans/, o avaliador não conhece os critérios de sucesso. Sem subagents, não existem fases paralelas; tudo decorre sequencialmente.

Como comparar /goal com Codex, Cursor e outros modos de agente#

/goal acrescenta uma verificação de conclusão após cada turno. Outros produtos têm modos diferentes; CLI local, tarefa alojada na nuvem e sessão supervisionada no editor não são unidades equivalentes. Não descreva todo o Codex CLI como contentor na nuvem nem assuma um único validador ou faturação para qualquer execução.

Use o mesmo estado do repositório, tarefa e verificações de aceitação. Registe para cada candidato:

Afirmar um múltiplo fixo de tokens exige essas condições e contagens medidas para o mesmo resultado bem-sucedido. Uma percentagem de benchmark também exige versão, modelo, executor e definições; percentagens Terminal-Bench sem esses detalhes não substituem essa evidência. O artigo não fornece benchmark independente entre ferramentas.

Escolha pelo método necessário: edições supervisionadas, tarefa delimitada em segundo plano ou vários turnos com conclusão explícita. Teste o modo suportado do produto instalado em vez de assumir ausência total de autonomia num concorrente. Separe aprovação de permissões da continuação: aprovar automaticamente uma ferramenta não prova o cumprimento do objetivo.

/goal vs /loop:

/loop é outro comando da mesma versão e lança tarefas periódicas a intervalos definidos (a cada N minutos). O /goal baseia-se numa condição (até esta ser cumprida). Utilize o /loop para tarefas semelhantes a cron e o /goal para alcançar objetivos específicos.

Da documentação da Anthropic:

Lista de verificação antes de iniciar o /goal: 7 itens#

Lista de verificação antes de cada execução do /goal:

1. Versão 2.1.139+ do Claude Code — verifique com claude --version e atualize se for inferior. A versão mínima recomendada é a 2.1.143 (15 de maio de 2026), que corrige ciclos de stop hook.

2. A condição inclui um estado final verificável — em vez de «melhora isso», especifique npm test exits 0. Se não conseguir encontrar um comando bash para verificar o resultado, o /goal não é adequado para esta tarefa.

3. Existe um limite rígido de turnos — todas as condições especificam or stop after N turns. Use 15 para tarefas fáceis, 50 para tarefas difíceis e, no máximo, 100 para execuções durante a noite.

4. As restrições são explícitas e delimitadas — without modifying files outside /auth, without removing existing assertions, without bumping major versions. Sem elas, o Claude pode corrigir os testes apagando os próprios testes.

5. Todas as alterações importantes foram guardadas em commit ou enviadas — se não estiver a trabalhar num worktree (por exemplo, com worktree.bgIsolation: "none"), o Claude edita a sua cópia de trabalho. Qualquer erro pode levar à perda de trabalho não guardado.

6. Os limites de utilização estão ativados em Settings → Usage — uma nova salvaguarda após o incidente dos 6 000 $. Defina um limite diário, por sessão e mensal.

7. O Agent View claude agents está aberto numa janela separada — em tarefas longas, use o peek com Space uma vez por hora. Se o número de turnos crescer mais depressa do que o esperado ou o avaliador repetir o mesmo motivo durante três turnos, prima Ctrl+C e reformule a condição.

Mais um item — nunca execute o /goal com --dangerously-skip-permissions em código de terceiros ou desconhecido. Essa combinação desativa todas as verificações e permite ao agente fazer o que quiser no seu projeto. O autor desta análise só o usa num worktree novo, onde nada há a perder.

O /goal é uma funcionalidade poderosa, mas não é magia. Funciona tão bem quanto conseguir formular a condição. Se conseguir descrever por palavras o que significa «concluído» de forma a que um comando o possa verificar, o /goal tratará do resto. Caso contrário, regresse a uma sessão normal ou ao Plan Mode.

Continue a explorar a Ailoot em ailoot.ai.