Codex: como lidar com “thread not found” sem apagar o histórico

O erro “thread not found” do Codex não significa necessariamente que o histórico foi perdido. Primeiro, verifique se apenas o envio falha ou se você também não consegue abrir a conversa.

1. O que está faltando quando o Codex mostra thread not found?

O Codex da OpenAI pode mostrar um erro como o seguinte ao enviar uma nova instrução a uma tarefa existente. O ID identifica a conversa e foi ocultado aqui. A primeira linha abaixo traduz a mensagem em japonês observada no nosso caso.

Ocorreu um erro ao enviar a mensagem
thread not found: <ID da conversa>

Este artigo aborda tarefas locais existentes no aplicativo para desktop. Em 21 de setembro de 2026, comparamos os registros de envios malsucedidos do nosso computador com o código-fonte público e relatos de usuários. O foco é o nosso caso no Windows, não um método de reparo comprovado em todos os ambientes.

A especificação oficial do App Server explica que thread/read lê o histórico salvo sem carregar a conversa na memória de execução. Sua função difere da de thread/resume, que retoma uma conversa para continuar o trabalho. São métodos de comunicação interna, não comandos para digitar no chat.

Também comparamos a versão da CLI 0.155.0-alpha.9, registrada nos metadados salvos do nosso computador, com o correspondente código-fonte público do envio. O ponto de entrada de turn/start busca a conversa e retorna thread not found se essa busca falhar. A procura ocorre na lista de conversas em memória, portanto esse erro, isoladamente, não demonstra que os arquivos salvos desapareceram.

notLoaded não é, por si só, um estado de erro. Significa que uma conversa salva não está carregada naquele momento para execução. O problema surge quando a retomada necessária não acontece e a conversa não consegue aceitar a próxima instrução. O texto sozinho não permite distinguir entre uma remoção normal da memória, um problema para localizar dados armazenados, um ID de conversa incorreto ou outras causas.

2. Caso real: o envio voltou sem apagar o histórico

No ambiente de trabalho do AI Arte, esse erro apareceu ao enviarmos uma instrução para continuar outra tarefa na versão Windows do aplicativo 26.915.31029. A linha do tempo abaixo resume os registros do aplicativo de 21 de setembro de 2026. Todos os horários estão no horário padrão do Japão (JST); IDs de conversa, detalhes do trabalho e informações pessoais foram omitidos.

A conversa salva e o diretório de trabalho existiam, e a leitura do histórico funcionou. A tarefa original não estava arquivada. Inspecionamos os registros e o estado armazenado somente para leitura, sem alterar o banco de dados de conversas ou as configurações.

Uma divergência entre o estado “retomado” da interface e o estado interno é uma explicação forte. Porém, não reproduzimos o problema para identificar exatamente como essa divergência surgiu. Verificar o estado dos últimos turnos também não equivale a conferir a correção do trabalho realizado neles. Nossas verificações de recuperação abrangem apenas o envio e o estado da conversa.

3. O que tentar quando apenas o envio falha

Primeiro, guarde uma cópia do texto digitado para não perdê-lo. Antes de pressionar enviar repetidamente, verifique se a mesma instrução já apareceu na conversa ou se o processamento começou. Evite duplicar uma solicitação cuja resposta esteja apenas atrasada, especialmente se envolver publicar, excluir ou comprar algo.

Por exemplo, limite o escopo da verificação como mostrado abaixo. Trata-se de uma instrução ao modelo, não de um comando que repara o aplicativo. O envio e a resposta do modelo podem contar como uso normal.

Esta é uma verificação de conexão. Não retome trabalhos anteriores,
não leia nem grave arquivos e não use ferramentas.
Responda apenas “Resposta recebida”.

O relato #30710 no repositório da OpenAI no GitHub descreve um caso no Windows em que reiniciar melhorou as falhas de envio logo após abrir uma conversa. O guia oficial de solução de problemas recomenda aguardar a conclusão das tarefas ativas e reiniciar quando o terminal integrado trava. Essa orientação não é um procedimento de recuperação específico para este erro de envio. Nenhuma das fontes garante que reiniciar resolva todos os erros thread not found.

