Erro Cannot serialize value no Codex: o que verificar quando um novo chat falha

Se um novo chat do Codex falhar com Cannot serialize value: (couldn't stringify value), anote a versão instalada e procure uma atualização primeiro. Se o erro persistir, compare um novo chat Local com um novo chat Worktree no mesmo projeto. Não comece apagando o histórico, trocando chaves de API ou redefinindo o repositório.

Esse erro exato apareceu em relatos sobre o aplicativo desktop em outubro de 2026. A discussão do problema já foi encerrada, e usuários relataram recuperação em builds específicos de macOS e Windows. Por isso, verificar a versão é mais útil do que presumir que o incidente antigo continua afetando todas as instalações.

Este guia trata de um novo chat que falha ao enviar a primeira mensagem, especialmente quando Worktree está selecionado. Ele se baseia em relatos públicos e em um procedimento conservador de diagnóstico; a Ofox não reproduziu a falha original em uma instalação controlada. As etapas abaixo são verificações e alternativas condicionais, não uma correção universal nem uma afirmação de que uma chave de API da Ofox corrige o Codex.

Confira a versão antes de aplicar uma solução alternativa antiga

O quadro abaixo resume a issue #55744 no repositório da OpenAI, consultada em 28 de outubro. São relatos de usuários, não uma matriz de suporte válida para todas as plataformas.

O comentário de recuperação no macOS e o comentário de recuperação no Windows são observações distintas. Quando o atualizador diz que um build antigo está “atualizado”, ele informa apenas o que aquela instalação consegue obter no momento; isso não prova que a correção relatada em outra plataforma esteja instalada.

Salve o prompt ainda não enviado em um local privado, conclua ou pause o trabalho em andamento e use o mecanismo de atualização previsto pelo aplicativo. Registre a versão antes e depois. Reinicie quando o atualizador solicitar, reabra o mesmo projeto e envie novamente uma mensagem pequena. Evite baixar um pacote antigo do aplicativo de uma fonte não oficial ou editar os arquivos instalados.

Confirme se é a mesma falha

“Serialização” é a conversão de um valor para transporte ou armazenamento. O texto da mensagem, por si só, não informa qual valor falhou, se houve envio de uma solicitação ao modelo ou se o seu repositório está danificado.

Registre três informações antes de mudar configurações:

1. Etapa: o aplicativo não abriu, a primeira mensagem não foi enviada ou uma tarefa em andamento falhou depois?
2. Modo: o novo chat estava em Local ou Worktree? Estava vinculado a um projeto Git?
3. Erro exato: copie a mensagem curta completa, incluindo o texto entre parênteses. Registre separadamente qualquer erro exibido ao lado.

Se a mensagem real for couldn’t load workspace settings, investigue a inicialização do espaço de trabalho. Se a extensão informar couldn’t load its resources, use o guia de carregamento de recursos. Se a área de composição indicar permission mode is unavailable, siga a lista de verificação de envio correspondente. O fato de os erros ocorrerem em momentos parecidos não demonstra uma causa comum.

A issue inclui investigações sobre o serializador no cliente, entre elas uma hipótese envolvendo atributos de documentos de texto formatado. Esses relatos ajudam a localizar um possível ponto de falha; eles não justificam orientar todos os usuários a remover pontuação, excluir texto em chinês ou reescrever os arquivos JSON do repositório. Um prompt curto em texto simples serve como controle, não como solução garantida.

Compare Local e Worktree sem colocar alterações do projeto em risco

Use um prompt apenas para diagnóstico, em vez da tarefa real:

Responda apenas com OK. Não leia nem modifique arquivos, não execute
comandos, não instale dependências e não inicie nenhuma tarefa do projeto.

Mantenha a mesma conta, o mesmo projeto e a mesma versão. Primeiro, tente um novo chat Local. Depois, tente um novo chat Worktree com o mesmo prompt. Criar um worktree pode executar o processo de configuração definido pelo projeto: revise essa configuração antes e use um repositório de teste sem riscos se o processo puder causar efeitos colaterais. Não repita o teste em projetos de produção apenas para reunir mais exemplos.

Pare quando obtiver uma comparação útil. Clicar repetidamente em Enviar gera ruído e pode dificultar a identificação da primeira falha. Uma resposta do modelo em Local comprova apenas que esse caminho funcionou naquele momento; ela não testa isolamento nem a configuração do Worktree.

Se Local funcionar, escolha conscientemente uma alternativa temporária

Local opera no checkout selecionado. Um worktree separado fornece outro diretório de trabalho. Portanto, mudar para Local altera o local em que as operações do projeto podem acontecer; não oferece a mesma garantia de isolamento.

Para uma conversa somente de leitura, permanecer em um chat Local que funciona pode ser suficiente. Antes de permitir edições, inspecione o checkout e coordene o uso com outros trabalhos que o utilizam. Preserve arquivos não rastreados e alterações ainda não commitadas. Não use git reset --hard, git clean ou exclusão de cache como correções genéricas para erros de serialização.

Para uma tarefa que exige isolamento, a issue contém relatos de iniciar em Local e depois criar um worktree gerenciado pelo aplicativo. Trate isso como uma alternativa condicional: use-a apenas se o recurso estiver realmente disponível no aplicativo instalado e verifique o diretório retornado antes de qualquer edição. Uma instrução adequada é:

Não edite o checkout atual. Primeiro, identifique a branch ou o commit
inicial pretendido e informe o commit resolvido. Crie um worktree
gerenciado separado usando o recurso suportado pelo aplicativo, se
estiver disponível. Informe o diretório absoluto e o HEAD. Execute
todas as operações posteriores do projeto nesse diretório. Se a criação
ou a vinculação falhar, pare antes de editar arquivos e informe o erro.

Use como revisão inicial a que sua tarefa realmente exige; não substitua automaticamente por master. Um novo worktree não recebe automaticamente as alterações não commitadas do checkout original. Se precisar delas, planeje a transferência explicitamente depois de preservá-las.

Antes de continuar, inspecione o local retornado com comandos Git somente de leitura:

git -C /absolute/path/to/worktree rev-parse --show-toplevel
git -C /absolute/path/to/worktree rev-parse HEAD
git -C /absolute/path/to/worktree status --short
git -C /absolute/path/to/worktree worktree list

Use o caminho real, entre aspas se contiver espaços. Confirme que o diretório é separado, que o commit corresponde à revisão inicial combinada e que todas as alterações iniciais são compreendidas. A mera criação de um diretório não comprova que o aplicativo o vinculou nem que os próximos comandos serão executados nele. Se o aplicativo não disponibilizar o recurso suportado, mantenha o trabalho somente de leitura ou use um fluxo de desenvolvimento já suportado; não apresente uma simples cópia de pasta como um worktree gerenciado.

Reúna diagnósticos para um relato útil

Use o canal de feedback ou diagnóstico previsto pelo aplicativo. Os relatos públicos incluem TypeError, falha de envio na área de composição e mode=worktree; procure o evento correspondente perto do horário do seu teste, em vez de copiar o stack trace de outra pessoa.

Registre apenas o evento relevante e seu contexto. Um log bruto pode conter prompts, caminhos locais, nomes de repositórios, dados de autenticação ou identificadores de sessão. Remova ou oculte esses dados antes de compartilhar. O modelo abaixo é uma ficha editorial de apoio, não um log observado:

Sistema operacional e arquitetura:
Versão/build do aplicativo desktop:
Horário do teste e fuso horário:
Erro exato exibido:
Chat novo ou existente:
Tipo de projeto: Git / sem Git / nenhum
Teste Local: sucesso / erro exato / não testado
Teste Worktree: sucesso / erro exato / não testado
Atualização oferecida e resultado:
Foi criado um diretório de worktree?
Campos de diagnóstico relevantes sem dados sensíveis:
O que mudou entre os testes:

Não apresente uma hipótese sobre o mecanismo do serializador como causa confirmada na sua máquina. Para os mantenedores, a distinção útil é saber se a falha ocorre antes de existir um worktree, durante a configuração ou depois de uma tarefa começar. Informe essa distinção e uma reprodução mínima, sem enviar código-fonte proprietário.

Decida se a recuperação está completa

Recuperação significa que a operação necessária voltou a funcionar, não apenas que um aviso desapareceu. Para uma falha na criação direta de Worktree, verifique se um novo chat Worktree aceita o prompt pequeno, se o aplicativo mostra o checkout pretendido e se um segundo chat novo também inicia. Depois, retome uma tarefa real pequena no diretório verificado e inspecione as alterações.

Se apenas Local funcionar, registre alternativa temporária disponível; criação direta de Worktree continua falhando. Se não houver atualização disponível, guarde a versão e as evidências de diagnóstico para o suporte. Se a mensagem mudar, investigue o novo erro pelo índice de erros do Codex, em vez de aplicar todas as medidas da discussão antiga.

A Ofox publica este guia de diagnóstico para desenvolvedores. Trocar de provedor de modelos, comprar créditos de API ou aumentar limites de uso não comprova a correção de uma falha de serialização no aplicativo desktop.