Codex Automations para tarefas longas: gatilhos agendados, heartbeats e trabalho de vários dias

Se você passa para o Codex verificações repetitivas, acompanhamento de PR, revisão pós-deploy e triagem de vários dias, a primeira pergunta não é se dá para automatizar. É que tipo de tarefa merece automação e como fazer isso. Automations não transforma o Codex em um agente de bastidor sempre ligado. Ele apenas traz o Codex de volta na hora certa, dentro do limite certo, para fazer uma coisa bem definida.

1. Primeiro avalie se a tarefa deve ser automatizada

1.1 standalone/project automation: trabalhos de bastidor independentes

Standalone automation e project automation são trabalhos de bastidor independentes. A diferença está no escopo. Standalone não está amarrada a um projeto específico; project automation está vinculada a um caminho de projeto, então funciona melhor para trabalho recorrente em torno de um repositório fixo.

Cada gatilho inicia uma execução nova. Quando termina, o resultado vai para inbox ou triage; se não houver nada novo, pode ser arquivado automaticamente. Os usos típicos incluem checagens semanais de dependências, triagem diária de issues e verificações programadas após deploy.

A limitação principal é o ambiente local: a máquina que roda o Codex precisa continuar ligada, o app precisa continuar aberto e o caminho do projeto precisa existir. Se a máquina dormir, desligar ou o app fechar, nada continua. Não é a camada certa para hosting sem supervisão de longo prazo.

1.2 thread automation (heartbeat): wakes periódicos no mesmo thread

Thread automation é um wakeup periódico estilo heartbeat preso ao thread atual da conversa. A ideia central é preservar contexto: a cada wakeup, a mesma conversa continua em vez de criar uma execução nova e independente.

Ela funciona bem para checks de log pós-deploy, follow-up de vários dias e triagem contínua. Por exemplo, você pode pedir para o Codex verificar os logs de deploy a cada 10 minutos, avisar apenas quando aparecer erro ou sucesso, e ficar em silêncio no restante do tempo. Esse tipo de tarefa precisa de continuidade de contexto, então standalone automation não combina.

Heartbeat não é um daemon permanente nem um forever loop. É um ritmo de acordar -> verificar -> reportar -> esperar. Se o app pausar ou fechar, o heartbeat também para.

1.3 Tabela comparativa

Dimensão	standalone/project automation	thread automation (heartbeat)
Local de execução	Thread de bastidor independente	Thread de conversa atual
Retenção de contexto	Contexto novo a cada execução	Mantém o contexto da sessão atual
Casos de uso adequados	Tarefas repetitivas independentes, triagem de issues, checagens de dependências	Follow-up de tarefas longas, triagem contínua, logs pós-deploy, trabalho de vários dias
Dependências	O app local / a máquina / o caminho do projeto precisam existir	O thread atual precisa continuar vinculado
Superfície de resultado	inbox / triage, arquivamento automático quando não há nada	Janela da conversa atual
Mecanismo de parada	Desativar a automação	Pausar ou fechar o app

A decisão é simples: a tarefa precisa manter contexto? Se sim, use thread automation. Ela está presa a um projeto específico? Se sim, use project automation; caso contrário, standalone automation.

2. Que tarefas combinam com Automations

Nem toda tarefa repetitiva merece Automations. Primeiro olhe para a forma da tarefa.

2.1 Características das tarefas que combinam

Tarefas que combinam com Automations costumam ter três características: muita repetição, regras claras e saída verificável.

Trabalho altamente repetitivo aparece em um ritmo fixo e mira praticamente o mesmo resultado toda vez. Checagens semanais de dependências, triagem diária de issues e revisões fixas após deploy são bons exemplos. Escopo de inspeção, critérios de decisão e formato de saída podem ser definidos antes.

Tarefas baseadas em regras viram prompt com facilidade. Por exemplo: “Verifique as versões em package.json, liste os pacotes que tiverem versões novas e recomende uma ordem de atualização.” Os critérios de julgamento continuam estáveis, então não há necessidade de repeti-los manualmente.

Saída verificável também importa. Uma boa automação deve voltar para inbox / triage, se arquivar sozinha quando não houver nada para fazer e mostrar claramente o próximo passo quando encontrar algo. É assim que você sabe que ela realmente economiza tempo em vez de mover ruído para outro lugar.

2.2 Características das tarefas que não combinam

Tarefas que não combinam com Automations normalmente têm quatro características: exigem julgamento humano frequente, dependem de um estado externo que muda rápido, o prompt ainda não é estável ou precisam de hosting sem supervisão por muito tempo.

Tarefas que exigem julgamento humano frequente tendem a ter fronteiras difusas. Decisões de arquitetura, caça complexa a bugs e trade-offs situacionais exigem adaptação caso a caso, então não casam bem com uma automação fixa.

