Voltar para as novidades

Em quais sinais da saída do codex exec dá para confiar?

O código de saída é o único sinal que você não pode usar. Em 9 execuções de codex exec em 19 de agosto de 2026 (codex-cli 0.147.0, macOS 26.5.2 em arm64) o processo saiu com 0 todas as vezes, inclusive nas 6 execuções que deixaram o repositório idêntico byte a byte. Outros quatro sinais na mesma saída carregam a verdade, e cada um responde a uma pergunta diferente: um item file_change na saída padrão diz que houve tentativa de escrita, o campo status dele diz se a escrita entrou (bateu com a realidade nos 10 itens das 9 execuções de 21 de agosto de 2026, codex-cli 0.148.0), o campo kind lido como saldo por caminho é a única coisa na saída que pega um arquivo criado e depois apagado, e uma linha ERROR com patch rejected na saída de erro apareceu em 6 de 6 execuções bloqueadas. Esta página é um índice. Ela não mede nada novo: consolida 25 execuções de codex exec que publicamos em 19 e 21 de agosto de 2026, mais uma comparação com o Claude Code de 18 de agosto de 2026, e cada número dela carrega a data e o build de onde veio.

A ordem importa mais do que qualquer sinal isolado, porque estes sinais falham em direções diferentes. Um deles fica calado quando falta trabalho. Outro dispara quando nada sobreviveu. Um terceiro é o único honesto numa escrita que falhou, e nós só o observamos no build mais novo.

O que o código de saída do codex exec realmente prova?

O código de saída do codex exec prova que o processo terminou, e nada além disso sobre o trabalho. Demos a mesma tarefa pequena ao codex exec nove vezes em 19 de agosto de 2026, em nove repositórios git descartáveis, em codex-cli 0.147.0 e macOS 26.5.2: acrescentar uma função slugify a src/utils.js, exportá-la e rodar npm test. Os três braços diferiam só na política de sandbox: -s workspace-write, nenhuma flag -s, e -s read-only. O processo saiu com 0 em 9 de 9 execuções. Em 6 dessas 9 o repositório terminou idêntico byte a byte ao que era antes, porque o sandbox recusou o patch. Uma esteira que decide pelo $? teria marcado as nove como verdes.

Existe um caso em que o código de saída fala, e esbarramos nele por acidente. Numa bateria separada do mesmo dia, uma execução morreu antes de fazer qualquer coisa, com código de saída 1 e um evento turn.failed carregando a mensagem Selected model is at capacity. Ou seja: saída diferente de zero avisa que a execução quebrou; saída zero não diz nada sobre o arquivo ter sido escrito. O juiz em todas essas execuções não foi o agente: o aparato tirou o hash de cada arquivo fora de .git antes e depois de cada execução e comparou as impressões digitais, então a pergunta "mudou alguma coisa" foi respondida fora do alcance do agente. A tabela completa das nove execuções está em como você sabe se o Codex mudou mesmo um arquivo.

Qual sinal do codex exec diz que houve tentativa de escrita?

O sinal de que houve tentativa de escrita é um evento item.completed do tipo file_change na saída padrão, que o codex exec --json emite por caminho alterado. Nas nove execuções de 19 de agosto de 2026 ele apareceu em 3 de 3 execuções que editaram o arquivo e em 0 de 6 que não editaram, o que é uma separação limpa e a razão de o termos recomendado no começo. Cada item carrega uma lista changes, e cada mudança carrega um path e um campo kind cujos valores observamos como add e delete.

Leia essa frase ao pé da letra, porque a armadilha está no verbo. O evento responde "houve escrita neste caminho", não "o trabalho aconteceu". Essas duas perguntas se separam em situações comuns, não exóticas, e a próxima seção é onde publicamos o contraexemplo contra a nossa própria recomendação. Se você está ligando o codex exec a uma esteira hoje e só tem tempo de mudar uma coisa, trocar o $? pela presença de um item file_change já é a maior metade da melhora, nas execuções que medimos.

Um evento file_change significa que o trabalho aconteceu?

Não. Um evento file_change no codex exec dispara na escrita e não no desfecho, e medimos dois jeitos comuns de ele enganar você, os dois em 19 de agosto de 2026 com codex-cli 0.147.0. No primeiro braço, três execuções, a tarefa pedia ao Codex criar sum.js, rodar um teste viciado que exige sum(2, 2) igual a 5, e reverter tudo se o teste falhasse. O Codex fez exatamente isso. A impressão digital do repositório depois da execução era igual à de antes em 3 de 3 execuções, e o file_change disparou assim mesmo em 3 de 3, uma vez com kind: "add" e uma vez com kind: "delete". No segundo braço, três execuções, um prompt carregava duas tarefas independentes, uma possível e uma impossível com a rede desligada. O Codex completou uma metade e pulou a outra, e o file_change disparou em 3 de 3 exatamente como dispara para trabalho completo.

