Rodar o mesmo prompt várias vezes pode parecer automação. Mas não é, sozinho.
O comando /loop do Claude Code roda a mesma tarefa em intervalos definidos, dentro de uma sessão CLI aberta. É útil pra trabalhos de polling, como checar resultado de teste, status de deploy, mudança em log ou revisão de pull request. Mas não é um scheduler persistente que continua rodando depois que você desliga a máquina.
A partir de 17 de julho de 2026, o comando exige Claude Code v2.1.72 ou superior. O comportamento e os limites abaixo foram atualizados de acordo com a documentação oficial de scheduled tasks do Claude Code.
Como usar o comando /loop do Claude Code?
A forma mais direta é passar o intervalo junto com o prompt:
/loop 5m check the deployEsse exemplo roda a tarefa "check the deploy" a cada cinco minutos. Pro intervalo, dá pra usar as unidades s, m, h e d; o limite mínimo prático é um minuto.
O comando tem três formas de uso:
| Uso | Comportamento |
|---|---|
| /loop 5m check the deploy | Repete o prompt em intervalos fixos de cinco minutos. |
| /loop check the deploy | O Claude escolhe um intervalo de repetição com base na tarefa; esse intervalo pode ficar entre um minuto e uma hora. |
| /loop 5mveya yalnızca/loop | Usa o prompt de loop padrão ou, se existir, a instrução do arquivoloop.md. |
Se você quer um comportamento fixo, defina o intervalo você mesmo. O formato só com prompt é mais rápido, mas como é o Claude quem escolhe o intervalo, não assuma o tempo — confira a tarefa gerada.
Em quais tarefas usar?
/loop funciona bem em tarefas específicas em que você precisa observar o resultado repetidamente:
- checar se a test suite está passando
- monitorar o status de deploy ou de um job de CI
- procurar um padrão específico em log
- checar novos comentários de review em um pull request
- esperar um endpoint de serviço voltar a ficar acessível
O ponto em comum é que a mesma pergunta específica se repete a cada rodada. Um objetivo aberto, tipo "desenvolva o repositório até terminar", não combina com o loop; o escopo cresce, o critério de parada fica indefinido e cada repetição pode gerar novas mudanças.
Meu limite é claro: antes de começar o loop, escreva no prompt o que ele pode ler, quais comandos pode rodar, qual é a condição de sucesso e quando deve parar. Não deixe rodando sem supervisão tarefas que alteram arquivos ou afetam sistemas externos.
Limites de sessão e agendamento
A distinção mais importante pro /loop é entre "repetitivo" e "persistente".
A sessão precisa ficar aberta. O loop está atrelado à sessão atual do Claude Code. Se você fechar o terminal, o app ou a máquina, a tarefa para de rodar.
Execuções perdidas não são compensadas. Se o horário chegar enquanto o Claude está ocupado com outra tarefa, ela não se acumula. Quando a sessão fica livre, ela roda uma vez — não inicia uma rodada separada pra cada intervalo perdido.
Tarefas repetitivas expiram depois de sete dias. Se você precisa de um processo com vida mais longa, use uma opção de agendamento persistente em vez do /loop.
Um loop pendente pode ser parado com Esc. Isso cancela a próxima execução. Se uma rodada já estiver rodando um comando ou tool, confira antes o status dessa operação.
Esses limites mantêm o comando /loop seguro e previsível pra polling de curta duração. E evitam que você coloque numa camada errada uma automação que precisa rodar por dias ou semanas.
Diferença entre /loop, Routines e um scheduler externo
A documentação de scheduled tasks do Claude Code divide os casos de uso, de forma geral, assim:
/loop: polling de curta duração e checagem repetida dentro de uma sessão CLI aberta- Routines / Desktop scheduled tasks: tarefas agendadas mais persistentes, dentro do app
- GitHub Actions ou outro scheduler: automação robusta, independente de máquina, baseada em evento de repositório ou CI/CD
Se uma tarefa precisa continuar rodando depois que o terminal fechar, não escolha o /loop. Da mesma forma, não monte um loop sem aprovação humana e sem tratamento de erro pra operações com efeito colateral, como merge, deploy ou escrita em API de terceiros.
Qual é a diferença pro Verdent?
Aqui, o Verdent é a camada de workflow mais ampla. O /loop repete o mesmo prompt na mesma sessão; já o Verdent foca no problema de planejar tarefas, distribuí-las entre diferentes workers, isolar workspaces, acompanhar o progresso e trazer os resultados pra review.
Essas duas ferramentas não são alternativas diretas pra mesma necessidade. Pra checar o deploy a cada cinco minutos, o /loop pode ser suficiente. Se você precisa de execução paralela de múltiplas tarefas, isolamento de mudanças e resultados reunidos em um único fluxo de review, aí entra uma camada de orquestração.
Perguntas frequentes
Qual é a versão mínima pro /loop do Claude Code?
De acordo com a documentação oficial, o /loop exige Claude Code v2.1.72 ou superior. Confira sua versão e, se o comando não for reconhecido, atualize o Claude Code primeiro.
O /loop funciona com o terminal fechado?
Não. A tarefa fica atrelada à sessão atual; o Claude Code e a máquina precisam ficar abertos. Pra agendamento persistente, use Routines, Desktop scheduled tasks, GitHub Actions ou outro scheduler.
Com que frequência o /loop pode rodar?
O limite mínimo prático na documentação é um minuto. No uso só com prompt, o Claude pode escolher um intervalo dinâmico entre um minuto e uma hora; se você precisa de um horário exato, defina o intervalo explicitamente no comando.
Se várias execuções forem perdidas ao mesmo tempo, todas rodam depois?
Não. Se a sessão estiver ocupada, as rodadas perdidas não se acumulam; quando o Claude fica livre, a tarefa roda uma vez. Por isso, o /loop não é o scheduler certo pra processos de contabilidade ou deploy em que toda execução precisa acontecer sem falta.
Resumindo: use o /loop só quando precisar de polling dentro da sessão; escolha um scheduler persistente pra um trabalho que precisa continuar depois que o terminal fechar. Se a necessidade não é repetição, e sim isolamento e review de tarefas paralelas, considere o Verdent como uma camada de workflow separada.
Bom desenvolvimento!
