Codex Desktop update lost project/sidebar conversation history mapping although local sessions still exist #26157

Activity

1. lalalavifda

   added

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   on Jun 3, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   sessionIssues involving session (thread) management, resuming, forking, naming, archivingIssues involving session (thread) management, resuming, forking, naming, archiving

   on Jun 3, 2026
3. github-actions commented on Jun 3, 2026

   

   github-actionsBot

   on Jun 3, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Codex Desktop hides active project chat history while local threads remain on disk #25084
   • Codex app project chat history disappears after reopening app #26031
   • Previously lost attachment-only conversations remain unrecovered after latest update; needs reindex/recovery path #25924
   • Codex App remote project conversations disappear from local sidebar, but still exist on the remote server #25092
   • Desktop Codex cannot open older chat sessions after recent update #26104

   Powered by Codex Action
4. wangyaok1 commented on Jun 7, 2026

   

   wangyaok1

   on Jun 7, 2026 – with ChatGPT Codex Connector

   More actions

   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.
5. fzdwx commented on Jul 24, 2026

   

   fzdwx

   on Jul 24, 2026

   More actions

   I can reproduce a very similar issue on macOS after today's ChatGPT/Codex desktop update.

   Version / build:

   • ChatGPT.app: 26.721.30844
   • CFBundleVersion: 5813
   • macOS desktop app

   Observed behavior:

   • The left sidebar Codex "Recent" section shows "No tasks" / no task entries.
   • Existing tasks are still available through the task search popup; search shows both unfinished and completed tasks across projects such as apex/friend/admin.
   • Pinning a task does not make it appear in the sidebar either.
   • The local task index is still intact: the app-level task listing API can return the existing tasks, including recent active/idle/notLoaded tasks, so this does not look like data deletion.
   • Some tasks have a saved project association, while others are projectless, but the sidebar fails even for the general recent/pinned visibility path.

   This started after updating today; the same sidebar/project task list was working yesterday. The behavior looks like a regression in the sidebar/project task-list filtering or thread-to-project mapping layer rather than missing session data.
6. asavs commented on Jul 28, 2026

   

   asavs

   on Jul 28, 2026 – with ChatGPT Codex Connector

   Last edited by asavs

   More actions

   I can reproduce the same underlying failure on Windows, with one useful distinction from the recent macOS reports: the task is omitted by the app-level task-list API itself, not only by the rendered sidebar.

   Environment:

   • ChatGPT/Codex desktop: 26.721.4979.0
   • Bundled Codex CLI: 0.146.0-alpha.3.1
   • Windows NT 10.0.26200.8875 x64

   Observed behavior:

   • One completed local root task is absent from the sidebar/recent list.
   • list_threads(limit=50) skips that task even though it returns both newer and older tasks from the same workspace.
   • The task is not archived; its rollout remains under ~/.codex/sessions.
   • session_index.jsonl contains the exact task ID, title, and an updated_at entry.
   • A direct read_thread(threadId, hostId="local") succeeds and returns the complete task, including its final answer.
   • Opening codex://threads/<thread-id> or navigating directly by task ID opens the task successfully in Codex Desktop.

   This establishes that the conversation is intact and loadable, while enumeration/index projection is dropping it.

   One potentially useful clue: the session-index timestamp corresponds to the beginning of the task, while the directly read task metadata correctly reports completion roughly 3 hours 19 minutes later. The affected task was a long GPT-5.6 Sol Ultra run with multiple compactions and delegated subagents.

   Expected behavior:

   • Any non-archived task present in session_index.jsonl and readable by ID should be returned by list_threads and appear under the documented Chronological task view.
   • If an index projection is stale, Codex Desktop should rebuild it from the durable session metadata.

   No local paths, source contents, prompts, or full session logs are included here. I can provide the affected task ID or redacted metadata privately if maintainers need it.

   — GPT-5.6 Sol High
