Codex Desktop project chat histories disappeared after recent update

What version of the Codex App are you using (From “About Codex” dialog)?

26.429.30905 (2345)

What subscription do you have?

ChatGPT Pro

What platform is your computer?

macOS Tahoe 26.4.1
MacBook Pro 16-inch, Apple M5 Max, 128 GB memory

What issue are you seeing?

After what appears to be a recent Codex Desktop update today, almost all of my project chat histories disappeared from the sidebar.

The projects themselves are still listed, but most of them now show No chats. Only one main project still shows its previous conversation history. Before the update/restart, those other projects had existing conversation history.

This looks like a local history/indexing or migration issue rather than an intentional project deletion, because the project entries still exist while their associated conversations are missing from the UI.

Observed sidebar state from my screenshot:

GGame still shows recent conversations
CloudKitAdminPlatform shows No chats
RaspberryPi shows No chats
weighted-wheel shows No chats
WAN Project shows No chats
CodexAutoSwitcher shows No chats
regular Chats also shows No chats

This is high impact because those missing project conversations contain important development context and task history.

What steps can reproduce the bug?

I do not yet have a deterministic repro, but this is what happened:

Use Codex Desktop with multiple projects that already have chat history.
Receive/apply the recent Codex Desktop update, or reopen Codex after the update.
Open Codex Desktop again.
Check the left sidebar project list.
Observe that most projects are still present but their chat histories are gone / shown as No chats.
Only one main project still shows previous conversations.

What is the expected behavior?

All existing project conversations should remain visible and searchable after a Codex Desktop update or app restart.

Specifically:

Updating/restarting Codex should not hide or remove project chat histories.
Existing projects should continue to show their associated conversations.
If this is an indexing problem, there should be a safe way to re-index/recover the local project conversations.

Additional information

I have screenshots showing:

The sidebar state where only one project still has conversations while the other projects show No chats.
The Codex Desktop About dialog showing version 26.429.30905 (2345).
The macOS system information showing macOS Tahoe 26.4.1 and MacBook Pro Apple M5 Max.

Please investigate whether this is a UI/sidebar indexing bug, local migration issue, or possible data-loss problem. Also, please advise whether there is a safe recovery/re-indexing procedure for the missing project conversations.

Possibly related to prior local-thread/sidebar visibility issues, but this report is for Codex Desktop on macOS and affects project-level chat history after the latest update/restart.

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

Desktop project sidebar shows No chats after Symphony automation creates many threads #20187
macOS Desktop sidebar hides older local conversations despite existing thread state #20419
Chat History Deleted #20506
Windows Desktop: Sidebar shows No chats and no projects after update, but Search can still find/open existing chats #19290
Codex Windows app and VS Code extension memory usage climbs above 10GB after update #19381

Powered by Codex Action

Additional urgency note: please fix this as soon as possible. I currently cannot see the histories for my other Codex projects, so I cannot continue working in those projects with the required previous context. A safe recovery or re-indexing procedure would also help if the underlying data still exists locally.

This looks very similar to what I hit in #20493. In my case the chats were not actually deleted; they still existed on disk/in SQLite, but Codex Desktop stopped treating them as visible sidebar chats after the update/import path.

I documented the fuller recovery here: #20493 (comment)

Quick thing to check

Before changing anything, make a backup:

backup_dir="$HOME/.codex/chat-metadata-repair-$(date -u +%Y%m%dT%H%M%SZ)"
mkdir -p "$backup_dir"

sqlite3 "$HOME/.codex/state_5.sqlite" ".backup '$backup_dir/state_5.before.sqlite'"
cp "$HOME/.codex/.codex-global-state.json" "$backup_dir/codex-global-state.before.json"

Then check whether your hidden chats have the same broken metadata pattern:

sqlite3 "$HOME/.codex/state_5.sqlite" "pragma integrity_check;"

