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

Depois de quedas de energia, meus projetos desapareceram do Codex no Windows, mas as conversas continuavam intactas. Descobri onde o índice é salvo e como reconstruí-lo sem apagar o histórico.

Asllan Maciel Publicado em 02/09/2026

Atualizado em 02/09/2026 Categorias: Inteligência Artificial

Palavras: 1813Tempo de Leitura: 10 Minutos

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 é:

fechar o Codex antes da alteração;
criar um backup com timestamp do .codex-global-state.json;
consultar os cwd das threads não arquivadas em state_5.sqlite;
normalizar caminhos no formato \\?\G:\... quando necessário;
ignorar diretórios que não existem mais;
preservar projetos já registrados;
recriar somente os projetos ausentes;
atualizar project-order;
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.