Se tentar uma atualização, registre primeiro a versão atual do aplicativo e os sintomas. A versão do Codex incluída no aplicativo pode ser diferente de uma CLI instalada separadamente. Atualizar apenas a CLI não comprova que o problema do aplicativo para desktop foi corrigido. Não identificamos uma versão que resolva definitivamente esse sintoma.

4. Mensagens parecidas, causas e soluções diferentes

Não se limite ao título informando que o envio falhou: leia o restante do erro e identifique a operação que falhou. A tabela abaixo agrupa relatos públicos e nossas observações; não é uma classificação da frequência de cada problema.

Para um exemplo em que o histórico continuou disponível, veja o comentário posterior do usuário de macOS em #30710. A interface considerava a conversa retomada, mas o envio falhava repetidamente; uma nova instância da interface conseguiu recarregá-la depois. Isso descreve uma divergência de estado que não se explica apenas por uma condição de corrida imediatamente após a abertura. É semelhante ao nosso caso, mas não foi comprovado que a causa seja idêntica.

Em contraste, o relato de Windows #39179 descreve falhas de envio e arquivamento que persistiram após reiniciar. #39575 também inclui um diagnóstico envolvendo marcas de tempo nos nomes dos arquivos salvos e o processo de busca. No entanto, são investigações de usuários. Um prefixo de caminho ou uma diferença de fuso horário, isoladamente, não comprova que seus dados estejam danificados.

Para falhas após uma espera, veja o relato de tempo limite de envio excedido em #27395; para falhas que também afetam a interrupção, veja o relato de divergência entre histórico e estado de execução em #42604. Relatos de mensagens semelhantes não demonstram que o problema seja frequente entre todos os usuários. Nossa investigação não encontrou uma taxa de incidência calculada sobre um total de usuários ou tentativas de envio.

5. Verificações e opções para continuar se o problema persistir

Se reiniciar não ajudar, verifique se o histórico salvo pode ser lido. Se o ambiente permitir inspecionar a tarefa afetada a partir de outra tarefa do Codex que funcione, comece com uma verificação somente de leitura. Confirme o ID de destino em vez de simplesmente escolher uma tarefa com nome parecido.

Investigue a tarefa indicada somente para leitura.
ID de destino: cole aqui o ID de conversa mostrado no erro

Informe se o histórico pode ser lido, o estado do último turno e os erros.
Não envie mensagens a outra tarefa, não retome trabalhos anteriores,
não crie ramificações nem arquive tarefas. Não altere configurações,
não edite o banco de dados e não mova nem exclua arquivos do histórico.
Se não houver ferramentas de gerenciamento de tarefas, informe essa limitação.

Este é um exemplo de solicitação para um ambiente com ferramentas de gerenciamento de tarefas. Elas não estão disponíveis em todas as interfaces ou CLIs. Se não encontrar o recurso, não é necessário adivinhar e executar comandos internos de nome semelhante.

Um comentário posterior em #39179 descreve uma verificação curta enviada de outra tarefa que funcionava; depois de a resposta terminar, a conversa normal também voltou a funcionar. Porém, outro comentário posterior relata que esse mesmo tipo de envio falhou, enquanto uma ramificação do histórico dos turnos concluídos aceitou uma nova instrução. Diante desse contraexemplo, o autor do primeiro relato esclareceu que não se tratava de uma solução geral.

Criar uma ramificação é uma opção para levar o histórico dos turnos concluídos a outra tarefa, não um reparo da tarefa original. Não presuma que o trabalho inacabado será reproduzido como estava. Após a transferência, verifique o diretório de trabalho, os arquivos alterados e a última etapa concluída. Um relato público de que uma nova instrução foi aceita também não garante que o trabalho posterior tenha terminado corretamente.

