Codex Desktop bug report: recent conversation history hidden/stale despite local DB containing threads

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

• #20493
• #20608
• #20959
• #20833
• #20419

Powered by Codex Action

Potential duplicates detected. Please review them and close your issue if it is a duplicate. Codex Desktop: chats disappear after update/import; imported threads open blank despite JSONL turns #20493 Codex Desktop macOS project sidebar hides unarchived local threads even though SQLite/session files are intact #20608 Codex Mac app hides unarchived local threads until they are messaged again #20959 Codex Desktop project sidebar hides older workspace conversations despite existing local thread data #20833 * macOS Desktop sidebar hides older local conversations despite existing thread state #20419 _Powered by Codex Action_

I reviewed the suggested duplicates. #20493 is the closest because it also involves the Imported agent setup flow and hidden local chats, but this issue has a different diagnostic signature: state_5.sqlite integrity is OK, app-server thread/list with useStateDbOnly:true returns the missing rows, and Codex Desktop restores stale selected-remote-host-id / active-workspace-roots on startup even after repairing both .codex-global-state.json and .codex-global-state.json.bak.

#20608, #20959, #20833, and #20419 are related sidebar/history visibility issues, but they do not cover the imported-agent trigger plus stale remote/workspace state restoration. I do not think this is an exact duplicate, though it may share the same broader sidebar/history indexing root cause.

Adding another reproduction/evidence set from Windows Desktop.

Reporter: @nemesistms

Environment observed:

• Windows Desktop app package path: OpenAI.Codex_26.506.3741.0_x64__2p2nqsd0c76g0
• Codex home: %USERPROFILE%\.codex
• Relevant files: state_5.sqlite, session_index.jsonl, .codex-global-state.json

We have now seen two related failure modes where chats/projects disappear from the Desktop sidebar/search while the local SQLite DB still contains the data.

Failure mode 1: project/sidebar state loss

• state_5.sqlite still contained the threads.
• .codex-global-state.json was rewritten to a minimal state.
• Missing/empty keys included electron-saved-workspace-roots, project-order, and active-workspace-roots.
• thread-workspace-root-hints was reduced to only one entry.
• Reconstructing those roots/hints from state_5.sqlite restored the project groups in the sidebar.

Failure mode 2: stale/incomplete session_index.jsonl

• In a later recurrence, the newest valid state was in state_5.sqlite, not in the last backup.
• The DB had more active chats than session_index.jsonl.
• Restoring an older backup would have lost newer chats from the visible index.
• Rebuilding session_index.jsonl from current SQLite fixed the visible chat list.
• Validation after rebuild in that incident: db_active=192, index_ids=192, missing_from_index=0, extra_in_index=0.

Local mitigation we added:

• A scheduled guard validates .codex-global-state.json and session_index.jsonl against state_5.sqlite.
• It treats SQLite as the source of truth for active thread IDs.
• If session_index.jsonl has missing/extra/duplicate IDs, it atomically rebuilds the index from SQLite instead of restoring an old backup.
• Current validation after hardening: db_active=190, index_entries=190, index_ids=190, missing_from_index=0, extra_in_index=0.

Other observations:

• Codex Desktop sometimes becomes unresponsive on Windows and triggers the Windows “wait or close” dialog.
• Logs showed sidebar/project Git scanning and some path duplication between normal Windows paths and extended \\?\ paths.
• My suspicion is that unresponsive shutdowns or startup/sidebar reconciliation can leave .codex-global-state.json or session_index.jsonl stale/incomplete, while SQLite remains correct.

Suggested product-side fix:

1. Make .codex-global-state.json and session_index.jsonl writes atomic and crash-safe.
2. On startup, compare active/unarchived thread IDs in state_5.sqlite with session_index.jsonl; rebuild if inconsistent.
3. Do not replace global sidebar/project state with a minimal object during migration/runtime failures.
4. Normalize Windows path comparisons consistently for C:\... vs \\?\C:\....
5. Keep sidebar Git/project scanning from blocking renderer responsiveness or state writes.

Adding another macOS reproduction/evidence set from Codex Desktop.

Environment observed:

• Codex Desktop: 26.506.31421
• macOS: 26.3.1 (25D771280a), arm64
• Codex home: ~/.codex
• Relevant files checked: state_5.sqlite, session_index.jsonl, .codex-global-state.json

Symptom:

• Project sidebar shows no chats for two local projects even though the chats are not archived.
• User also checked Archive; the missing project chats are not visible there either.
• Restarting the UI did not restore the project chat lists.

Concrete local evidence:

• state_5.sqlite integrity check returns ok.
• The local DB contains active, unarchived threads for the missing projects:

/Users/rajesh/flextract/src/advisory | archived=0 | count=11
/Users/rajesh/flextract/src/flex     | archived=0 | count=30
/Users/rajesh/flextract/src/flex     | archived=1 | count=3

• Example missing active threads:

019e0406-b786-7e73-aa62-99026035e821 | Review AI simplification options | /Users/rajesh/flextract/src/advisory | archived=0
019e1207-ece9-7f62-9cb9-6fa4feea667c | Investigate app-server protocol  | /Users/rajesh/flextract/src/flex     | archived=0
019e1275-e8af-77e2-8903-ad5791080fd8 | Implement document pipeline       | /Users/rajesh/flextract/src/flex     | archived=0

• Those thread IDs are also present in session_index.jsonl, and their rollout paths point to existing files under ~/.codex/sessions/....

Global/sidebar state observations:

• electron-saved-workspace-roots included both project roots:

/Users/rajesh/flextract/src/advisory
/Users/rajesh/flextract/src/flex

• project-order included advisory but did not include flex.
• thread-workspace-root-hints had no entries for either advisory or flex; it mostly contained projectless ~/Documents/Codex mappings.

Attempted local mitigation:

• Backed up .codex-global-state.json.
• Added /Users/rajesh/flextract/src/flex to project-order.
• Added thread-workspace-root-hints for 41 active advisory/flex thread IDs from SQLite.
• Restarting/refreshing still did not make the project chat lists appear.

This looks like the same broader failure class: SQLite/session/index data exists, archive state is correct, but the Desktop sidebar project view is applying another stale/incomplete filter or source of truth and hiding valid local project threads.

One more important signal from my case: the same chats are visible in the mobile app, but not in Codex Desktop. So the data is not lost; this appears to be a Desktop sidebar/recent-conversations loading issue.

Desktop seems to load/group only the first 50 recent conversations. For users with many local chats, older project chats disappear from the visible sidebar and projects show “No chats”, even though the threads still exist locally.

Impact: this looks like lost chat history. In my case I need at least 200 visible/recent chats, or proper pagination/per-project loading so projects do not appear empty just because their chats are outside the first 50.

Please increase the Desktop recent conversation cap substantially, or load project conversations independently from the initial recent-conversations page.

Adding another data point, this time from Windows, because it looks like the same user-visible failure mode but with a more specific local-state clue.

Environment:

• Codex Desktop app: OpenAI.Codex 26.513.4821.0
• Platform: Microsoft Windows 11 Pro 10.0.26200, 64-bit
• Local state DB: %USERPROFILE%\.codex\state_5.sqlite
• Current standalone codex --version on PATH: codex-cli 0.130.0
• Affected threads were older Desktop-created rows from previous Codex Desktop/CLI builds; newly created Desktop threads were visible.

Observed behavior:

• Desktop sidebar showed only the newly-created current thread for a project, making earlier project threads appear lost.
• The missing conversations still existed on disk and in session_index.jsonl / rollout JSONL files.
• The missing conversations also existed in state_5.sqlite with archived = 0.
• The issue was not project-specific; the user reported this happening repeatedly across multiple workspaces.

Important DB difference found locally:

• Hidden older Desktop rows had source = 'vscode', archived = 0, and thread_source IS NULL.
• Newly created visible Desktop rows had source = 'vscode', archived = 0, and thread_source = 'user'.
• In this local state, there were 92 unarchived Desktop rows with thread_source IS NULL.
• PRAGMA integrity_check returned ok.

Local repair that restored visibility:

UPDATE threads
SET thread_source = 'user'
WHERE archived = 0
  AND source = 'vscode'
  AND thread_source IS NULL;

After that update, the hidden project thread appeared again in local enumeration, and the count of unarchived Desktop rows with null thread_source went from 92 to 0.

Hypothesis:
There may be a migration or sidebar filtering path that treats older Desktop-created rows with thread_source IS NULL as non-user/non-sidebar threads, while newer Desktop-created rows correctly get thread_source = 'user'. This makes existing local history look deleted even though the DB and rollout files still contain it.

Suggested fix area:

• Ensure Desktop sidebar queries include legacy top-level Desktop threads where source = 'vscode' and thread_source IS NULL, or migrate those rows to thread_source = 'user'.
• Make the migration idempotent and safe across app updates so users do not perceive local conversation loss.

This comment intentionally avoids naming the user’s private project/thread details; the key reproducible signal is the thread_source difference above.

Adding another macOS data point. This looks like the same broad Desktop sidebar/project visibility failure class, but with one extra reconciliation detail that may help narrow the bug.

Environment:

• Codex Desktop: 26.513.31313
• macOS: 26.4.1, arm64
• Relevant local files:
• ~/.codex/state_5.sqlite
• ~/.codex/.codex-global-state.json
• ~/.codex/session_index.jsonl
• ~/.codex/sessions/.../rollout-*.jsonl

