Projetos sumiram do Codex no Windows? Como recuperei sem perder as conversas

Recentemente passei duas vezes pelo mesmo problema no Codex para Windows: depois de um desligamento inesperado do computador, os projetos locais simplesmente desapareceram da barra lateral.

Na segunda ocorrência, o padrão ficou muito claro. O aplicativo pediu autenticação novamente, abriu normalmente e minhas conversas continuavam aparecendo em Recentes, mas a seção Projetos estava vazia.

A primeira reação pode ser imaginar que os projetos ou as conversas foram perdidos. No meu caso, não foram.

Depois de investigar o estado local do aplicativo, descobri que os diretórios continuavam no disco, as conversas continuavam no banco local e ainda guardavam o caminho correto de cada projeto. O que havia sido perdido era o registro usado pela interface para montar a lista de projetos.

Neste artigo vou mostrar exatamente como diagnostiquei o problema e como consegui reconstruir os projetos sem apagar minhas conversas.

Importante: os arquivos internos do Codex podem mudar entre versões. Faça backup antes de editar qualquer coisa dentro de .codex. O procedimento abaixo descreve o comportamento que encontrei no Windows em agosto de 2026.

O sintoma: conversas existem, projetos não

O problema aconteceu depois de quedas de energia enquanto o Codex estava aberto e processando tarefas.

Ao voltar ao aplicativo, encontrei uma situação curiosa:

• os diretórios dos projetos continuavam normalmente no disco;
• várias conversas continuavam aparecendo em Recentes;
• ao abrir uma conversa, ela ainda conhecia o repositório e o diretório de trabalho;
• a seção Projetos, porém, estava vazia ou mostrava apenas alguns projetos recentes.

Essa diferença foi a pista principal. Se a conversa ainda sabe em qual diretório trabalhou, talvez o conteúdo não tenha sido perdido. O problema pode estar apenas no catálogo usado pela interface.

Onde encontrei os dados

No Windows, o estado local que investiguei fica em:

C:\Users\SEU_USUARIO\.codex

Dois arquivos foram fundamentais no diagnóstico:

state_5.sqlite
.codex-global-state.json

Eles têm papéis diferentes.

No meu ambiente, o state_5.sqlite continuava contendo as threads e seus diretórios de trabalho (cwd). Já o .codex-global-state.json continha estruturas usadas pelo aplicativo para organizar os projetos na interface, incluindo local-projects e project-order.

Foi justamente aí que encontrei a inconsistência.

Primeiro: verifique se suas conversas ainda conhecem os projetos

Eu já tinha o sqlite3 disponível no Windows. Com o Codex fechado, consultei o banco assim:

sqlite3 "$env:USERPROFILE\.codex\state_5.sqlite" "
SELECT cwd, COUNT(*) AS total
FROM threads
WHERE archived = 0
GROUP BY cwd
ORDER BY total DESC;
"

No meu caso, o resultado trouxe vários diretórios que haviam desaparecido da barra lateral, por exemplo:

G:\Meus Projetos\ProjetoA        20
G:\Meus Projetos\ProjetoB         7
G:\Meus Projetos\ProjetoC         2

Também confirmei que os diretórios realmente existiam:

Test-Path "G:\Meus Projetos\ProjetoA"

O retorno era True.

Isso mudou completamente o diagnóstico: os projetos físicos existiam e as threads continuavam associadas aos respectivos cwd no banco.

O arquivo que havia perdido o índice

Em seguida, analisei:

%USERPROFILE%\.codex\.codex-global-state.json

Dentro dele encontrei uma estrutura semelhante a:

{
  "local-projects": {
    "ID_DO_PROJETO": {
      "id": "ID_DO_PROJETO",
      "name": "ProjetoA",
      "rootPaths": [
        "G:\\Meus Projetos\\ProjetoA"
      ]
    }
  },
  "project-order": [
    "ID_DO_PROJETO"
  ]
}

O problema era simples de explicar depois que o encontramos: local-projects não continha mais os projetos antigos.