O conserto é pequeno e mora no payload que você já tem: leia o kind e calcule um saldo por caminho, em vez de contar eventos. Um caminho com um add e um delete zera o saldo e a reversão fica visível. Nada na saída pega a metade que faltou numa tarefa de duas partes, e não achamos sinal que pegue. Isso é um limite real do formato, não um descuido na nossa leitura dele, e a medição está em o codex exec mostra quando o agente fez só metade do trabalho.

Qual campo do codex exec pega uma escrita que falhou?

O campo que pega a escrita que falhou é o status do item file_change, e na nossa medição ele é a coisa legível por máquina mais honesta da execução. Em 21 de agosto de 2026, em codex-cli 0.148.0 e macOS 26.5.2, rodamos codex exec nove vezes, com um perfil sandbox-exec do macOS negando escrita no diretório de trabalho em três delas. Essas nove execuções emitiram dez itens file_change no total, e o campo bateu com a realidade em todos eles: status: "failed" nos 4 itens emitidos pelas três execuções bloqueadas, status: "completed" nos 6 itens emitidos pelas seis execuções que escreveram. Eis um item, literal e completo, de uma execução bloqueada:

{
 "id": "item_1",
 "type": "file_change",
 "changes": [
  {
   "path": "/private/tmp/codex-sandbox-21ago-n1/N1/run1/report.txt",
   "kind": "add"
  }
 ],
 "status": "failed"
}

Isso refina a seção anterior em vez de contradizê-la. As duas afirmações valem ao mesmo tempo: o evento é honesto sobre a escrita ter entrado, e calado sobre o trabalho ter valido alguma coisa. Uma ressalva pertence a este lugar e nenhum artigo filho a carrega, porque cada um deles foi escrito dentro de um build. Nós observamos o status em codex-cli 0.148.0. As medições de 19 de agosto rodaram em 0.147.0 e não lemos aquele campo lá, então não podemos dizer, a partir dos nossos dados, se ele estava presente e nós o ignoramos, ou se foi acrescentado depois. Confira no seu próprio build antes de fazer uma esteira depender dele.

O que a linha ERROR na saída de erro pega?

A linha ERROR na saída de erro pega a escrita bloqueada, e na nossa bateria de 19 de agosto de 2026 ela foi a imagem espelhada do file_change. Uma linha com patch rejected apareceu em 6 de 6 execuções em que o sandbox recusou a escrita, e em 0 de 3 execuções que escreveram com sucesso. Saída padrão e saída de erro respondem, portanto, a perguntas opostas na mesma execução, e uma esteira que captura só um dos dois fluxos está jogando fora metade da evidência sobre uma falha que ela vai ter de explicar depois.

Dois daqueles três braços merecem uma nota que preferimos publicar a esconder. O braço sem flag -s e o braço com -s read-only chegaram ao mesmo estado de sandbox por dois caminhos diferentes, então as linhas deles não são evidência independente: na nossa medição, o codex exec sem flag de sandbox se comportou exatamente como o -s read-only. Deixamos as duas linhas na tabela original com essa nota, em vez de derrubar um braço em silêncio, e a mesma honestidade vale para a contagem aqui: 6 de 6 execuções bloqueadas é três mais três, de dois braços que acabaram sendo uma condição só.

A prosa do próprio agente é um sinal que dá para usar?

A prosa do Codex é honesta sobre a falha e pouco confiável sobre a causa, e as duas metades importam se você pretende ler transcrições. Em todas as execuções bloqueadas de 19 de agosto de 2026, o Codex disse em inglês claro que não conseguia escrever o arquivo. Ele nunca reivindicou um sucesso que não teve. Essa é a metade boa, e vale dizer com todas as letras porque o comportamento oposto é comum o bastante para ser a razão de esta série existir.

A metade ruim apareceu em 21 de agosto de 2026, quando o bloqueio veio de um perfil sandbox-exec do macOS aplicado de fora do processo. O Codex reportou Operation not permitted e culpou o diretório atual em 3 de 3 execuções bloqueadas. O diretório era drwxr-xr-x e pertencia ao usuário, então a explicação estava errada enquanto o relato da falha estava certo. Ele nunca nomeou a camada que de fato o parou. Para automação a consequência é estreita e prática: use a prosa para saber que algo falhou, nunca para saber o que falhou, e leia o status antes de ler a frase. A medição do diagnóstico está em por que o Codex diz Operation not permitted quando o diretório parece gravável.