Observed behavior:

• Desktop and mobile project/sidebar views diverged.
• One Desktop project showed as empty / "No chats" even though the local SQLite DB contained non-archived threads for that project.
• Another project was restored by fixing the saved workspace root, but a second project kept showing the wrong contents after restarts.
• Updating threads.cwd in state_5.sqlite and repairing .codex-global-state.json was not enough. After restart, Desktop would reintroduce stale project/workspace state.

Additional local finding:

• Codex appears to scan rollout JSONL on startup / thread/list and use session_meta.payload.cwd as a metadata repair source.
• In my case, the affected thread's rollout JSONL still had a stale session_meta.payload.cwd.
• Because of that, correcting only SQLite/global state was temporary: the app-server would rehydrate the stale cwd from the rollout JSONL and effectively push the project/sidebar state back into the broken state.

Local repair that finally restored the project sidebar:

1. Fully quit Codex Desktop.
2. Back up:

• state_5.sqlite
• .codex-global-state.json
• the affected rollout-*.jsonl

1. Update the stale session_meta.payload.cwd in the affected rollout JSONL.
2. Update the matching threads.cwd rows in state_5.sqlite.
3. Update .codex-global-state.json project roots / labels / thread workspace hints.
4. Restart Codex.

After the rollout JSONL cwd was aligned with the DB/global state, the missing project conversations reappeared.

Hypothesis:
There may be a startup/sidebar reconciliation issue where rollout JSONL, SQLite thread metadata, and Desktop global sidebar state disagree. If rollout JSONL is treated as an authoritative repair source, stale session_meta.payload.cwd values can override corrected SQLite/global state and make valid local project threads appear missing or grouped under the wrong/empty project.

Suggested fix area:

• Make the source-of-truth ordering explicit for project/workspace assignment.
• Avoid silently overwriting corrected threads.cwd / sidebar state from stale rollout JSONL.
• If JSONL metadata repair is necessary, detect conflicts and either preserve the newer/corrected state or surface a repair/migration warning.

If the missing threads still exist in state_5.sqlite / rollout JSONL files, one thing worth checking is whether the local history is split across different model_provider buckets.

I maintain an unofficial helper for that specific case: https://github.com/Wangnov/codex-threadripper

Start with the read-only diagnostic first:

codex-threadripper status

If it shows threads split across providers, codex-threadripper sync can reconcile the local metadata so Codex Desktop / codex resume / app-server clients see the same history again. It writes backups before changing local state, but I would still back up ~/.codex first.

Caveat: this only targets provider-bucket visibility drift. If the root cause is sidebar cache/state, workspace path normalization, or encrypted-content ownership across accounts, it may not fix the underlying issue.

Thanks for the suggestion. I checked my local state_5.sqlite and the first lines of the rollout JSONL files, and all threads are currently under model_provider = openai, with no provider-bucket mismatch found.

So this specific case does not look like provider visibility drift, but the diagnostic idea was helpful. In my case the remaining suspect still seems to be cwd/sidebar/project state reconciliation between rollout JSONL, SQLite, and global state.

Additional Windows data point with a very consistent ~7-day visibility window.

Environment:

• Codex Desktop app: 26.519.5221.0
• Platform: Windows NT 10.0.19045.0 x64
• Local state DB: %USERPROFILE%\.codex\state_5.sqlite
• Electron/UI cache: %APPDATA%\Codex

Observed:

• The Desktop sidebar only shows conversations from roughly the last 7 days.
• Older conversations appear missing in the UI, but they are still present in the local SQLite state DB.
• Rebuilding session_index.jsonl and thread-workspace-root-hints from the DB succeeds, but the Desktop UI still hides conversations older than the recent window.
• Clearing/renaming the Electron/UI cache does not fix the issue.

Local diagnostic counts from state_5.sqlite:

• total threads: 90
• unarchived threads: 89
• threads with updated_at < now - 7 days: 43
• oldest updated_at: 2026-04-17 00:18:37 UTC
• newest updated_at: 2026-05-25 09:16:25 UTC

A temporary workaround that changes older threads' updated_at values into a synthetic now - 6 days window makes the conversations visible again, but they begin falling out of the sidebar again the next day. That strongly suggests the Desktop sidebar, or the app-server path feeding it, is applying a sliding recency filter/window rather than losing the underlying data.

Expected:

• All unarchived local conversations should remain visible, or at least reachable through pagination/search/load-more, regardless of age.
• The Desktop UI should not silently present locally persisted conversations as lost simply because updated_at is outside a recent time window.

I am intentionally omitting exact workspace paths and conversation contents here, but can provide more redacted diagnostics if useful.