sqlite3 "$HOME/.codex/state_5.sqlite" \
  "select cwd, source, has_user_event, count(*)
   from threads
   where archived=0
     and first_user_message <> ''
     and (has_user_event=0 or source='exec')
   group by cwd, source, has_user_event
   order by count(*) desc, cwd;"

If that returns your missing project roots, this may be the same issue.

Repair that worked for me

This only touches active rows with a real first user message. It does not unarchive everything:

sqlite3 "$HOME/.codex/state_5.sqlite" "
begin immediate;

update threads
set has_user_event=1
where archived=0
  and first_user_message <> ''
  and has_user_event=0
  and source in ('vscode', 'cli', 'exec');

update threads
set source='vscode'
where archived=0
  and first_user_message <> ''
  and source='exec';

commit;

pragma wal_checkpoint(full);
pragma integrity_check;
"

After this, refresh/restart Codex Desktop. In my case a normal UI refresh was enough once the metadata was repaired.

If the chats exist but still appear under the wrong project, also inspect ~/.codex/.codex-global-state.json, especially:

thread-workspace-root-hints
project-order
electron-saved-workspace-roots

The short version: the data may still be there, but rows with first_user_message <> '' can end up with has_user_event=0 or source='exec', and then Desktop seems to hide them from the normal project sidebar.

@vishkrish200

@vishkrish200 Thank you very much. I will try this.

That said, I still think the Codex team should treat this as a real bug and fix it seriously. Users should not have to manually repair local SQLite metadata just to recover visible project chat history after an update.

Faced the same. Not available in app sidebar, but visible in cli.
Resumed chat with cli -> sent a message -> chat reappeared in app sidebar.

macOS 15

I’m seeing what appears to be the same issue on Windows with WSL projects after a recent Codex Desktop update.

Environment:

Codex Desktop on Windows
Project is inside WSL:
/home/user1234/projects/Servicenowreports
Same project is also accessible from Windows as:
\wsl.localhost\Ubuntu\home\user1234\projects\Servicenowreports
Observed behavior:

The project still appears in the Codex Desktop project/sidebar UI.
The old project chats do not appear under the project chat list.
Switching/opening the project via the alternate WSL/UNC path did not restore the old project chat list.
However, in-app Search still finds the old chat title.
Clicking the old chat from Search opens the thread successfully, and the assistant can respond in that old thread.
Even after sending a new message in that old thread, it still does not reappear in the project chat list/sidebar.
Local data observations:

The old thread still exists in the local Codex database.
In C:\Users\user.userlastname.codex\state_5.sqlite, the threads table contains the old thread.
The thread is not archived (archived = 0).
The old thread has this cwd:
?\UNC\wsl.localhost\Ubuntu\home\user1234\projects\Servicenowreports
The rollout/session file still exists at:
C:\Users\user.userlastname.codex\sessions\2026\04\28\rollout-2026-04-28T23-56-20-019dd617-da60-76a2-a36f-d5ab72d3bc05.jsonl
The thread title is:
Planera ServiceNow-rapportimport
This suggests the chat data itself is still present and loadable, but the project chat list/sidebar no longer associates existing threads with the project correctly. It looks more like a project/thread indexing or path normalization regression than actual data loss.

One possible contributing factor is WSL path identity/normalization. The current workspace may appear as:
/home/user1234/projects/Servicenowreports
while older stored threads use:
?\UNC\wsl.localhost\Ubuntu\home\user1234\projects\Servicenowreports

But opening the project through the alternate path did not fix the project chat list.

Additional observation: the project files also no longer appear correctly in the Codex Desktop UI, even though they still exist in WSL and the agent can read them from /home/user1234/projects/Servicenowreports. In one resumed thread, the cwd appeared malformed, combining the Windows app resources path with the WSL UNC path:
/mnt/c/Program Files/WindowsApps/OpenAI.Codex_.../app/resources/\wsl.localhost\Ubuntu\home\user1234\projects\Servicenowreports

This suggests the issue may affect project root/path resolution, not only chat history listing.