7. BradGroux commented on Aug 3, 2026

   

   BradGroux

   on Aug 3, 2026

   More actions

   Adding a current macOS data point that isolates the project-assignment/sidebar layer from path-migration problems.

   Environment:

   • Codex Desktop: 26.727.51351 (build 6119)
   • Bundled CLI: codex-cli 0.146.0-alpha.9.2
   • Platform: macOS arm64
   • Storage: default ~/.codex

   All checks were read-only. Project names, absolute paths, titles, messages, and thread IDs are redacted.

   What is intact

   The primary store is internally consistent:

   state_5.sqlite integrity: ok
   total rows:               1,898
   active rows:              1,867
   archived rows:               31
   
   active rollout files:     1,867
   archived rollout files:      31
   

   An older hidden conversation can still be read directly by its known ID. The app returns it as notLoaded, not missing or corrupt.

   Exact project-mapping mismatch

   The affected saved project still exists, its root has not moved, and the stored project root exactly matches the cwd on the historical thread rows. This is therefore not a path-normalization or deleted-folder case.

   For one sanitized affected project:

   primary database rows at exact project cwd:
     active rows:                   65
     active direct conversations:  42
   
   global Desktop project state:
     explicit thread assignments:   2
     sidebar thread-order IDs:       1
   

   The single sidebar ID is the newly opened current conversation. Older rows with the same exact cwd were not backfilled into that project.

   Across the complete local state:

   saved local project objects:           28
   legacy saved workspace roots:          21
   active primary thread rows:         1,867
   thread-project-assignment entries:     208
   projects with sidebar thread orders:     8
   

   These counts do not prove that every historical row requires a permanent explicit assignment, but they do prove that the rendered project history cannot rely on those sparse caches without falling back to durable thread metadata.

   Current catalog sync is also incomplete

   The newer app-level catalog at ~/.codex/sqlite/codex-dev.db passes its integrity check, but it does not contain the affected project cwd at all:

   local_thread_catalog rows:            109
   distinct cwd values:                   10
   initial_build_complete:                 0
   watermark_updated_at:                NULL
   last_full_reconciled_at:             NULL
   observation_sequence:                 899
   

   Its newest source update is from July 17, while valid primary-store threads continue through August 3.

   The observed behavior is therefore:

   1. Durable thread rows and rollout files remain healthy.
   2. The saved project and exact cwd association remain valid.
   3. The explicit project/sidebar mapping contains only newly observed threads.
   4. The catalog cold-start/backfill is incomplete and has no watermark.
   5. Opening a new conversation adds that conversation to the project but does not recover older same-cwd history.

   Requested behavior

   The project/sidebar state should be treated as a rebuildable projection, not the authority for whether history exists.

   A safe recovery path should:

   1. Canonicalize each saved project root and match all persisted thread cwd values during a full paginated backfill.
   2. Use exact-cwd/root containment as a fallback when an explicit assignment is absent.
   3. Merge existing explicit assignments instead of discarding them.
   4. Populate sidebar order from the rebuilt project catalog, ordered by persisted recency.
   5. Persist a watermark and completion marker only after the full snapshot succeeds.
   6. Automatically retry or reconcile whenever initial_build_complete = 0 or the watermark is null.
   7. Provide a supported UI/CLI action to rebuild project/thread mappings without editing .codex-global-state.json or SQLite manually.

   Manual edits are not a durable solution because the running app can rewrite the global state. The app has enough authoritative local data to reconstruct these associations without mutating conversation content.
8. etraut-openai

   marked Codex macOS app update lost local conversation history from sidebar while sessions still exist locally #35585 as a duplicate of this issue on Aug 6, 2026