Em uma das ocorrências, havia sobrado apenas um projeto. Em outra, a interface chegou a mostrar Nenhum projeto.

As conversas, porém, continuavam no state_5.sqlite.

Portanto, no meu caso, não era perda do código nem necessariamente perda das conversas. Era perda de metadados de organização da interface.

Antes de reparar: faça backup

Antes de alterar o estado global, feche completamente o Codex/ChatGPT Desktop.

Depois faça uma cópia:

Copy-Item `
  "$env:USERPROFILE\.codex\.codex-global-state.json" `
  "$env:USERPROFILE\.codex\.codex-global-state.json.backup-manual"

Confirme:

Test-Path "$env:USERPROFILE\.codex\.codex-global-state.json.backup-manual"

O esperado é:

True

Não recomendo modificar esse JSON com o aplicativo aberto, porque o processo pode manter estado em memória e gravá-lo novamente no arquivo.

Como recuperei os projetos

Depois de confirmar os diretórios pelo SQLite, reconstruí as entradas ausentes de local-projects e atualizei project-order.

Uma entrada de projeto precisa ter um identificador, nome e pelo menos um rootPaths válido. Em PowerShell, a estrutura que usei para cada projeto foi equivalente a:

$id = [guid]::NewGuid().ToString()
$agora = [DateTimeOffset]::UtcNow.ToUnixTimeMilliseconds()

$dados = [PSCustomObject]@{
    id        = $id
    name      = "ProjetoA"
    rootPaths = @("G:\Meus Projetos\ProjetoA")
    createdAt = $agora
    updatedAt = $agora
}

Depois de salvar o JSON como UTF-8 válido e abrir novamente o Codex, os projetos reapareceram na barra lateral.

As conversas relacionadas também voltaram a ser exibidas dentro dos respectivos projetos.

Automatizei a recuperação com PowerShell

Como o problema aconteceu novamente após outra queda de energia, repetir todo o diagnóstico manualmente deixou de fazer sentido.

Criei então um script PowerShell para automatizar a reconstrução.

A estratégia é:

1. fechar o Codex antes da alteração;
2. criar um backup com timestamp do .codex-global-state.json;
3. consultar os cwd das threads não arquivadas em state_5.sqlite;
4. normalizar caminhos no formato \\?\G:\... quando necessário;
5. ignorar diretórios que não existem mais;
6. preservar projetos já registrados;
7. recriar somente os projetos ausentes;
8. atualizar project-order;
9. validar o JSON antes de considerar a recuperação concluída.

Isso torna a recuperação muito menos arriscada do que editar manualmente dezenas de IDs e caminhos.

Por que reinstalar o aplicativo não resolveu?

Antes de encontrar a causa, tentei caminhos que normalmente resolveriam um aplicativo quebrado: reparar, restaurar e reinstalar.

Nada disso trouxe os projetos de volta.

O motivo ficou evidente depois: o problema estava em dados persistentes do perfil do usuário dentro de .codex, não nos binários instalados do aplicativo.

Reinstalar o pacote não necessariamente reconstrói o catálogo de projetos a partir das threads existentes.

Por isso é importante não confundir reinstalar o Codex com reconstruir o estado local do Codex.

Não é um caso isolado

Depois de resolver o problema localmente, pesquisei relatos públicos e encontrei issues no repositório oficial do Codex descrevendo comportamentos muito próximos.

Há relato específico de perda de estado após queda de energia no Windows em que .codex-global-state.json foi reduzido a um estado mínimo, enquanto a reconstrução utilizou informações preservadas no state_5.sqlite.

Também existem relatos recentes em que local-projects foi substituído por um mapa vazio durante atualização do aplicativo, enquanto as pastas dos projetos e os dados das threads permaneceram intactos. Em outro caso, um .codex-global-state.json preenchido com bytes NUL foi interpretado como estado vazio e o backup .bak acabou recebendo o mesmo estado já danificado.

Outro relato de agosto de 2026 descreve projetos históricos desaparecendo da interface enquanto tarefas recentes, banco local e diretórios físicos continuavam existentes.