O histórico da conversa e os arquivos de trabalho também são separados. As alterações do projeto podem continuar presentes mesmo que a conversa não abra. Por outro lado, um histórico legível não garante que os arquivos estejam atualizados. Em um projeto Git, revise as alterações e determine o que já foi executado antes de continuar.

6. O que registrar ao pedir ajuda

Separe o que funcionou do que falhou, em vez de relatar apenas “não consigo enviar”. A versão do aplicativo, o sistema operacional, o horário e o fuso, o ID da conversa e a ação anterior ajudam a distinguir os tipos de falha. Não é necessário publicar toda a conversa logo de início.

Se puder inspecionar os registros, examine as entradas próximas da solicitação que falhou. method=turn/start marca o início de uma instrução, thread/resume retoma uma conversa e errorCode dá uma pista sobre a resposta interna. Guarde também as entradas bem-sucedidas e diferencie uma única falha registrada em várias linhas de várias solicitações que realmente falharam.

No nosso computador Windows, os registros do aplicativo estavam em %LOCALAPPDATA%\Codex\Logs. Essa foi a localização verificada nesta máquina, não uma garantia para todas as distribuições. A documentação oficial situa as sessões em $CODEX_HOME/sessions, com o padrão ~/.codex/sessions. Configurações ou destinos de execução diferentes podem simplesmente significar que os dados relevantes não estão na pasta consultada. Não encontrá-los em uma busca não comprova que foram excluídos.

O guia oficial de solução de problemas explica como enviar feedback digitando / no campo de mensagem. Registros e capturas de tela podem conter texto de conversas, endereços de e-mail, nomes de outros projetos e caminhos locais. Inclua em um relato público apenas as partes necessárias e anonimizadas. Antes de compartilhar IDs completos ou detalhes semelhantes, confira o destinatário e quem poderá acessar o envio.

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

Em vez de começar apagando o histórico, verifique três coisas separadamente: é possível lê-lo, retomá-lo e concluir uma nova instrução? No nosso caso, o envio funcionou depois de recarregar, mas isso não demonstra que o mesmo método resolva erros de armazenamento sem relação com esse caso.

Quando uma resposta curta terminar, confira até onde a instrução original chegou e retome a partir da etapa adequada. Se o problema persistir, priorize a investigação somente de leitura e a preservação dos registros. O desaparecimento de uma mensagem de erro ou a criação bem-sucedida de uma ramificação não basta para declarar a recuperação concluída.

Claude Code também pode apresentar Prompt is too long, relacionado à capacidade de entrada, ou MCP error -32000: Connection closed, que exige verificar a conexão com ferramentas externas. São erros diferentes em outro produto. Mesmo que o sintoma pareça “não consigo dar instruções à IA”, escolha a ação pelo nome do produto e pela mensagem completa. Os comandos de diagnóstico desses erros não devem ser simplesmente reutilizados em uma conversa do Codex.

Perguntas frequentes

Q. thread not found significa que a conversa foi excluída?
A. Não necessariamente. O histórico salvo pode continuar legível mesmo que a conversa necessária para receber uma mensagem não esteja carregada para execução. Porém, também pode haver problemas nas referências aos dados armazenados ou nos próprios arquivos; verifique se é realmente possível ler o histórico.

Q. notLoaded é um erro?
A. O nome do estado, por si só, não comprova um erro. Pode descrever uma situação normal em que uma conversa salva não está carregada para execução naquele momento. Verifique se ela é retomada ao continuar e se uma resposta curta termina.

Q. Reiniciar sempre resolve?
A. Não. Alguns relatos descrevem melhora, enquanto outros mencionam erros de armazenamento ou arquivamento que persistiram após reiniciar. No nosso computador, observamos envios bem-sucedidos depois de recarregar a conversa; não fizemos um experimento para testar a reinicialização.

Q. Atualizar para a versão mais recente resolve?
A. No momento da revisão, não havíamos verificado uma versão específica que resolvesse todo esse conjunto de sintomas. Registre a versão do aplicativo e os resultados antes e depois de atualizar. Uma CLI instalada separadamente e a versão do Codex incluída no aplicativo não são necessariamente iguais.