Uma issue aberta no repositório oficial do openai/codex desde março de 2026 continua sem correção em setembro: toda vez que um comando demorado roda em segundo plano, o Codex confere se já terminou reenviando o histórico inteiro da conversa para a API, de novo e de novo. Uma build de 60 segundos vira cerca de 12 chamadas completas de API sem nenhum trabalho novo sendo feito.
Por que o Codex gasta token só esperando um comando terminar?
Porque existe um bug real, documentado no próprio repositório oficial e ainda sem correção. Quando um comando roda em segundo plano (um cargo build, um npm test), o Codex confere se já terminou com uma chamada de ferramenta chamada write_stdin. Se não terminou, a resposta volta vazia e o agente reenvia o histórico inteiro da conversa numa nova chamada de API completa pra tentar de novo.
Confirmado lendo o código-fonte do openai/codex: o piso de espera entre um poll e outro (MIN_EMPTY_YIELD_TIME_MS) está fixo em 5.000 milissegundos direto no binário, sem opção de configurar. Isso bate exatamente com o que a issue #13733 relata: um cargo build de 60 segundos gera cerca de 12 turnos de poll, cada um recontando a conversa inteira pra API.
O tamanho do estrago depende do histórico da sua sessão
O custo de cada poll é proporcional ao tamanho do histórico multiplicado pelo número de polls. Numa sessão curta, isso passa quase despercebido. Numa sessão longa, com código legado, refatoração grande ou dezenas de arquivos já discutidos, esperar um build de 10 minutos pode gerar mais de 100 chamadas completas de API só de espera, cada uma carregando tudo que já foi dito antes.
A issue já linka 4 relatos duplicados do mesmo padrão (#10957, #8656, #6113, #3968), e a thread "Codex is unusable now" no r/codex, com mais de 700 pontos e 300 comentários em menos de 24 horas, mostra o tamanho do incômodo. O comando /goal, que documentadamente deixa o agente definir e retomar uma meta sozinho, amplifica o problema: cada retomada automática é mais um turno que reconta a conversa inteira.
| Constante ou config | Valor | O que controla |
|---|---|---|
MIN_EMPTY_YIELD_TIME_MS | 5.000 ms | piso de espera de um poll vazio, fixo no código-fonte |
MAX_YIELD_TIME_MS | 30.000 ms | teto de espera pra escrita de stdin não vazia |
background_terminal_max_timeout | 300.000 ms (padrão) | teto configurável do poll vazio, no config.toml |
Dá pra corrigir sem esperar a OpenAI?
Só parcialmente. Não existe hoje um jeito de zerar o polling: o piso de 5 segundos está fixo no binário, e é ele quem decide a cadência quando o próprio agente pede esperas curtas, que é o comportamento observado na prática. O que dá pra fazer é reduzir o tamanho do estrago.
Antes de rodar um comando que você já sabe que vai demorar, abra uma ramificação isolada da conversa:
/fork/fork é um slash command oficial da Codex CLI: clona a conversa atual pra uma nova aba com ID próprio, sem tocar na conversa original. Rode o comando demorado dentro do fork. Cada poll ainda reenvia o histórico, mas é o histórico do fork, não da sua sessão principal, então o ruído fica isolado e descartável. Terminado o comando, volte pra sessão principal e, se precisar limpar o fork, use:
/compactPra acompanhar o estrago em tempo real, /status mostra a configuração da sessão e o uso de tokens.
Existe também um parâmetro de configuração real pra esse comportamento, background_terminal_max_timeout, no config.toml:
background_terminal_max_timeout = 300000Mas atenção: esse número já é o padrão (300.000 ms, 5 minutos), e ele funciona como teto, não como piso. Só ajuda se o agente pedir uma espera mais longa do que está pedindo hoje. Na prática, não é ele quem resolve o padrão relatado pela comunidade.
Enquanto essa issue segue aberta, cada poll de 5 em 5 segundos continua contando contra a sua cota semanal no Codex, e uma build de 10 minutos pode custar dezenas de chamadas completas só de espera. Na Verboo Code esse tipo de ineficiência não tira nada do seu bolso: os planos rodam com token ilimitado, então mesmo um agente preso num loop de poll não te deixa sem cota no meio de uma tarefa.