I hit the same issue on Codex Desktop macOS.

In my case the chats were not deleted. The original thread rows still existed in:

~/.codex/state_5.sqlite
~/.codex/session_index.jsonl
~/.codex/sessions/.../rollout-*.jsonl

For the affected project, the rows had:

archived = 0
source = 'vscode'
correct cwd
populated first_user_message

I first tried the metadata repair suggested above:

update threads
set has_user_event = 1
where archived = 0
  and first_user_message <> ''
  and cwd = '<PROJECT_ROOT>';

That updated the rows correctly and pragma integrity_check; returned ok, but Codex Desktop still did not show the chats after reload/restart.

The workaround that actually made one hidden chat reappear was cloning it to a new thread identity:

Generate a new Codex-style UUIDv7 thread id.
Copy the original rollout file to a new rollout path.
Change the first session_meta.payload.id in the copied rollout JSONL to the new id.
Insert a new threads row with the new id, same cwd, source='vscode', archived=0, has_user_event=1, and the new rollout path.
Append a matching entry to session_index.jsonl.

After that, the recovered chat appeared in the project sidebar.

So this seems to be more than just has_user_event=0. At least in my case, once a thread was hidden, fixing metadata alone was not enough. Desktop seemed to keep ignoring the old thread identity, while a cloned thread with a fresh id/index entry was picked up.

I found a workaround that avoids rewriting chat metadata or touching timestamps. Since it modifies/fixes the codex desktop app code, it can't modify the actual installed version due to signing, but it can run separately as its own electron app; I just put a shortcut to it on my desktop until OpenAI gets into gear and fixes this.

In my case, exec chats being hidden seems correct. The actual Desktop bug was that the sidebar’s recent chat refresh only loaded the first page, while the app-server had more non-exec chats available. Patching the renderer to fetch all thread/list pages made my old projectless/non-project chats reappear.

I verified:

no exec chats were shown
no chat timestamps were changed
no source='exec' rows were changed to vscode
rendered sidebar rows matched the active non-exec projectless rows in SQLite/global state

Prompt I used/that others can adapt:

Investigate missing Codex Desktop chats without changing chat timestamps or converting exec chats to vscode.

Goal:
Make every active, non-empty, non-exec interactive chat visible in Codex Desktop, especially old projectless/non-project chats.

Rules:
- Back up ~/.codex/state_5.sqlite and ~/.codex/.codex-global-state.json first.
- Do not change source='exec' rows to source='vscode'.
- Do not use timestamp touching as the primary fix.
- Treat exec chats as intentionally hidden unless proven otherwise.
- Prefer a renderer/sidebar paging fix over SQLite metadata hacks.
- Verify by comparing rendered sidebar thread IDs against SQLite/global-state expected non-exec chats.

What to look for:
In the installed Desktop app bundle, find the renderer asset that owns recent conversations, usually a hashed file like:

  app-server-manager-signals-*.js

Look for logic similar to:

  runRecentConversationRefresh(...)
  listRecentThreads({ limit: 50 * this.recentConversationPageCount, cursor: null })

There may already be a helper that recursively loads all thread/list pages, often similar to:

  listAllThreads(...)
  thread/list with cursor recursion

Patch the initial recent conversation refresh to use the all-pages helper instead of only the first page. For example, conceptually:

  let t = {
    data: await this.listAllThreads({ modelProviders: null, archived: false }),
    nextCursor: null
  };

Then keep the existing cache/upsert/notify logic unchanged.

Important:
The app-server already defaults empty sourceKinds to interactive sources, which excludes exec. Do not “fix” visibility by rewriting exec rows.