Ou seja: embora o gatilho não seja necessariamente o mesmo em todos os casos, existe evidência pública de uma classe real de problemas envolvendo persistência e reconstrução do estado local de projetos no Codex para Windows.

Cuidado com o .bak

Um detalhe importante encontrado nos relatos públicos é que o arquivo:

.codex-global-state.json.bak

não deve ser tratado automaticamente como um backup histórico confiável.

Há casos em que o aplicativo grava o estado atual no arquivo principal e depois replica esse mesmo estado para o .bak. Se o estado em memória já estiver vazio ou corrompido, os dois arquivos podem terminar igualmente inutilizáveis para recuperação.

Por isso passei a preferir backups próprios com timestamp antes de qualquer alteração.

Como reduzir o risco

Depois de passar por isso duas vezes, algumas medidas simples passaram a fazer sentido no meu ambiente:

• manter backups periódicos do .codex-global-state.json;
• não depender apenas do .bak criado pelo aplicativo;
• fechar completamente o Codex antes de manipular seus arquivos de estado;
• não apagar state_5.sqlite, sessions ou a pasta .codex inteira ao primeiro sinal de problema;
• verificar primeiro se as threads e seus cwd continuam no banco;
• manter o código dos projetos normalmente versionado no Git, independentemente do estado do Codex.

A principal regra é simples: se os projetos sumiram da interface, não conclua imediatamente que os dados foram apagados.

Diagnóstico rápido

Se isso acontecer com você, eu seguiria esta ordem:

1. Feche completamente o Codex

Não edite o estado enquanto o aplicativo estiver aberto.

2. Faça backup da pasta ou pelo menos do estado global

Copy-Item `
  "$env:USERPROFILE\.codex\.codex-global-state.json" `
  "$env:USERPROFILE\.codex\.codex-global-state.json.backup-manual"

3. Consulte os projetos conhecidos pelas threads

sqlite3 "$env:USERPROFILE\.codex\state_5.sqlite" "
SELECT cwd, COUNT(*) AS total
FROM threads
WHERE archived = 0
GROUP BY cwd
ORDER BY total DESC;
"

4. Confira se os diretórios existem

Test-Path "C:\caminho\do\seu\projeto"

5. Só então investigue local-projects

Procure no arquivo:

%USERPROFILE%\.codex\.codex-global-state.json

Se as threads apontam para diretórios válidos, mas esses diretórios não aparecem em local-projects, você pode estar diante do mesmo tipo de inconsistência que encontrei.

O que eu não faria

Depois de toda essa investigação, há algumas ações que eu evitaria como primeira tentativa:

• apagar a pasta .codex inteira;
• excluir state_5.sqlite;
• apagar sessions;
• presumir que reinstalar o aplicativo recuperará o índice;
• editar o JSON sem backup;
• confiar cegamente no .bak como única cópia de segurança.

O objetivo da recuperação deve ser preservar o máximo possível e reconstruir apenas o que realmente foi perdido.

Conclusão

A parte mais interessante desse problema é que a interface dava a impressão de perda muito maior do que realmente havia ocorrido.

No meu caso, a situação podia ser resumida assim:

state_5.sqlite
      ↓
threads + cwd continuavam existentes

.codex-global-state.json
      ↓
local-projects perdeu registros

interface do Codex
      ↓
projetos desaparecem

Reconstruindo o catálogo de projetos, a interface voltou a enxergar os diretórios e as conversas relacionadas.

E a confirmação mais importante veio quando o problema aconteceu pela segunda vez: executei a recuperação novamente e os projetos voltaram.

Se você chegou aqui porque abriu o Codex e encontrou Nenhum projeto, mas ainda consegue encontrar suas conversas em Recentes, não comece apagando tudo.

Há uma boa chance de o conteúdo ainda estar no seu computador e o problema estar apenas no estado usado para organizar esses dados na interface.

Enquanto esse tipo de falha não estiver completamente eliminado no aplicativo, manter um backup independente do estado local e conhecer a estrutura de recuperação pode economizar bastante tempo — e alguns sustos.