DEV Community

Cover image for Comando /goal: Como Executar Codex e Claude como Agentes Autônomos 24/7
Lucas
Lucas

Posted on • Originally published at apidog.com

Comando /goal: Como Executar Codex e Claude como Agentes Autônomos 24/7

Todos os principais laboratórios de IA lançaram a mesma primitiva nas últimas seis semanas: um comando /goal para executar agentes em loop fechado até que um estado final mensurável seja atingido. A Anthropic adicionou /goal ao Claude Code. A OpenAI lançou o recurso no Codex CLI e no aplicativo de desktop Codex. A Nous Research integrou o mesmo padrão ao Hermes. A interface é simples: você define um objetivo, o agente trabalha, valida o progresso e só volta quando termina, encontra uma restrição ou esgota o orçamento.

Experimente o Apidog hoje

Se você ainda faz o ciclo manual de “aprovar, enviar prompt, pedir para continuar, repetir”, /goal é o comando que remove essa etapa. Em vez de supervisionar cada iteração, você entrega um alvo verificável ao agente.

Este guia mostra como usar /goal de forma prática no Codex e no Claude Code, como escrever prompts que convergem e como aplicar o padrão em fluxos de API usando Apidog.

Baixe o Apidog gratuitamente se quiser acompanhar os exemplos de API.

O que /goal realmente faz

Em uma linha: /goal permite que um agente execute uma tarefa em loop até que uma condição de parada seja atendida, sem pedir sua aprovação a cada rodada.

O mecanismo é direto:

  1. O modelo principal executa uma etapa.
  2. Um modelo validador menor verifica se o objetivo foi atingido.
  3. Se não foi, o agente continua.
  4. Se foi, o loop termina e o agente reporta o resultado.

Na prática:

  • Sem /goal: você é o loop. Lê a saída, decide se está correta, pede o próximo passo e aprova chamadas de ferramenta.
  • Com /goal: o agente controla o loop. Ele planeja, executa, autovalida e só interrompe quando há conclusão, erro, restrição ou limite de orçamento.

Exemplo:

/goal create a landing page
Enter fullscreen mode Exit fullscreen mode

Isso pode acionar pesquisa, scaffolding, estilização, depuração e uma prévia final em uma única execução contínua.

Por que /goal apareceu em várias ferramentas ao mesmo tempo

Tarefas longas com agentes tendem a falhar por dois motivos:

  1. Desvio de objetivo: o modelo se afasta da tarefa original e entrega algo plausível, mas incorreto.
  2. Supervisão constante: mesmo quando o agente consegue fazer o trabalho, você precisa aprovar ou orientar cada iteração.

O validador reduz os dois problemas. Ele compara cada etapa com o objetivo original e fornece uma condição de parada mais rígida. O padrão não elimina a necessidade de revisão humana, mas diminui a quantidade de microgerenciamento.

Configurando /goal no Codex

O Codex CLI oferece controle direto sobre execução e aprovações.

1. Habilite objetivos no desktop

Abra o Codex desktop e vá em:

Settings → Configuration
Enter fullscreen mode Exit fullscreen mode

Defina:

goals = true
Enter fullscreen mode Exit fullscreen mode

O CLI herda essa configuração.

2. Inicie o CLI em modo automático 

codex --approval-mode full-auto
Enter fullscreen mode Exit fullscreen mode

Use esse modo apenas quando o escopo estiver claro e você confiar nas restrições definidas.

3. Defina o objetivo 

/goal [seu objetivo aqui]
Enter fullscreen mode Exit fullscreen mode

Exemplo:

/goal corrigir todos os testes falhando até que npm test retorne código 0 sem modificar arquivos fora de /auth
Enter fullscreen mode Exit fullscreen mode

O Codex registra o objetivo e começa a executar.

Captura de tela do Codex CLI com o comando /goal sendo usado para definir um objetivo.

Se preferir evitar o CLI, use o aplicativo de desktop Codex. A funcionalidade é semelhante, mas você ganha interface para pausar, limpar objetivos e observar uso de tokens.

Configurando /goal no Claude Code

No Claude Code CLI, o fluxo é parecido:

/goal [descrição da tarefa]
Enter fullscreen mode Exit fullscreen mode

A documentação oficial está no site de documentação do Claude Code.

Captura de tela do Claude Code CLI com o comando /goal sendo usado para definir um objetivo.

Se você encontrar erros de configuração ao iniciar o Claude Code, veja a correção para a configuração empresarial custom3p inválida. Para fluxos multiagentes com Claude Code e /goal, consulte a análise de Ruflo, uma camada multiagente sobre o Claude Code.

Dica prática: acompanhe a contagem de tokens. Se o agente consome muitos tokens sem progresso visível, o objetivo provavelmente está mal definido ou o validador não consegue convergir. Nesse caso, use:

/pause
Enter fullscreen mode Exit fullscreen mode

ou:

/goal clear
Enter fullscreen mode Exit fullscreen mode

Depois, reescreva o objetivo com critérios mais verificáveis.

A estrutura de prompt que funciona

A sintaxe de /goal é simples. O problema é escrever um objetivo que possa ser validado.

Um bom prompt tem três partes:

  1. Trabalho: o que deve ser feito.
  2. Estado final mensurável: como saber que terminou.
  3. Restrições: limites que não podem ser quebrados.

Modelo:

/goal [fazer o trabalho] até que [estado final mensurável] sem [restrições obrigatórias]
Enter fullscreen mode Exit fullscreen mode

Exemplo para código:

/goal consertar todos os testes falhando até que npm test saia com 0 sem modificar nenhum arquivo fora do diretório /auth
Enter fullscreen mode Exit fullscreen mode

Por que funciona:

  • npm test fornece um sinal verificável.
  • Código de saída 0 define conclusão.
  • /auth limita o escopo de alteração.

Evite objetivos vagos como:

/goal deixar a interface mais moderna
Enter fullscreen mode Exit fullscreen mode

Isso não tem critério objetivo. Reescreva como:

/goal melhorar a interface até que a pontuação de acessibilidade do Lighthouse seja 90+ sem alterar a navegação existente
Enter fullscreen mode Exit fullscreen mode

Estrutura avançada para tarefas maiores

Para trabalhos com mais de uma etapa, use blocos explícitos:

/goal
Objetivo: [objetivo em uma linha]

Critérios de sucesso:
  - [critério mensurável 1]
  - [critério mensurável 2]
  - [critério mensurável 3]

Restrições:
  - [limite 1]
  - [limite 2]

Contexto:
  - [arquivos relevantes]
  - [comandos de teste]
  - [documentação ou especificações]
Enter fullscreen mode Exit fullscreen mode

Exemplo:

/goal
Objetivo: implementar autenticação por refresh token.

Critérios de sucesso:
  - npm test retorna código 0
  - os testes de integração de /auth passam
  - o endpoint POST /auth/refresh retorna 200 para refresh token válido
  - o endpoint retorna 401 para token expirado ou inválido

Restrições:
  - não modificar arquivos fora de /auth e /tests/auth
  - não alterar o schema público de usuários