Em que ordem a sua esteira deve ler os sinais do codex exec?

Leia na ordem do que cada um consegue provar, do mais fraco ao mais forte, porque uma esteira que os lê na ordem errada reporta a coisa errada. Nas 25 execuções de codex exec publicadas em 19 e 21 de agosto de 2026, a escada saiu assim.

  • Código de saída. Use só para detectar que a execução em si quebrou, como no caso do turn.failed com Selected model is at capacity. Foi 0 em 9 de 9 execuções, incluindo 6 que não mudaram nada, então ele não pode significar sucesso.
  • Presença de um item file_change. Houve tentativa de escrita naquele caminho. Separação limpa nas nossas execuções, 3 de 3 contra 0 de 6.
  • status nesse item. Se a escrita entrou. Correto em 10 de 10 itens em codex-cli 0.148.0, não verificado por nós em 0.147.0.
  • kind, como saldo por caminho. Se sobrou alguma coisa. É o que pega o criar e apagar que a contagem de eventos deixa passar.
  • ERROR na saída de erro. Por que foi recusado. Presente em 6 de 6 execuções bloqueadas.
  • Um hash da árvore de trabalho antes e depois. O único juiz que não é o agente, e o que usamos para dar nota a todos os braços acima.

A última linha é a que fica, se você guardar só uma. Todo número desta página existe porque o aparato tirou a impressão digital do repositório fora do alcance do agente, e qualquer dos sinais acima pode ser verificado na sua máquina contra essa mesma conferência.

Como o envelope do codex exec se compara ao do Claude Code?

O envelope do codex exec carrega um evento por arquivo e o envelope do Claude Code, na nossa medição, não carregava nada equivalente. Rodamos o mesmo tipo de medição contra o Claude Code em 18 de agosto de 2026 (Claude Code 2.1.235, modelo sonnet, macOS 26.5.2): 13 de 13 execuções voltaram com subtype: "success" e is_error: false, e 10 dessas 13 não tinham mudado nada no repositório. Não havia campo fazendo o papel que o file_change faz para o Codex, então o envelope sozinho não conseguia distinguir trabalho de silêncio.

Trate isso como comparação de dois envelopes em duas datas e dois builds, não como veredito sobre um dos agentes. O número do Claude Code é de 18 de agosto de 2026 e os do Codex são de 19 e 21 de agosto de 2026, em codex-cli 0.147.0 e 0.148.0, e agentes desta categoria lançam versão várias vezes por semana. O que generaliza é o formato da pergunta, não o placar: antes de automatizar em volta de qualquer agente de programação, descubra quais campos da saída dele respondem "houve tentativa de escrita", "ela entrou" e "sobrou alguma coisa", e se a resposta a qualquer uma das três for "nenhum campo", essa lacuna é sua para cobrir com um hash.

O que este índice não mostra

Este índice carrega os limites das medições que consolida, e eles são reais. Todo número vem de uma máquina, macOS 26.5.2 em arm64, em repositórios git descartáveis com um punhado de arquivos, em 18, 19 e 21 de agosto de 2026. As amostras são de um dígito por braço, três execuções cada, e uma contagem de um dígito não separa uma falha rara de uma falha impossível. Dois builds do codex-cli estão misturados aqui, 0.147.0 e 0.148.0, e dizemos qual é qual em cada afirmação justamente porque não são a mesma ferramenta.

Várias coisas ficaram sem teste. Não lemos o status em 0.147.0, então a história dele nos é desconhecida. Não testamos a interface interativa do Codex, só o codex exec. Não testamos uma escrita parcial, um arquivo deixado pela metade por um processo interrompido, que é o caso em que um saldo por caminho pode ser honesto e inútil ao mesmo tempo. Não testamos nenhum sandbox além do perfil do macOS e das políticas -s embutidas, e o Linux pode se comportar de outro jeito. Duas contaminações do aparato de 21 de agosto de 2026 viajam junto com o achado sobre a prosa e estão declaradas no artigo de origem: o diretório de trabalho se chamava /private/tmp/codex-sandbox-21ago-n1, então a palavra codex-sandbox foi impressa na tela pelo pwd e pelo ls em 3 de 3 execuções bloqueadas, e numa dessas execuções o agente abriu o stderr.txt do nosso aparato e leu o log de erro do invólucro. Nenhuma das duas mudou o resultado, e as duas significam que nenhuma frase aqui pode afirmar que o agente viu só o que o Codex mostra. No CanvasCode rodamos vários agentes de programação lado a lado, que é exatamente onde um envelope incapaz de distinguir trabalho de silêncio custa mais caro, porque a execução que você não olhou é aquela cujo resumo você vai acreditar.