Windows notes:
- Directly replacing the installed WindowsApps app.asar may fail because WindowsApps is TrustedInstaller-protected.
- A signed copied Codex.exe may reject a modified app.asar because Electron asar integrity can fail.
- A viable non-admin workaround is:
  1. Extract app.asar to a writable folder.
  2. Patch the extracted renderer asset.
  3. Run it with generic Electron, e.g. electron@matching-version.
  4. Set env vars so it uses the normal Codex local state/runtime:
     - BUILD_FLAVOR=prod
     - NODE_ENV=production
     - ELECTRON_RENDERER_URL=file:///.../app-asar/webview/index.html
     - CODEX_CLI_PATH=%LOCALAPPDATA%\OpenAI\Codex\bin\codex.exe
     - CODEX_BROWSER_USE_NODE_PATH=%LOCALAPPDATA%\OpenAI\Codex\bin\node.exe
     - CODEX_NODE_REPL_PATH=%LOCALAPPDATA%\OpenAI\Codex\bin\node_repl.exe
     - CODEX_ELECTRON_RESOURCES_PATH=path to copied/existing resources

Verification:
Use Chrome DevTools remote debugging or DOM inspection to extract sidebar thread IDs, then compare with:

  select id
  from threads
  where archived = 0
    and first_user_message <> ''
    and source <> 'exec'
  order by updated_at desc;

Also account for projectless-thread-ids and thread-workspace-root-hints in ~/.codex/.codex-global-state.json.

Expected result:
Old non-exec chats appear in the sidebar without changing their timestamps or source metadata.

For repeated use, put the patched launch command behind a small script and create a desktop shortcut to that script. The shortcut is easier than retyping the env vars each time, and it avoids accidentally launching the unpatched official Desktop app.

On Windows, the shortcut can point to PowerShell, for example:

powershell.exe -NoProfile -ExecutionPolicy Bypass -File "C:\Path\To\Start-PatchedCodexDesktop.ps1"

The script should set the required environment variables, then run:

npx --yes electron@<matching-electron-version> "C:\Path\To\extracted\app-asar"

Admin is not required for this generic-Electron launcher unless your own environment has unusual permissions. If the script works once from a normal terminal, the shortcut should work the same way.