Tarefas dependentes de um estado externo que muda rápido também pedem cautela. Monitoramento em tempo real de um serviço de produção, por exemplo, muda rápido demais e combina melhor com ferramentas especializadas de observabilidade do que com Automations.

Não automatize também um prompt que ainda não foi validado. Rode manualmente algumas vezes, estabilize regras, escopo e saída, e só depois transforme isso em automação.

Hosting sem supervisão de longo prazo não é a camada certa para project-scoped automation. Ela depende do app local, da máquina e do caminho do projeto. Se a máquina some, a automação para. Não é uma solução cloud.

2.3 Tabela de encaixe

Tipo de tarefa	Encaixa?	Motivo	Abordagem recomendada
Checagens semanais de dependências	Sim	Repetitiva, baseada em regras, verificável	standalone automation ou project automation
Triagem diária de issues	Sim	Pode ir para inbox, pode ser arquivada automaticamente, o prompt é estável	standalone automation ou thread heartbeat
Checks de log pós-deploy	Sim	Mesmo thread, o contexto importa	thread automation
Decisões de arquitetura	Não	Exige julgamento humano frequente, fronteiras difusas	conversa manual
Caça complexa a bugs	Não	Exige adaptação situacional	conversa manual
Monitoramento em tempo real	Não	O estado externo muda rápido demais	ferramentas especializadas de observabilidade
Hosting sem supervisão de longo prazo	Não	project-scoped automation depende do ambiente local	abordagem CI ou cloud
Fluxos de automação não testados	Não	Prompt instável, execuções manuais inconsistentes	estabilize manualmente primeiro

O fluxo de decisão é simples: primeiro verifique se o prompt está estável, depois veja se a tarefa precisa manter contexto e, por fim, se você realmente precisa de hosting cloud duradouro.

3. Criar sua primeira standalone/project automation

3.1 Fluxo de criação

1. Escreva a tarefa com clareza primeiro. Defina escopo, entrada, saída, critérios de sucesso e condições de parada.
2. Escolha o tipo de automação. Trabalho repetitivo independente vai para standalone; trabalho repetitivo em torno de um repositório fixo vai para project automation.
3. Escolha o local de execução. Em repositórios Git, comece com um worktree para não atrapalhar o workspace atual.
4. Defina a frequência. Tarefas por minuto precisam de condições de parada explícitas para não acordarem para sempre.
5. Faça primeiro alguns ciclos de teste. Quando a saída estiver estável, aumente para a frequência real.

3.2 Como escolher entre worktree e local project

Local de execução	Isolamento	Casos adequados	Risco
worktree	As mudanças ficam isoladas do diretório atual	Tarefas que editam arquivos, escrevem código ou sugerem PR	Os erros normalmente ficam dentro do worktree e são descartados com facilidade
local project	Sem isolamento; executa direto no diretório atual	Verificações de leitura, geração de relatório, triagem	Pode afetar arquivos que você está editando

Em repositórios Git, tarefas de modificação devem começar em um worktree. Use local project só quando a tarefa for explicitamente de leitura, inspeção ou confirmação.

4. Criar thread automation (heartbeat)

4.1 Fluxo de criação

1. Verifique primeiro se o thread atual já está cuidando de uma tarefa longa.
2. Depois prenda a thread automation nesse thread.
3. Escreva exatamente o que ele deve verificar a cada wakeup, quando ele deve reportar e quando deve ficar em silêncio.
4. Defina condições de parada: sucesso, falha, timeout ou número máximo de ciclos.
5. Comece com frequência baixa e confirme que não vai spammar antes de passar para o ritmo final.

4.2 Exemplo de prompt heartbeat

Verifique os logs de deploy a cada 10 minutos e reporte apenas nestes casos:

1. Surge um sinal de erro (contém "error", "failed" ou "exception")
2. Surge um sinal de conclusão (contém "deployed", "success" ou "completed")
3. Passam 30 minutos e ainda não terminou

Formato do relatório:
- Status: [in progress / success / failure]
- Trecho-chave do log: [até 3 linhas]
- Próximo passo: [se houver]

Fique em silêncio quando nada mudar.

Esse prompt deixa explícitos o escopo da verificação, o limite da saída e as condições de parada. Não precisa repetir “checagem concluída” a cada wakeup, nem transformar ausência de mudança em ruído.

5. Segurança: sandbox, approval policy e governança do time

5.1 Configurações de sandbox e approval policy

Automations roda por padrão dentro de uma sandbox. A sandbox decide quais arquivos podem ser tocados, se pode cruzar limites e se precisa de aprovação extra. Para automação de bastidor, quanto menor o limite padrão, melhor.