Contexto:
  - src/auth/*
  - tests/auth/*
  - openapi.yaml
Enter fullscreen mode Exit fullscreen mode

Esse formato ajuda o validador a verificar o progresso sem depender de interpretação subjetiva.

Exemplos úteis de /goal

Pesquisa 

/goal coletar todos os benchmarks públicos para Claude Opus 4.7 publicados desde abril de 2026, salvar as fontes e produzir uma tabela markdown ordenada por data até que a tabela cubra pelo menos 10 benchmarks distintos
Enter fullscreen mode Exit fullscreen mode

Manutenção de repositório 

/goal encontrar código morto, dependências não utilizadas e arquivos obsoletos neste repositório, então propor uma descrição de PR listando remoções seguras até que cada item tenha uma justificativa
Enter fullscreen mode Exit fullscreen mode

Documentação 

/goal reescrever README.md para que um novo colaborador possa instalar, executar, testar e entender o projeto até que cada um desses quatro passos tenha um comando funcionando e uma saída esperada
Enter fullscreen mode Exit fullscreen mode

Funcionalidade de frontend 

/goal adicionar um alternador de tema claro/escuro, persistir a escolha no localStorage, atualizar estilos para ambos os temas e verificar no navegador até que o alternador funcione sem recarregar a página e sobreviva a uma atualização
Enter fullscreen mode Exit fullscreen mode

O padrão é o mesmo: cada objetivo define uma condição de término verificável.

Usando /goal em fluxos de desenvolvimento de API

APIs são um bom caso de uso para /goal porque o estado final costuma ser testável:

  • a requisição retorna o status correto;
  • o schema de resposta corresponde ao contrato;
  • os casos de teste passam;
  • a documentação está sincronizada.

Um fluxo prático:

  1. Defina o contrato no Apidog

    Crie o endpoint, schemas de requisição e resposta, exemplos e casos de teste no Apidog.

  2. Exporte a especificação

    Use OpenAPI 3.x como contexto para o Codex ou Claude Code.

  3. Execute /goal com critério de teste

    Exemplo:

   /goal implementar o endpoint POST /users até que todos os testes do Apidog passem sem alterar o contrato OpenAPI
Enter fullscreen mode Exit fullscreen mode
  1. Use o runner de testes como validador A cada iteração, o agente executa os testes contra o serviço local. O objetivo só deve ser concluído quando todos os casos estiverem verdes.

Esse fluxo é melhor do que deixar o agente criar seus próprios testes, porque o contrato já está definido. O agente implementa contra uma especificação, não contra uma interpretação livre do requisito.

Se você ainda não usa o Apidog, a plataforma combina design, mocking, testes e documentação de API em um único fluxo. Isso ajuda o /goal porque o validador precisa de um comando claro para verificar se o estado final foi atingido. O guia de fluxo de trabalho de API design-first mostra a configuração contrato-primeiro, e a visão geral da ferramenta de teste de API para engenheiros de QA explica como estruturar casos de teste.

Se você trabalha com servidores MCP, o mesmo padrão se aplica. Veja teste de servidor MCP com Apidog para configurar testes que agentes com /goal podem executar localmente.

Boas práticas para rodar /goal

Use estas regras para evitar loops longos e resultados ruins:

  • Execute um objetivo por vez Codex e Claude Code trabalham melhor com um único objetivo ativo. Antes de iniciar outro, use: 
  /goal clear
Enter fullscreen mode Exit fullscreen mode
  • Comece com /plan Peça um plano primeiro, revise e depois transforme o plano em /goal. 
  /plan como implementar refresh tokens neste projeto?
Enter fullscreen mode Exit fullscreen mode
  • Peça um arquivo de progresso Para tarefas longas, instrua o agente a manter um arquivo como: 
  progress.md
Enter fullscreen mode Exit fullscreen mode

Isso cria um log auditável e ajuda a preservar contexto.

  • Defina comandos de verificação Prefira critérios como: 
  npm test
  pytest
  go test ./...
  docker compose up --build
Enter fullscreen mode Exit fullscreen mode

  • Evite critérios subjetivos

    “Melhorar”, “modernizar” e “deixar mais limpo” precisam virar métricas ou checklists.

  • Monitore tokens e tempo

    /goal tem sobrecarga. Para mudanças pequenas, um prompt normal pode ser mais rápido.

Quando /goal pode falhar

/goal não resolve todos os tipos de tarefa.

Custo

Loops longos consomem mais tokens. Defina orçamento, tempo máximo ou ponto de pausa.

Tarefas sem sinal claro

UX, tom de texto e gosto visual não têm validação objetiva por padrão. Use métricas, checklists ou revisão humana.

Efeitos colaterais externos

Objetivos que enviam e-mails, fazem pagamentos ou chamam APIs de produção precisam de restrições explícitas. O agente não vai inferir cautela sozinho. Se você está construindo controle de acesso para agentes chamando APIs, o artigo sobre uso e cobrança do GitHub Copilot para equipes API discute como fornecedores tratam esse tipo de limite.

Contexto obsoleto

Se a base de código muda durante uma execução longa, pause e reinicie com o contexto atualizado. Não deixe o agente continuar com uma visão antiga do projeto.

O que muda no trabalho com IA

/goal move a IA de “autocomplete avançado” para “executor com critérios de aceite”. O papel do desenvolvedor muda: menos digitação de cada linha, mais definição de objetivo, restrições e validação.

As equipes que mais se beneficiam são as que já têm:

  • contratos OpenAPI claros;
  • testes automatizados;
  • CI confiável;
  • documentação atualizada;
  • critérios de aceite objetivos.

Se sua API tem especificação e testes, você pode entregar um endpoint a um agente com /goal. Se a API existe apenas como conhecimento informal, o agente não tem como validar a entrega.

É por isso que plataformas de API se tornam parte da infraestrutura para workflows com agentes. O Apidog é orientado a desenvolvimento design-first, o que combina bem com agentes que precisam ler especificações e verificar implementação contra testes. Baixe o Apidog se quiser configurar o fluxo contrato-primeiro descrito acima.

FAQ

/goal funciona no aplicativo web do Codex?

Sim. Funciona no Codex CLI, no desktop Codex, no aplicativo Codex e no Claude Code CLI. Hermes também suporta o mesmo comando.

Como /goal é diferente de um prompt normal?

Um prompt normal executa uma vez e para. /goal roda em loop fechado, com um validador verificando a condição de parada após cada etapa.

O agente pode quebrar as restrições?

Pode, especialmente se a restrição for vaga. Use limites explícitos. Por exemplo:

sem modificar nenhum arquivo fora de /auth
Enter fullscreen mode Exit fullscreen mode

é melhor do que:

sem quebrar nada
Enter fullscreen mode Exit fullscreen mode

/goal custa mais tokens?

Sim. O validador pode ser menor, mas o modelo principal continua trabalhando por várias iterações. Use orçamento, /pause e critérios de término claros.

Como testar a saída do agente contra uma API real?

Use uma ferramenta como Apidog para definir o contrato e executar testes contra a implementação. O validador pode usar esses testes como estado final mensurável. Se você está inicializando um serviço com Claude e orçamento limitado, veja o guia de API Claude gratuita.

Top comments (0)