Same symptom on Windows — root cause appears to be `\\?\` extended-length path prefix in `threads.cwd`

Hit this on Windows 11 (10.0.26200) with Codex Desktop 26.513.31313 (MSIX OpenAI.Codex_2p2nqsd0c76g0). Same sidebar-empty behavior as the OP, plus: clicking any affected thread produces "Oops, an error has occurred," and after one such click no further threads will load in that session (including clean ones). Restarting Codex Desktop fixes loading temporarily, until the next affected thread is clicked.

No chats are actually deleted. Both the pre-recovery auto-backup and the current DB have the same 11,133 thread IDs.

Root cause

Every affected thread has its cwd stored with the Windows extended-length prefix \\?\:

\?\C:\Users<me>\Desktop\Projects_Betting_Markets\Polymarket_Wallets

while the matching entry in .codex-global-state.json → electron-saved-workspace-roots is the same path without the prefix. The project↔thread matcher (and apparently the thread loader) compares these literally and doesn't normalize the prefix, which sets off a cascade:

Affected threads look "projectless" → triggers projectless_recovery.
Recovery clears active-workspace-roots instead of normalizing the orphan cwds. (Auto-backup .codex-global-state.before_projectless_recovery.<ts>.json confirms this — the only diff vs. the current file is active-workspace-roots: ["C:\\…\\Polymarket_Wallets"] → [].)
Sidebar then renders "No chats" because no active project is set.
Clicking any affected thread throws in the loader and poisons renderer state → all subsequent loads fail for the session.

Who's writing the prefix

In state_5.sqlite, the bad rows uniformly have:

originator: "Codex Desktop"
source: "vscode"
cli_version: 0.118.0-alpha.2 … 0.131.0-alpha.9 (every alpha shipped with Desktop over the last ~5 weeks)

Threads created by codex exec as a subprocess have source: "exec" and never have the \\?\ prefix. So it isn't the CLI in general — it's specifically the Codex Desktop spawn path calling something equivalent to Rust's std::fs::canonicalize() on Windows (which returns \\?\-prefixed paths) and persisting the result.

Counts on my machine: of 11,133 threads, 150 had \\?\ cwd. Concentrated in the projects I use most. My Polymarket_Wallets project: 96 affected vs. 55 clean (64% affected).

Data-level fix does not stick

Tried a sanity normalization:

UPDATE threads SET cwd = SUBSTR(cwd, 5) WHERE substr(cwd, 1, 4) = '\?';
-- 150 rows updated

Confirmed 0 prefixed rows immediately after. Restarted Codex Desktop → 120 rows re-acquired the prefix within ~1 minute, including the specific row I was trying to click. So Codex Desktop is re-canonicalizing the cwd at load/access time and writing it back. Whatever path does that is the right one to patch — strip \\?\ before reading from or writing to the DB (e.g. dunce::simplified() in Rust, or any equivalent prefix-strip elsewhere).

What "history repair" / "projectless recovery" actually do

The two auto-backups Codex created during the update:

| File | Effect |

|---|---|

| state_5.before_history_repair.<ts>.sqlite | ~0.2 MB SQLite page churn vs. current. No rows deleted, identical thread-ID set. |

| .codex-global-state.before_projectless_recovery.<ts>.json | Only active-workspace-roots changed (project → empty). Nothing else. |

So both recovery passes are essentially no-ops w.r.t. the orphan problem — they just clear the active project, which makes it look like data loss to the user but doesn't relocate or repair anything.

Possibly the actual throw site of the loader crash

Sentry breadcrumbs from the crashing session (event itself was flushed before I could read it locally) — last electron.net entries are all chatgpt.com/backend-api/aip/connectors/asdk_app_*/logo GETs, with one 404:

GET .../aip/connectors/asdk_app_69e92b0ca8708191a9c3259e162d8e2d/logo?theme=light → 404 [warning]

If thread display tries to render AIP connector metadata and the 404 on /logo is unhandled in some code path, that may be where the loader actually throws. Worth checking the renderer's tolerance for 404 on connector-logo fetches.

Suggested fix points

Strip the \\?\ prefix before persisting threads.cwd (canonicalize for comparison on a local variable, don't store the canonical form).
Normalize paths in the project↔thread matcher so \\?\C:\X matches C:\X (case-insensitive on Windows).
Wrap the thread loader's path resolution in try/catch and surface errors locally — right now one bad click takes out loading for the entire session, which feels like a separate hardening bug from the path issue.
projectless_recovery should attempt path normalization on orphan cwds instead of clearing active-workspace-roots. Clearing the active project hides the symptom but doesn't repair anything.

Environment

OS: Windows 11 10.0.26200
Codex Desktop: 26.513.31313 (MSIX OpenAI.Codex_2p2nqsd0c76g0)
Electron 42.0.1, Node 24.15.0, Chrome 148.0.7778.97
Affected thread cli_version range: 0.118.0-alpha.2 → 0.131.0-alpha.9
The 96-affected project is on a local NTFS volume, path under 260 chars (so no actual need for extended-length syntax).

Happy to share the auto-backup state files, specific row dumps, or the rollout JSONL for an affected thread if useful — the data on my machine is intact, just not loadable through the Desktop UI.

I’m seeing the same issue on macOS Codex Desktop.

A project that used to have many chats now shows “No chats” in the sidebar.

I did not archive the chats, and archived chats do not contain them.

Severity update from the same affected Windows install on OpenAI.Codex_26.611.8604.0_x64__2p2nqsd0c76g0:

The behavior is now worse than previous reports.
Clicking/opening one conversation can cause the project/sidebar conversation list to disappear entirely.
This is not limited to old migrated conversations; project/sidebar visibility remains unstable during normal navigation.
Pinning still appears to be the only workaround that keeps a conversation reachable, but the normal project conversation list is not reliable.

This is a high-impact regression for multi-project users because normal navigation can hide the visible working set immediately.