Codex: como lidar com "thread not found" e verificar o que fazer antes de apagar o histórico

O erro "thread not found" do Codex pode aparecer mesmo com o histórico preservado, e isso não significa necessariamente que a conversa foi apagada. Sem apagar o histórico, tente nesta ordem: reabrir a mesma tarefa, reiniciar o app completamente e enviar uma mensagem curta de verificação. Se também aparecer um erro de armazenamento (como os error 2), o tratamento é outro.

1. O que significa "thread not found"

Ao enviar uma continuação para uma tarefa existente no Codex da OpenAI, você pode ver um erro como este. O ID no final identifica a conversa de destino e está oculto abaixo.

メッセージの送信中にエラーが発生しました
thread not found: <ID da conversa de destino>

Em apps exibidos em inglês, a primeira linha mostra Error submitting message (#30710).

Error submitting message
thread not found: <conversation ID>

Este artigo trata de tarefas locais existentes no aplicativo de desktop. Ele se baseia em registros de um exemplo que encontramos em nosso ambiente (Windows), no código-fonte público e em relatos de bugs de usuários, e foi organizado com base na situação em 21 de setembro de 2026.

Exibir o histórico e aceitar novas instruções são mecanismos separados. Em uma tarefa que você não usa há algum tempo, o histórico pode carregar enquanto a conversa não está carregada do lado que aceita instruções. Se você enviar assim mesmo, aparece este erro.

2. Estudo de caso: o envio foi restabelecido com o histórico preservado

Este é um exemplo do nosso ambiente. O erro apareceu quando enviamos uma instrução de continuação em uma tarefa do app Windows 26.915.31029. Abaixo, os registros do app de 21 de setembro de 2026 foram convertidos para UTC e organizados sem os IDs das conversas nem os detalhes do trabalho.

A conversa salva e o diretório de trabalho permaneceram, e a operação de leitura do histórico também teve sucesso. A tarefa original não havia sido arquivada.

A causa provável é uma divergência: a tela tratava a conversa como retomada, mas internamente ela não tinha sido carregada. Depois que o envio voltar a funcionar, verifique também se o trabalho feito naquele turno está correto.

3. A ordem para tentar quando só o envio falha

Primeiro, salve sua mensagem em outro lugar para não perdê-la. Antes de clicar em Enviar de novo, verifique se a mesma instrução já foi adicionada à conversa ou se o processamento já começou. Especialmente em instruções que envolvem publicar, excluir ou comprar algo, é importante não empilhar solicitações cuja resposta atrasou.

Por exemplo, você pode restringir o escopo da mensagem de verificação assim. Como ela é enviada como uma instrução comum ao modelo, pode consumir seu limite de uso normalmente.

Teste de conexão. Não retome o trabalho anterior.
Sem ler ou gravar arquivos nem fazer chamadas de ferramentas,
responda apenas com "Resposta recebida."

O relato no repositório do GitHub da OpenAI #30710 inclui um caso em que uma falha de envio logo após abrir a conversa no Windows foi resolvida com a reinicialização completa do app. A orientação oficial de solução de problemas, para "aguardar a conclusão da tarefa em execução antes de reiniciar", se refere a casos em que o terminal integrado trava; não é uma orientação para este erro de envio.

Se for atualizar, primeiro registre a versão atual do app e os sintomas. Segundo a documentação oficial de solução de problemas, o Codex incluído no aplicativo de desktop e a CLI instalada separadamente podem ter versões diferentes. Atualizar a CLI não significa que um bug do app foi corrigido.

4. A mesma mensagem pode ter causas e soluções diferentes

Não decida apenas pelo título de erro ao enviar a mensagem; observe o texto que vem depois e a operação que falhou. A tabela abaixo separa, por sintoma, exemplos de relatos públicos e do nosso ambiente.

Nos casos em que o histórico permanece, o acompanhamento de um usuário de macOS em #30710 é útil. A tela tratava a conversa como retomada, mas o envio continuava falhando; depois, o recarregamento em uma nova tela foi bem-sucedido. Trata-se de um relato de inconsistência de estado que não pode ser explicado por uma "condição de corrida apenas no momento da abertura", e a sequência é muito parecida com a deste caso.

Por outro lado, o relato do Windows #39179 descreve um histórico que podia ser lido enquanto o envio e o arquivamento falhavam; no ambiente do autor, isso continuou depois da reinicialização. Um acompanhamento posterior também relata que, após reiniciar completamente o app, o usuário conseguiu continuar, mas a falha no arquivamento não foi corrigida de forma confiável. A #39575 traz diagnósticos sobre os horários nos nomes dos arquivos salvos e sobre o processo de referência. Todos são investigações de usuários; por isso, não conclua que seus dados estão corrompidos só porque há um prefixo de caminho ou uma diferença de fuso horário.

O tipo que espera aparece no relato de timeout de envio #27395, que inclui registros em que turn/start foi interrompido em 30 segundos (timeoutMs=30000) e falhou como Timeout. Em um acompanhamento da #23644, uma solicitação da qual o envio depende ficou cerca de 30 segundos na fila (queueWaitMs=30001) antes de falhar com App server request expired while queued. O tipo em que a parada também falha pode ser visto no relato sobre inconsistência entre histórico e estado de execução #42604.

5. Quando ainda não funciona: verificações e transferência

Se ainda não funcionar depois de reiniciar, verifique se você consegue ler o histórico salvo. Se houver uma função que permita a uma tarefa do Codex em bom funcionamento ler a tarefa de destino, comece por uma verificação somente leitura. Também é importante não confundir o ID de destino com uma tarefa de nome parecido.

Investigue a tarefa de destino em modo somente leitura.
ID de destino: o ID da conversa exibido no erro

Informe se o histórico pode ser lido, o estado do último turno e os erros.
Não envie mensagens para outras tarefas, não retome trabalhos anteriores, não crie um fork,
não arquive, não altere configurações, não edite o banco de dados nem mova ou exclua arquivos de histórico.
Se não houver nenhuma função de gerenciamento de tarefas disponível, informe isso.

Este exemplo serve para ambientes em que há funções de gerenciamento de tarefas. Se você não encontrar essa função, não tente adivinhar comandos internos com nomes parecidos; vá para o relatório na seção 6.

Um acompanhamento do #39179 descreve um caso em que uma mensagem curta de verificação foi enviada a partir de outra tarefa em bom funcionamento e, depois que a resposta foi concluída, a conversa normal também foi recuperada. No entanto, outro acompanhamento relata um envio semelhante que falhou, e uma nova instrução foi aceita ao criar um fork de um histórico concluído. Diante desse contraexemplo, o próprio relator original observou que não se trata de uma solução geral.

Um fork é uma operação que leva um histórico concluído para uma tarefa separada; a tarefa original não é corrigida. Não presuma que um trabalho inacabado simplesmente vai continuar. Depois da transferência, verifique o diretório de trabalho, os arquivos alterados e a última etapa que foi concluída.

Os dados do histórico e os arquivos de trabalho também são coisas separadas. Mesmo que a conversa não abra, as edições do projeto podem continuar lá. Por outro lado, mesmo que você consiga ler a conversa, os arquivos podem não estar atualizados. Se o projeto usar Git, revise a lista de alterações e organize o que já foi executado antes de continuar.

6. Informações a guardar ao pedir uma investigação

Ao relatar o problema, separe não só "não consigo enviar", mas também o que deu certo e o que falhou. A versão do app, o sistema operacional, o horário da ocorrência com o fuso horário, o ID da conversa de destino e a operação feita logo antes facilitam o rastreamento sem misturar falhas de outra natureza. Você não precisa publicar a conversa inteira desde o início.

Se for possível examinar os registros, vale observar as linhas antes e depois da solicitação que falhou. method=turn/start indica o início de uma instrução, thread/resume indica a retomada da conversa, e errorCode é uma pista da resposta interna. Guarde também as linhas de sucesso e distinga se a mesma falha aparece apenas em várias linhas de registro ou se ela realmente falhou várias vezes.

Como local dos registros do app, a documentação oficial de solução de problemas indica ~/Library/Logs/com.openai.codex/YYYY/MM/DD no macOS. No Windows, em nosso ambiente, eles estavam nestes dois lugares.

• PC em que o erro apareceu: %LOCALAPPDATA%\Codex\Logs
• Versão da Microsoft Store em outro PC (registros de março de 2026): %LOCALAPPDATA%\Packages\OpenAI.Codex_<ID>\LocalCache\Local\Codex\Logs (este PC não tinha a pasta %LOCALAPPDATA%\Codex)

Segundo a explicação da Microsoft, os arquivos que um app empacotado cria novos no AppData são gravados em um local exclusivo do app e podem aparecer para ele como se estivessem no local normal. Se não encontrar em um lugar, procure também no outro. A orientação oficial diz que os dados de sessão são guardados em $CODEX_HOME/sessions (padrão ~/.codex/sessions). Se suas configurações ou o local de execução forem diferentes, o alvo pode simplesmente não estar na pasta que você está olhando; por isso, não conclua que ele foi excluído só porque "a busca não encontra".

Se você mudou o CODEX_HOME do Codex ou o próprio app para outro drive, registramos onde ficou cada coisa em Como mover o ChatGPT e o Codex para outro drive.

A documentação oficial de solução de problemas explica como enviar feedback digitando / no campo de entrada. Registros e capturas de tela podem conter texto de conversas, endereços de e-mail, nomes de outros projetos e caminhos locais. Em uma issue pública, inclua apenas as partes necessárias, anonimizadas, e, ao enviar IDs completos ou informações semelhantes, confirme o destinatário e quem poderá ver.

7. Confirme a recuperação com uma resposta curta

A primeira resposta a este erro não é apagar o histórico, mas verificar separadamente se você consegue lê-lo, se consegue retomá-lo e se uma nova instrução é concluída. Neste caso, o envio voltou depois de recarregar a conversa. Se aparecer um erro de armazenamento, o caminho é outro; siga para as verificações da seção 5.

Quando uma resposta curta for concluída, verifique até onde a instrução original foi executada e retome a partir da etapa necessária. Se ainda não resolver, priorize a investigação somente leitura e a preservação dos registros. É importante não considerar a recuperação concluída só porque a mensagem de erro sumiu ou porque foi possível criar um fork.

Artigos relacionados:

• Erros de capacidade do Codex e esgotamento da cota de uso: diferenças e como resolver (quando aparece "Selected model is at capacity")
• Requisitos de conexão do Remote e verificações após a desconexão (local de execução e suspensão do PC)
• Erros semelhantes no Claude Code: Prompt is too long (tamanho da entrada) e MCP error -32000: Connection closed (conexão com ferramentas externas)

FAQ

P. Se aparecer "thread not found", a conversa foi apagada?
R. Não necessariamente. O histórico salvo pode continuar legível enquanto a conversa necessária como destino de envio para execução não foi carregada. Por outro lado, a referência de armazenamento ou os próprios arquivos podem ter algum problema; por isso, verifique se você consegue realmente lê-los.

P. notLoaded é um erro?
R. Esse estado em si é normal. Ele indica que uma conversa salva não está carregada para execução no momento. Só se torna um problema quando, ao continuar, ela não é retomada e nem mesmo uma resposta curta é concluída.

P. Reiniciar sempre resolve?
R. Não necessariamente. Há relatos em que a reinicialização completa resolveu o problema (#30710) e relatos em que as falhas de envio e arquivamento continuaram depois da reinicialização (#39179). No nosso exemplo, o envio voltou depois que a conversa foi recarregada.

P. Atualizar para a versão mais recente resolve?
R. Em 21 de setembro de 2026, não encontramos nenhuma versão corrigida que afirme explicitamente ter resolvido todo este sintoma. Ao atualizar, registre as versões do app antes e depois e os resultados. A CLI instalada separadamente e o Codex incluído no app não são necessariamente da mesma versão.