Codex Desktop project chat histories disappeared after recent update

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

• #20187
• #20419
• #20506
• #19290
• #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: https://github.com/openai/codex/issues/20493#issuecomment-4359541878

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

1. Generate a new Codex-style UUIDv7 thread id.
2. Copy the original rollout file to a new rollout path.
3. Change the first session_meta.payload.id in the copied rollout JSONL to the new id.
4. Insert a new threads row with the new id, same cwd, source='vscode', archived=0, has_user_event=1, and the new rollout path.
5. 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:

1. Affected threads look "projectless" → triggers projectless_recovery.

1. 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"] → [].)

1. Sidebar then renders "No chats" because no active project is set.

1. 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

1. Strip the \\?\ prefix before persisting threads.cwd (canonicalize for comparison on a local variable, don't store the canonical form).

1. Normalize paths in the project↔thread matcher so \\?\C:\X matches C:\X (case-insensitive on Windows).

1. 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.

1. 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.

Experiencing this bug on Windows 11. The logs are still there in C:\Users\...\.codex\state_5.sqlite, session_index.jsonl but do not appear in the codex desktop app.

Broken for the second time? Missing again. MacOS.

I am facing the same issue on macOS, chat names are visible but the content itself is not, on the bright side I can view the chats in codex CLI.

<img width="1453" height="840" alt="Image" src="https://github.com/user-attachments/assets/0fccd76f-cbb1-4442-abc8-9176980860fd" />

Also experiencing this on MacOS. This work around fixes it for me but it would nice to have better configuration around the number of previous threads that are populated vs being locked into the 50 most recent..

this has been around 3 weeks or more! How have they not fixed it?
Happening to me on about a 3rd of my older chats

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

how do you do this? sounds like a simple way to get it working again
EDIT lol nevermind I just pointed Codex to this bug and it gave me the terminal command to continue the chat: ie
/Applications/Codex.app/Contents/Resources/codex resume 019d695d-b51f-7a12-91bf-57cb30v0fd1c

Still reproducible on Codex Desktop 26.519.31651 (3017) with macOS Tahoe 26.5 on a MacBook Pro 16-inch, Apple M5 Max, 128 GB memory.

The left sidebar chat history can still disappear after some time. Once it disappears, I cannot directly recover those chats in the Codex app. Updating to this latest version did not restore the chat histories that disappeared in earlier versions.

This blocks normal project work because those conversations contain important project context. My current assumption is that the conversations are still stored locally, but the app is failing to index, associate, or display them in the sidebar.

Please investigate this as a priority and provide an official recovery/re-indexing path for previously hidden chats.

I tried codex CLI, and I can resume all my chat history. It's a good solution before openai fix this bug

郝临峰
@.***

签名由 网易灵犀办公 定制

Original:
From：GGBondBlueWhale @.>Date：2026-05-22 12:03:39(中国 (GMT+08:00))To：openai/codex @.>Cc：csdiyfree @.> , Comment @.>Subject：Re: [openai/codex] Codex Desktop project chat histories disappeared after recent update (Issue #20741)GGBondBlueWhale left a comment (openai/codex#20741)
Still reproducible on Codex Desktop 26.519.31651 (3017) with macOS Tahoe 26.5 on a MacBook Pro 16-inch, Apple M5 Max, 128 GB memory.
The left sidebar chat history can still disappear after some time. Once it disappears, I cannot directly recover those chats in the Codex app. Updating to this latest version did not restore the chat histories that disappeared in earlier versions.
This blocks normal project work because those conversations contain important project context. My current assumption is that the conversations are still stored locally, but the app is failing to index, associate, or display them in the sidebar.
Please investigate this as a priority and provide an official recovery/re-indexing path for previously hidden chats.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you commented.Message ID: @.***>

This was a blocking issue for me. This /goal prompt given to 5.5 will create a database browser of your entire chat history. It recovered 5,000+ of my sessions. Adjust to your liking or better, just let it rip
(edit: added cloned database architecture for backup so you own your chats)

/goal Build a durable local read-only browser/search tool for all available Codex chat/session history: find the local Codex session database/files, create and maintain a separate cloned/indexed archive database as backup, only read Codex data to import new or changed entries, provide a simple searchable UI over the archive, support safe auto-update on each run or via a local watcher/job, never modify Codex app data, and report the command/URL plus total sessions archived.

this is annoying as f

修复了吗，老是丢 chat记录啊

What is going on with OpenAI that they haven't fixed this?It's so annoying and it's such a glaring bug.

I ran into a similar issue after a Codex Desktop update: project entries were still present, but older project chats disappeared from the sidebar even though local session data still existed.

I collected my local recovery workflow here:

https://github.com/huajiexiewenfeng/codex-session-recovery

It is an unofficial workaround, not an upstream fix. The workflow starts with a dry-run, checks sessions/**/*.jsonl, session_index.jsonl, .codex-global-state.json, SQLite threads.cwd, project/sidebar mappings, and exact cwd matching risks, then creates timestamped backups before writing and verifies the result afterward.

This may help users whose local data is still present but hidden due to stale/missing local index or project mapping state after an update.

Please fix

@huajiexiewenfeng I'm unclear on what your workaround recovery does - does it bring all of the chats back to the sidebar?

Disgustingly still a problem in 26.601.21317 - only the 50 most recent threads are shown. Again I had to rebuild my own version of the app to get around the signing problem. Here's a prompt to get your codex to build a fixed version in windows:

Fix my local Codex Desktop sidebar so it shows all non-exec chats again, without touching chat metadata, JSONL mtimes, or SQLite rows.

Context:
- This is the Codex Desktop “missing chats/sidebar cutoff” bug.
- Do not use workaround hacks like changing `source`, `has_user_event`, project ids, or file mtimes.
- The intended app-code fix is to remove the capped recent-chat sidebar fetch and use the app’s existing all-thread listing path instead.

Requirements:
1. Discover the installed Codex Desktop version and app path dynamically. Do not hard-code package ids or version numbers.
2. Build a side-by-side patched app under a user-local directory such as:
   `%LOCALAPPDATA%\OpenAI\CodexPatchedDesktop\<version>\...`
   Do not modify the original Store/app install unless explicitly necessary and safe.
3. Patch the renderer bundle by searching for the recent sidebar refresh code, not by assuming exact filenames. Look for terms like:
   `runRecentConversationRefresh`
   `listRecentThreads`
   `recentConversationPageCount`
   `limit:50`
   `cursor:null`
4. Replace the capped recent-chat fetch with the app’s existing all-thread path. The resulting request should be equivalent to:
   `thread/list` with `archived:false`, `cursor:null`, `limit:null`, and `sortKey:"updated_at"`.
   Preserve existing backend/source filtering. Do not make exec chats visible by metadata hacking.
5. Keep the patched app using the real production database, `codex.db`. Do not switch to a copied database unless there is no other viable option.
6. If packaging on Windows, do not rely on copying the Store/Owl `Codex.exe` launcher directly, because it may reactivate the installed Store package instead of the patched local app. Build/package a local Electron app and verify its process path is under the patched local directory.
7. Handle Windows packaging/native dependency failures explicitly.

   First, do not trust `require("better-sqlite3")` alone as a test. The native binding is loaded lazily. Smoke-test with:
   - require the module
   - construct `new Database(":memory:")`
   - run a simple `create table / insert / select`

   Expected failure modes and fixes:
   A. `The specified module could not be found ... better_sqlite3.node`
      - Inspect PE imports for `better_sqlite3.node`.
      - If it imports `chrome.dll`, ensure the app root contains `chrome.dll`.
      - Inspect `chrome.dll` imports too; if it imports `chrome_elf.dll`, copy/include `chrome_elf.dll`.
      - Retest by constructing an in-memory database.

   B. `Module did not self-register`
      - This means the native module ABI does not match the Electron runtime.
      - Do not keep copying random DLLs at this point.
      - Rebuild `better-sqlite3` for the packaged Electron version.

   C. In-place rebuild fails with `deps/common.gypi not found`
      - The packaged app’s `better-sqlite3` may be stripped of source/deps.
      - Create a temporary build directory with no spaces in the path.
      - `npm install better-sqlite3@<same version as packaged app> --ignore-scripts`
      - Run `@electron/rebuild` against the target Electron version.
      - Copy only the rebuilt `better_sqlite3.node` into the patched app.

   D. Electron 42 / V8 header build failures on Windows
      If the rebuild fails with V8 API errors, patch the temporary `better-sqlite3` source minimally:
      - define `__builtin_frame_address` for MSVC using `_AddressOfReturnAddress()`
      - pass `v8::kExternalPointerTypeTagDefault` to `v8::External::New(...)`
      - pass `v8::kExternalPointerTypeTagDefault` to `External::Value(...)`
      - use `nullptr` instead of `0` in the `SetNativeDataProperty(...)` call
      Then rebuild again.

   Keep a backup of the original `better_sqlite3.node` before replacing it.
8. Add a launcher script that sets production environment variables, including:
   `BUILD_FLAVOR=prod`
   `NODE_ENV=production`
   `CODEX_SPARKLE_ENABLED=false`
   a patched-app-specific `CODEX_ELECTRON_USER_DATA_PATH`
9. Create a desktop shortcut to the launcher. A non-admin shortcut is preferred if it works; optionally create an “admin” shortcut too.
10. Actually launch the patched app yourself. Do not stop after building.
11. Verify all of this before finishing:
   - patched app process path is local, not the original Store/app path
   - SQLite opens successfully
   - app uses `codex.db`, not a copied DB
   - sidebar patch is present and the old `limit:50 * recentConversationPageCount` fetch is gone
   - after scrolling the sidebar, chats older than the previous cutoff are visible
   - capture a screenshot of the patched window after scrolling

Be careful not to kill the Codex instance that is running this task. If closing the official app is needed because of a database lock, ask first.

same error

I wonder if they want this to be the behavior, for some reason.

Hi everyone, I'm tracking the same Codex Desktop missing-thread/sidebar-history issue on macOS.

For those affected here: did you eventually get all hidden project threads back in Desktop? If yes, what exact method worked durably for you?

Examples I'm trying to distinguish:

• official update fixed it
• restart/reindex fixed it
• codex resume --all <thread-id> rehydrated it
• repairing session_index.jsonl / state_5.sqlite / .codex-global-state.json fixed it
• Codex Wake or another local recovery helper fixed it
• app bundle / listAllThreads patch fixed it
• nothing worked yet

In my case, the missing project threads still exist in ~/.codex/sessions and state_5.sqlite, but Desktop does not hydrate them back into the project sidebar after restart. Any confirmed durable fix would help. Please do not share private session contents; sanitized method/results are enough.

what's worked for me: go to the project folder, open codex in that context, /resume, type something in the thread. It will then reappear in your codex desktop.

what's worked for me: go to the project folder, open codex in that context, /resume, type something in the thread. It will then reappear in your codex desktop.

Thanks for the suggestion — I’ll try this workaround.

@etraut-openai Just adding visibility here: this really shouldn’t be something users have to manually discover and fix. This is something the Codex app/team should resolve properly. On the latest version I’m using, 26.602.71036, the previously disappeared project chat histories still have not been restored, and more sessions are still continuing to disappear.

A workaround is helpful, but this needs an official recovery/migration/reindex fix.

There's a lot going on here, but sharing my experience and expectations:

I started a side chat and ran through a couple of turns, and then I noticed that there was a Codex update, which I ran.

When I came back, I couldn't open the same side chat again; it only opened the main chat, and I expected it would reopen in the same state as I closed it with both chats open.

What was worse was that I was not able to find the side chat in the workspace as a recent chat, even in the left panel. I would expect it to both stay open after an app reload/restart and be visible as a recent chat in the left side panel, so I am always able to continue that side chat, because as is, it feels too much like a throwaway chat which was not explained to me anywhere when starting the chat.

This chat had good information and was half done. That's not what I expected from a side chat.

Searching for specific keywords that was inside that chat returned no results.

Adding a macOS datapoint after updating to the latest Desktop build.

Environment:

• macOS 15.5 (24F74)
• Apple Silicon / arm64
• Codex Desktop: 26.608.12217
• CFBundleVersion: 3722
• Local storage: default ~/.codex

Recovery status on my affected project:

• The update appears to have restored some previously missing threads.
• It did not restore everything.
• Older project threads are still missing from the Desktop sidebar/project history.
• The local data still appears to exist. For the affected project, state_5.sqlite still has 251 active/non-archived rows with the expected project cwd.
• Earlier checks also confirmed matching rollout JSONL/session files under ~/.codex/sessions.

So my current result is: 26.608.12217 looks like a partial recovery, not a full recovery. It would still be very helpful to have an official full local reindex/recovery command that rebuilds sidebar/project history from durable local state.

I’m seeing the same class of issue on Windows Codex Desktop.

Environment:

• Codex Desktop: 26.608.1337.0
• OS: Windows
• Local state location: C:\Users\Coco\.codex

Observed behavior:

• After upgrade/restart, project conversations disappear from the sidebar or projects show no/partial chat history.
• Re-adding project folders can temporarily restore the project list, but conversations disappear again after navigation/restart.
• The underlying local data is still present: state_5.sqlite, session_index.jsonl, and sessions/ still contain the historical threads.
• Manual repair attempts against .codex-global-state.json and state_5.sqlite do not persist reliably; the app rewrites sidebar/project/index state on launch/navigation.

Local evidence:

• state_5.sqlite still contains the thread records and first user messages.
• sessions/ still contains rollout JSONL files.
• The issue appears to be sidebar/index/project mapping rather than deleted conversations.

Impact:

• High impact for multi-project users because project-local history becomes inaccessible from the UI even though the data still exists locally.

Requested fix:

• A safe local reindex/rebuild command for project/thread sidebar state, or an app-side migration fix that rebuilds visible project conversation lists from state_5.sqlite / sessions/ without losing existing history.

I hit something very similar and made a python script that helped me recover the missing chats locally on my mac:

https://github.com/gifgiif/codex-chat-metadata-repair

In my case the chats were not actually deleted. The session data was still there in .codex/sessions/, and the thread records were still in .codex/state_5.sqlite, but some Codex metadata/index fields were empty or missing, so the chats stopped showing up in the sidebar.

The script only tries to repair local metadata/index state, mostly around:

• .codex/state_5.sqlite
• .codex/session_index.jsonl
• .codex/sessions/**/*.jsonl

Just to be clear: this is not an official fix and probably won’t solve cases where Codex keeps rewriting/breaking the project index after every restart. But if your local session JSONL files and SQLite records are still there and the sidebar just lost track of them, it may help.

This seems like it might be fixed now...mac desktop app 26.609.30741 now seems to be showing many sessions that had been missing up until recently for me...I'd be curious if other folks are seeing the same..

This seems like it might be fixed now...mac desktop app 26.609.30741 now seems to be showing many sessions that had been missing up until recently for me...I'd be curious if other folks are seeing the same..

I don't think it's fixed for me. I'm still unable to find the actual side chat that I started in the sidebar. So it might be fixed moving forward, and I haven't had the time to test that yet, but it's not fixed in any backwards‑compatible way.

Update from the same affected Windows install:

• Codex Desktop was upgraded this morning and the issue still reproduces.
• Current running package path shows: OpenAI.Codex_26.609.3341.0_x64__2p2nqsd0c76g0\app\Codex.exe.
• Project conversations still appear and then disappear again during navigation, including newly created conversations.
• Local data still appears present under .codex; the failure looks like project/sidebar indexing or visibility state, not deleted session data.
• A newly created disappearing thread was observed with has_user_event=0 in state_5.sqlite; setting visibility metadata helped surface some rows but did not provide a durable fix because the app/sidebar state still becomes inconsistent.
• Pinning a conversation appears to keep it visible. It may move/use visibility outside the normal project grouping, but it is currently the only reliable workaround found on this install.
• Recreating projects from existing folders did not solve it: conversations still disappear after navigation.

Request: please provide an official recovery/reindex command or migration fix for existing local session data on Windows. The current 26.609.3341.0 upgrade did not repair this installation.

Additional Windows update from the same affected install:

• Codex Desktop was upgraded again and the issue still reproduces.
• Current installed/running package is now: OpenAI.Codex_26.609.4994.0_x64__2p2nqsd0c76g0.
• Running executable path observed: C:\Program Files\WindowsApps\OpenAI.Codex_26.609.4994.0_x64__2p2nqsd0c76g0\app\Codex.exe.
• Project conversations still disappear after navigation, including newly created conversations.
• Previous workaround still appears to be pinning conversations; unpinned project/sidebar visibility remains unstable.
• This confirms that the issue was not resolved for this Windows install by upgrading from 26.609.3341.0 to 26.609.4994.0.

Still requesting an official Windows-safe recovery/reindex command or migration fix that rebuilds project/sidebar conversation visibility from existing local .codex data.

Additional Windows update from the same affected install:

• Codex Desktop was upgraded again and the issue still reproduces.
• Current installed/running package is now: OpenAI.Codex_26.609.9530.0_x64__2p2nqsd0c76g0.
• Running executable path observed: C:\Program Files\WindowsApps\OpenAI.Codex_26.609.9530.0_x64__2p2nqsd0c76g0\app\Codex.exe.
• Project/sidebar conversation visibility is still unstable after navigation.
• Existing and newly created conversations can still disappear from project history unless pinned.
• This confirms the issue was not resolved for this Windows install by upgrading from 26.609.4994.0 to 26.609.9530.0.

Still requesting an official Windows-safe recovery/reindex command or migration fix that rebuilds project/sidebar conversation visibility from existing local .codex data.

Additional Windows update from the same affected install:

• Codex Desktop was upgraded again and the issue still reproduces.
• Current installed/running package is now: OpenAI.Codex_26.611.8273.0_x64__2p2nqsd0c76g0.
• Running executable path observed: C:\Program Files\WindowsApps\OpenAI.Codex_26.611.8273.0_x64__2p2nqsd0c76g0\app\Codex.exe.
• Product/FileVersion observed: 149.0.7827.115.
• Project/sidebar conversation visibility is still unstable after navigation.
• Existing and newly created conversations can still disappear from project history unless pinned.
• This confirms the issue was not resolved for this Windows install by upgrading from 26.609.9530.0 to 26.611.8273.0.

Still requesting an official Windows-safe recovery/reindex command or migration fix that rebuilds project/sidebar conversation visibility from existing local .codex data.

Additional Windows update from the same affected install:

• Codex Desktop was upgraded again and the issue still reproduces.
• Current installed/running package is now: OpenAI.Codex_26.611.8604.0_x64__2p2nqsd0c76g0.
• Running executable path observed: C:\Program Files\WindowsApps\OpenAI.Codex_26.611.8604.0_x64__2p2nqsd0c76g0\app\Codex.exe.
• Product/FileVersion observed: 149.0.7827.115.
• Project/sidebar conversation visibility is still unstable after navigation.
• Existing and newly created conversations can still disappear from project history unless pinned.
• This confirms the issue was not resolved for this Windows install by upgrading from 26.611.8273.0 to 26.611.8604.0.

Still requesting an official Windows-safe recovery/reindex command or migration fix that rebuilds project/sidebar conversation visibility from existing local .codex data.

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.

Additional Windows update from the same affected install:

• Codex Desktop was upgraded again and the issue still reproduces.
• Current installed/running stable package is now: OpenAI.Codex_26.616.3767.0_x64__2p2nqsd0c76g0.
• Running executable path observed: C:\Program Files\WindowsApps\OpenAI.Codex_26.616.3767.0_x64__2p2nqsd0c76g0\app\Codex.exe.
• Product/FileVersion observed: 149.0.7827.115.
• Regression behavior remains severe: clicking/opening one conversation can cause all project/sidebar conversations to disappear.
• Existing and newly created conversations can still disappear from project history unless pinned.
• This confirms the issue was not resolved for this Windows install by upgrading from 26.611.8604.0 to 26.616.3767.0.

Still requesting an official Windows-safe recovery/reindex command or migration fix that rebuilds project/sidebar conversation visibility from existing local .codex data.

Additional Windows update from the same affected install:

• Codex Desktop was upgraded again and the issue still reproduces.
• Current installed/running stable package is now: OpenAI.Codex_26.616.5445.0_x64__2p2nqsd0c76g0.
• Running executable path observed: C:\Program Files\WindowsApps\OpenAI.Codex_26.616.5445.0_x64__2p2nqsd0c76g0\app\Codex.exe.
• Product/FileVersion observed: 149.0.7827.115.
• Regression behavior remains: clicking/opening one conversation can cause project/sidebar conversations to disappear.
• Existing and newly created conversations can still disappear from project history unless pinned.
• This confirms the issue was not resolved for this Windows install by upgrading from 26.616.3767.0 to 26.616.5445.0.

Still requesting an official Windows-safe recovery/reindex command or migration fix that rebuilds project/sidebar conversation visibility from existing local .codex data.

Additional Windows update from the same affected install:

• Codex Desktop was upgraded again and the issue still reproduces.
• Current installed/running stable package is now: OpenAI.Codex_26.616.6631.0_x64__2p2nqsd0c76g0.
• Running executable path observed: C:\Program Files\WindowsApps\OpenAI.Codex_26.616.6631.0_x64__2p2nqsd0c76g0\app\Codex.exe.
• Product/FileVersion observed: 149.0.7827.115.
• Regression behavior remains: clicking/opening one conversation can cause project/sidebar conversations to disappear.
• Existing and newly created conversations can still disappear from project history unless pinned.
• This confirms the issue was not resolved for this Windows install by upgrading from 26.616.5445.0 to 26.616.6631.0.

Still requesting an official Windows-safe recovery/reindex command or migration fix that rebuilds project/sidebar conversation visibility from existing local .codex data.

Additional Windows update from the same affected install:

• Codex Desktop was upgraded again and the issue still reproduces.
• Current installed/running stable package is now: OpenAI.Codex_26.616.9593.0_x64__2p2nqsd0c76g0.
• Running executable path observed: C:\Program Files\WindowsApps\OpenAI.Codex_26.616.9593.0_x64__2p2nqsd0c76g0\app\Codex.exe.
• Product/FileVersion observed: 149.0.7827.115.
• Regression behavior remains: clicking/opening one conversation can cause project/sidebar conversations to disappear.
• Existing and newly created conversations can still disappear from project history unless pinned.
• This confirms the issue was not resolved for this Windows install by upgrading from 26.616.6631.0 to 26.616.9593.0.

Still requesting an official Windows-safe recovery/reindex command or migration fix that rebuilds project/sidebar conversation visibility from existing local .codex data.

Additional Windows update from the same affected install:

• Codex Desktop was upgraded again and the issue still reproduces.
• Current installed/running stable package is now: OpenAI.Codex_26.616.10790.0_x64__2p2nqsd0c76g0.
• Running executable path observed: C:\Program Files\WindowsApps\OpenAI.Codex_26.616.10790.0_x64__2p2nqsd0c76g0\app\Codex.exe.
• Product/FileVersion observed: 149.0.7827.115.
• Current observed state is worse: conversations have disappeared entirely from the project/sidebar view.
• Previous regression behavior also remains relevant: clicking/opening one conversation can cause project/sidebar conversations to disappear.
• Existing and newly created conversations can still disappear from project history unless pinned.
• This confirms the issue was not resolved for this Windows install by upgrading from 26.616.9593.0 to 26.616.10790.0.

Still requesting an official Windows-safe recovery/reindex command or migration fix that rebuilds project/sidebar conversation visibility from existing local .codex data.

@cocodanila You are spamming this issue by automatically having your Codex app/agent re‑report every time you update the app with the same information, which is not necessary because this is still an issue until it has been resolved. Nobody is closing the issue. A monthly follow up is plenty enough to keep this on the radar and as you can see, your current approach haven't moved the needle on this one.

Posting the exact same automated information every single time you update the app, does not benefit anyone or help in any way to get this resolved, I am afraid, potentially just the opposite.

Can you imagine if we all did the same as you? And we did that with every single annoyance we had with the app, and we just spammed every single issue in this and all other repositories under those terms. While this is probably something that is running fully automatic on your end and without you even putting eyes on it, other people are being notified of your useless information because we wish to subscribe to an issue to be informed when it truly has forward progress, no just regurging the same thing over and over again. We don't need the repetition of you having the problem still. We all know you have the problem.

From another user that wants this solved as much as you. Please stop.

You are right. The repeated updates were not intended as spam, but I understand the impact on everyone subscribed to the issue.

I will stop the automatic follow-ups on every app update. I thought the typical behavior was that of a incident management where you update the ticket with new information, not a broadcast to the world. And is not the same information, with each upgrade the things are going from bad to worse.

Same issue. This problem has occurred several times over the past month, but sometimes it seemed to get resolved quickly. The latest issue is that, aside from conversations from the past day, only conversations from seven months ago show up. On top of that, the rendering is broken—they all just display as 'new conversation,' though pinned conversations are fine.

I checked ~/.codex/sessions and the data is all still there. This is honestly a very amateur bug, and it has never been fixed.

This is persistent for me as well. 200+ conversations missing. Some are accessible via search, but otherwise gone. Support@openai.com keeps replying with instructions for hallucinated settings that don’t exist in their desktop app. No path to a human.

Chats show for an instant before vanishing when I launch the app.

What worked for me:

Open:
C:\Users\<USERNAME>\.codex\sessions

Browse to the matching:
year\month\day
Find the session file matching your last chat time.
Copy the session UUID from the filename. (e.g. rollout-2026-07-13T03-30-54-SESSION_UUID.jsonl)

Run:
codex resume <session_id>

Send a simple message like:
hi

After that, the thread appeared again in Codex chats.

Backup your .codex folder first, and do not edit the .jsonl session files.

for large number of sessions you can write some script which loop it.

I’m seeing the same class of issue, but in my case the entire Projects list is empty after the desktop app migration. Recent tasks remain visible, but all saved project entries and task-to-project associations are missing.

Codex Desktop: 26.707.62119 (build 5211)
macOS: 26.5.2, arm64
Feedback ID: 019f5b41-d408-77a3-8280-abd3dc87d669

I have not reinstalled the app or cleared local data. Please advise whether the project migration can be re-run or the saved project index can be safely restored.

What worked for me: Open: C:\Users\<USERNAME>\.codex\sessions Browse to the matching: year\month\day Find the session file matching your last chat time. Copy the session UUID from the filename. (e.g. rollout-2026-07-13T03-30-54-SESSION_UUID.jsonl) Run: codex resume <session_id> Send a simple message like: hi After that, the thread appeared again in Codex chats. Backup your .codex folder first, and do not edit the .jsonl session files. for large number of sessions you can write some script which loop it.

Thanks for this; I had codex create a skill that processed 20 chats at a time in separate terminal windows since each one has to be resumed separately. It appears I have recovered everything in about half an hour.

I'm seeing what may be the same underlying issue on the latest macOS desktop app, although my symptoms are slightly different.

Environment
macOS Tahoe 26.5.1
ChatGPT for Mac
Version 26.707.91948 (Released Jul 15, 2026)

Updated from the legacy ChatGPT desktop app (not a fresh install)

ChatGPT Plus

What I'm seeing

• The desktop app only exposes ChatGPT Work and Codex. There is no Chat mode available anywhere in the app.
• The Projects section recently reappeared after today's update, but it is empty.
• There is no way to access Custom GPTs from the desktop app.
• Searching the command palette (⌘K) for "Chat" does not provide any way to switch to Chat mode.

Important observation
On chatgpt.com, using the same account, everything is present and working normally:

• Chat mode is available.
• Work mode is available.
• All Projects are present.
• All Custom GPTs are present (under More → GPTs).

So this does not appear to be data loss or an account synchronization issue. It appears that the desktop app is loading a different navigation/UI than the web app, preventing access to Chat, Projects, and GPTs.

Has anyone else on macOS 26.707.91948 seen the same behavior?

<img width="355" height="345" alt="Image" src="https://github.com/user-attachments/assets/3421249a-51b6-4610-b34d-fcf8b7d10f95" />

Sharing this in case it helps anyone else: I created a generic helper repo for migrating local Codex Desktop project chat history between Macs.

It backs up selected ~/.codex data, restores it on the new machine, rewrites old project paths to the new clone path, and rebuilds the local session index:

https://github.com/ademozsayin/codex-history-migrator

This is a workaround for local history/sidebar state that does not fully come back from sign-in alone.