Modo sandbox	Escopo de permissão	Adequado para	Nível de risco
read-only	Só leitura, sem escrita	Inspeção e análise puras	Baixo
workspace-write	Leitura/escrita dentro do workspace; ações externas ainda pedem aprovação	Automação diária, edição de arquivos, sugestões de PR	Médio
danger-full-access	Acesso irrestrito ao sistema	Ambientes isolados ou tarefas muito confiáveis	Alto

A approval policy controla se o agente deve pedir autorização ao encontrar uma ação mais arriscada.

approval policy	Comportamento	Caso de uso
on-request	Pede permissões mais altas quando necessário	Um pouco de autonomia, mas com revisão humana
never	Executa tudo automaticamente, sem perguntar	Scripts de automação ou ambientes não interativos

A recomendação padrão deve ser workspace-write + rules/allowlist, não full access + unattended. A segunda opção é ampla demais quando algo dá errado.

5.2 Conselho de governança

Os times podem fixar sandbox e approval em requirements.toml para evitar que alguém conceda permissões demais por engano.

[agent]
approval_policy = "never"
sandbox = "workspace-write"

O objetivo não é bloquear tudo. O objetivo é manter o limite padrão estreito e ampliá-lo só quando a tarefa realmente precisar.

6. Três modelos de automação prontos para usar

6.1 Revisão semanal de dependências

• Frequência de disparo: uma vez por semana
• Local de execução: priorize worktree em repositórios Git
• Saída bem-sucedida: lista de dependências atualizáveis e prioridades sugeridas
• Condição de parada: se não houver nada para atualizar, mantenha a resposta curta
• Limite de permissões: leitura apenas ou relatório leve

6.2 Follow-up heartbeat pós-deploy

• Frequência de disparo: a cada 10 minutos, até 30 minutos
• Local de execução: thread automation
• Saída bem-sucedida: resumo curto de sucesso, falha ou timeout
• Condição de parada: sinal de sucesso, sinal de falha ou timeout
• Limite de permissões: ler logs apenas, não tocar na produção

6.3 Triagem diária de issues / PR

• Frequência de disparo: uma vez por dia
• Local de execução: standalone automation ou thread heartbeat
• Saída bem-sucedida: colocar em inbox o que exige atenção humana
• Condição de parada: ficar em silêncio quando não houver nada novo
• Limite de permissões: por padrão workspace-write; evite full access

7. Se a automação falhar, verifique primeiro estas 6 coisas

1. O app do Codex ainda está rodando e a máquina está acordada?
2. O caminho do projeto ainda existe ou o worktree foi movido / removido?
3. A sandbox está bloqueando escrita ou rede?
4. A thread automation realmente precisa conservar contexto?
5. O worktree acumulou demais e precisa de limpeza?
6. O prompt diz claramente quando parar e quando reportar?

8. Checklist de FAQ

8.1 Automations é uma tarefa agendada ou um agente que roda o tempo todo?

Ele se parece mais com um trabalho em segundo plano agendado ou acordado periodicamente. Em cada wakeup ele verifica, trabalha, reporta e volta a esperar. Não é um forever loop.

8.2 Qual é a diferença entre standalone/project e thread automation?

Standalone/project automation é uma execução de fundo independente que recomeça do zero a cada vez, e o resultado vai para inbox / triage. Thread automation é um heartbeat no mesmo thread e preserva o contexto da conversa atual.

8.3 Que tarefas combinam com Automations e quais não combinam?

As adequadas são repetitivas, baseadas em regras e verificáveis. As inadequadas são as que exigem julgamento humano frequente, dependem de um estado externo que muda rápido ou têm prompts instáveis.

8.4 Como escolher entre worktree e local project?

Para tudo que possa modificar arquivos, priorize worktree. Use local project só para checagens de leitura e tarefas de relatório.

8.5 Vai continuar funcionando se eu fechar o app ou o computador dormir?

Não. A automação ligada ao projeto depende do app local, da máquina e do caminho do projeto. Se o app fechar ou a máquina dormir, ela para.

8.6 Quando devo usar Computer Use?

Só quando for preciso operar diretamente uma GUI e não houver API nem interface web. Se o código normal resolve, normalmente não vale a pena.

8.7 Como controlo custo e frequência?

Mantenha a frequência apenas no nível necessário, verifique o estado com /status, defina condições de parada para cada automação e evite polling excessivo.

9. Resumo

Computer Use, o navegador embutido e Automations resolvem camadas diferentes do mesmo problema. Automations serve para dar ao Codex trabalho estável, verificável e repetitivo em segundo plano; thread automation serve para acompanhar tarefas longas de vários dias; worktree e sandbox servem para manter o risco sob controle.

A ordem mais segura é sempre a mesma: primeiro julgue se a tarefa deve ser automatizada, depois escolha o local de execução e as permissões, e só então ajuste a frequência. Primeiro estabilize o processo humano e depois deixe o Codex mantê-lo por mais tempo.