9. DanialRa04 commented on Aug 10, 2026

   

   DanialRa04

   on Aug 10, 2026

   More actions

   I encountered what appears to be the same underlying problem on Windows, but I was able to identify the local-state inconsistency and recover the missing projects/conversation mappings without modifying the actual conversation data.

   Environment

   • Codex Desktop: 26.803.5235.0
   • Package: OpenAI.Codex_26.803.5235.0_x64__2p2nqsd0c76g0
   • Subscription: ChatGPT Plus
   • OS: Microsoft Windows NT 10.0.26200.0 x64

   What happened

   After restarting Windows and reopening Codex Desktop, the app behaved like a fresh installation:

   • onboarding/preferences appeared again;
   • most of my projects disappeared;
   • old conversations were no longer visible inside their original projects;
   • some existing conversations appeared to become projectless.

   At first it looked like the conversations were gone, but the underlying data was still present.

   What I found

   Before the problem:

   • local projects: 8
   • project order entries: 8
   • projectless threads: 2

   After the problem:

   • local projects: 1
   • project order entries: 1
   • projectless threads: 10

   However, the conversation data itself was still intact:

   • active session JSONL files: 90
   • archived session JSONL files: 1
   • state_5.sqlite threads: 91
     • active: 90
     • archived: 1

   There was also an index inconsistency:

   • session_index.jsonl: 78 lines
   • unique usable thread IDs: 77
   • active SQLite threads: 90

   So about 13 active threads were missing from the session index, even though their session JSONLs and SQLite records still existed.

   Important finding

   The biggest difference was in:

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

   The broken/recreated version was only about 8 KB and contained only one project.

   A surviving pre-failure temporary backup file in the same directory was about 123 KB and still contained the original project/workspace metadata, including:

   local-projects
   project-order
   selected-project
   active-workspace-roots
   electron-saved-workspace-roots
   thread-project-assignments
   thread-workspace-root-hints
   thread-projectless-output-directories
   projectless-thread-ids
   

   That older file still contained all 8 original projects.

   How I recovered it

   First, I fully closed Codex and backed up the entire local Codex directory:

   $src = Join-Path $env:USERPROFILE ".codex"
   $dst = Join-Path $env:USERPROFILE "Desktop\codex-FULL-backup"
   
   Copy-Item $src $dst -Recurse -Force

   Then I listed possible global-state backups:

   Get-ChildItem "$env:USERPROFILE\.codex" |
   Where-Object {
       $_.Name -like "*codex-global-state*"
   } |
   Select-Object Name, Length, LastWriteTime

   I found a surviving pre-reset state file in the form:

   ..codex-global-state.json.bak.tmp-<timestamp>-<uuid>
   

   I verified that it was the older, complete state file and then, with Codex fully closed, restored it over the active global-state file:

   $root = Join-Path $env:USERPROFILE ".codex"
   
   $old = Join-Path $root "<OLD_GLOBAL_STATE_FILENAME>"
   $current = Join-Path $root ".codex-global-state.json"
   
   Copy-Item `
       -LiteralPath $old `
       -Destination $current `
       -Force

   I did not modify:

   state_5.sqlite
   sessions/
   archived_sessions/
   session_index.jsonl
   

   After reopening Codex:

   • all 8 original projects returned;
   • old conversations became visible again;
   • project associations returned;
   • the archived conversation was still present;
   • automations and attachments were still intact.

   So in my case, the conversations were never deleted. The problem was the local project/history metadata being reset or regenerated inconsistently.

   Additional verification

   I also compared important user data against the backup:

   • active sessions: exact match
   • archived sessions: exact match
   • automations: exact match
   • attachments: exact match
   • rules: exact match
   • skills: exact match
   • auth.json: identical SHA-256 hash

   The only notable differences were in runtime/plugin cache files, which appeared to be expected application-update changes rather than user-data loss.

   Suggestion

   It would be very useful if Codex could automatically detect and repair inconsistencies between:

   sessions/*.jsonl
   archived_sessions/*.jsonl
   state_*.sqlite
   session_index.jsonl
   .codex-global-state.json
   

   A built-in recovery/reindex option would probably prevent users from thinking their conversations are permanently gone when the actual conversation data is still intact.
10. TyceHerrman commented on Aug 24, 2026

    

    TyceHerrman

    on Aug 24, 2026

    More actions

    #38940 added experimental SQLite-backed project records, thread project_id assignments, project/import, and project/thread change notifications.

    This looks like it's possibly groundwork for making project/sidebar state durable, but existing Desktop project assignments and sidebar history don't seem to be fully migrated or rebuilt after an update
11. devdoshi commented on Aug 26, 2026

    

    devdoshi

    on Aug 26, 2026

    More actions

    It's always pretty disturbing when this happens to me especially since I work on a lot of projects and use a lot of harnesses. Aside from addressing the issue at its root cause so it can never happen, it seems like a Jetbrains style "invalidate caches and restart" kind of button might make sense moving forward?