Codex Chats Disappeared After an Update? Recover Safely

If Codex Desktop shows no old chats after an update, do not uninstall it, clear app data, delete %USERPROFILE%\.codex, edit its SQLite files, or reset the repository. First close Codex, copy the entire local state directory, and determine whether the transcript files still exist. Missing sidebar entries and missing transcript files are different failures, and the safe recovery path depends on which one you have.

Recent Windows reports show both cases. Some users could still find old threads in Search, another Codex surface, local JSONL files, or the state database even though the sidebar was empty. A July 27 report described a more serious case in which 934 of 942 rollout JSONL files were absent while their database rows remained. Treat the symptom as possible data loss until a verified backup proves otherwise.

What You Need Before Recovery

Use this guide on Windows when a Codex Desktop update is followed by one or more of these symptoms:

• projects show No chats or old conversations vanish from the sidebar;

• Search or the VS Code extension can see threads that Desktop does not list;

• a resumed thread fails because its rollout JSONL path is missing;

• Codex settings appear reset;

• tracked files are unexpectedly missing from a repository.

You need PowerShell, enough free space for a copy of %USERPROFILE%\.codex, and Git for any affected repository. If project files are missing, do not let Codex continue editing that repository until you finish the inventory.

Step 1: Stop Writers and Preserve Codex State

Close Codex Desktop and any Codex CLI processes that are using the same account state. Confirm no process remains:

Get-Process Codex,codex -ErrorAction SilentlyContinue

Then copy the state directory to a new timestamped folder on the Desktop:

$CodexState = Join-Path $env:USERPROFILE ".codex"
$Stamp = Get-Date -Format "yyyyMMdd-HHmmss"
$BackupRoot = Join-Path $env:USERPROFILE "Desktop\codex-state-$Stamp"

robocopy $CodexState $BackupRoot /E /COPY:DAT /DCOPY:DAT /R:1 /W:1 /XJ
if ($LASTEXITCODE -ge 8) {
  throw "Codex state backup failed with robocopy exit code $LASTEXITCODE"
}

Microsoft documents robocopy exit codes 0 through 7 as non-failures and 8 or higher as at least one copy failure. Do not continue if the command throws.

Expected result: $BackupRoot contains a separate copy of the original .codex tree. Keep it unchanged. Perform every later inspection against the copy when possible.

Step 2: Check Whether the Transcripts Still Exist

Count rollout JSONL files in the preserved copy:

$SessionRoot = Join-Path $BackupRoot "sessions"
$Rollouts = Get-ChildItem $SessionRoot -Recurse -Filter "rollout-*.jsonl" -File -ErrorAction SilentlyContinue
$Rollouts.Count

$Rollouts |
  Sort-Object LastWriteTime -Descending |
  Select-Object -First 10 FullName,Length,LastWriteTime

List the copied state databases without opening or modifying them:

Get-ChildItem $BackupRoot -Filter "state_*.sqlite" -File |
  Select-Object FullName,Length,LastWriteTime

Interpret the result conservatively:

Do not conclude that SQLite can reconstruct a missing transcript. A database row can retain a thread title, path, and rollout reference without containing the missing conversation body.

Step 3: Try Non-Destructive Visibility Checks

When the JSONL files exist, reopen only one Codex surface and try these checks before changing any local state:

1. Use the app's Search instead of relying only on the project sidebar.

2. Open the same project through the exact path used before the update.

3. If you previously used WSL, compare the current project path with the path shown in preserved thread metadata or diagnostic output.

4. Check whether the same thread is visible in the Codex VS Code extension or another supported signed-in surface.

Several reports describe Windows or WSL project histories becoming invisible while the rollout files remained on disk. One report traced the symptom to a Windows-versus-WSL current-working-directory mismatch. That does not make hand-editing state_5.sqlite a supported repair. Preserve the evidence and wait for an official migration or recovery path.

Expected result: either a supported surface can open the old thread, or you have confirmed that the UI cannot reach a transcript that still exists in the backup.

Step 4: Audit the Repository Separately

Chat history and repository files are separate assets. From each affected repository, run read-only checks:

git status --short
git diff --name-status
git ls-files --deleted

git ls-files --deleted lists tracked files missing from the working tree. It cannot recover untracked files and does not prove what deleted a file.

Before restoring anything, copy each affected path that still contains work to a separate recovery folder. Then restore only a reviewed tracked path:

git restore --source=HEAD -- path/to/reviewed-file

Expected result: the exact tracked path matches HEAD, while unrelated local changes remain untouched. Never replace this targeted command with git reset --hard, git clean, or a broad git restore :/ during incident recovery.

If the missing work was committed, recover it from the relevant commit or remote branch. If it was untracked, Git has no copy; use File History, Previous Versions, OneDrive version history, or another backup.

Step 5: Recover Missing Files From a Backup

Microsoft recommends backing up current data before using Windows recovery tools. For individual missing files or folders, prefer File History or Previous Versions and restore into a different location first. Compare the restored copy with the preserved incident state before moving anything back.

Check these sources in order:

1. Windows File History or Previous Versions for %USERPROFILE%\.codex and the repository parent;

2. OneDrive or another cloud provider's version history, if the affected paths were synced;

3. an external disk, workstation backup, or enterprise endpoint backup;

4. the Recycle Bin, while recognizing that some removal paths do not send files there.

Avoid Reset this PC, app-data clearing, reinstalling Codex, or a whole-system restore as a first response. Those actions can replace more evidence and may not recreate absent JSONL payloads. If a system-level restore is the only remaining option, preserve the current disk state and follow your organization's recovery process first.

Step 6: Capture a Useful Incident Report

Record facts without publishing transcript content, credentials, or private project paths:

• Codex Desktop version from About and Codex CLI version;

• Windows version and whether the project uses WSL, OneDrive, junctions, or UNC paths;

• the approximate time of the update and the first observed loss;

• rollout JSONL count, newest surviving timestamp, and copied state database sizes;

• whether Search, VS Code, or another surface can open an old thread;

• git ls-files --deleted count for each affected repository;

• a Codex Feedback ID and a link to the matching GitHub issue.

Keep full diagnostics private unless OpenAI requests a secure upload. Session JSONL files can contain prompts, model output, command output, local paths, and other sensitive project data.

Common Recovery Mistakes

Why This Recovery Order Works

The first copy freezes the best available evidence before another process, reinstall, migration, or cleanup changes it. The file inventory then separates a presentation problem from missing payloads. Repository checks isolate source-code recovery from Codex session recovery, and targeted Git restore avoids overwriting unrelated work.

This follows the repeatable structure behind Aident's Ollama networking guide: use the exact symptom, run read-only diagnostics, provide reproducible commands with expected results, explain the failure boundary, and cover unsafe shortcuts. The topic is different, but the useful shape is the same.

Verify One Remote Integration With Aident Loadout

Losing a local Codex thread should not require copying provider credentials into a replacement prompt. After preserving the incident, use Aident Loadout from a trusted shell to verify that one remote integration remains available independently of the lost conversation.

Install or update it with this prompt:

Follow https://aident.ai/SETUP.md

Then run:

aident account auth status
aident vault vault --action status
aident capabilities search \
  --queries '["find one read-only Action for the integration I need to recover"]' \
  --types '["action"]'

Inspect the chosen Action with aident capabilities get --name "<canonical-action-name>" before execution. Success means the account is authenticated, the required integration is connected, and its current read-only Action schema is available without exposing a provider secret or depending on the missing thread. This does not restore Codex history; it verifies that remote access can be re-established safely in a fresh task.

Sources

• Rollout JSONL files deleted at app-server process transition, OpenAI Codex issue, opened July 27, 2026

• The tasks and chats in each project are deleted, OpenAI Codex issue, opened July 27, 2026

• Project chat history disappeared after latest Codex app update, OpenAI Codex issue, opened June 10, 2026

• Chat history disappeared from sidebar after app update, OpenAI Codex issue, opened June 3, 2026

• Codex Desktop history disappears after a Windows and WSL path mismatch, OpenAI Codex issue, opened May 24, 2026

• Anyone else seeing their Codex chats disappear from the GUI?, r/codex, posted May 23, 2026

• All chats gone, r/codex, posted July 19, 2026

• Robocopy command and exit codes, Microsoft Learn, accessed July 28, 2026

• Backup, restore, and recovery in Windows, Microsoft Support, accessed July 28, 2026

• Git restore documentation, Git, accessed July 28, 2026

• Aident setup instructions, accessed July 28, 2026

Refresh this guide when OpenAI ships an official Codex state backup, thread reindex, or recovery workflow, or documents a fix for the Windows session-loss reports.