Codex Desktop 26.519.22136: local project conversation history missing after update, threads still exist in state_5.sqlite

[catink]

Summary

After updating Codex Desktop on macOS on May 22, 2026, multiple local project conversation histories disappeared from the Codex Desktop UI. The underlying local data still exists in ~/.codex, including state_5.sqlite, session_index.jsonl, and the original rollout JSONL files under sessions/ and archived_sessions/. The issue appears to be a UI/sidebar/project-history indexing or migration bug rather than data deletion.

Environment

• Product: Codex Desktop App
• Platform: macOS
• Codex Desktop version observed in process metadata: 26.519.22136
• Time of update/problem: May 22, 2026, Asia/Shanghai timezone
• Local Codex directory: ~/.codex

User-Visible Impact

The following projects no longer show their expected conversation history in Codex Desktop:

• /Users/<user>/Documents/code/project_244
• /Users/<user>/Documents/code/project_466
• Potentially also affected:
  • /Users/<user>/Documents/code/project_A
  • /Users/<user>/Documents/code/project_B
  • /Users/<user>/Documents/code/project_C

The conversations are important because they contain project-specific debugging, automation, data-processing, and research workflow context.

Evidence That Data Still Exists

Local database and rollout files still contain the missing threads.

state_5.sqlite

Query:

select id, cwd, title, archived, rollout_path
from threads
where cwd in (
  '/Users/<user>/Documents/code/project_244',
  '/Users/<user>/Documents/code/project_466'
)
order by updated_at desc;

Observed results include:

• <thread_id_466_1>

  • cwd: /Users/<user>/Documents/code/project_466
  • archived: 0
  • rollout: ~/.codex/sessions/2026/03/19/rollout-2026-03-19T17-13-52-<thread_id_466_1>.jsonl

• <thread_id_244_1>

  • cwd: /Users/<user>/Documents/code/project_244
  • archived: 0
  • rollout: ~/.codex/sessions/2026/04/01/rollout-2026-04-01T09-04-49-<thread_id_244_1>.jsonl

• <thread_id_244_2>

  • cwd: /Users/<user>/Documents/code/project_244
  • archived: 0
  • rollout: ~/.codex/sessions/2026/03/27/rollout-2026-03-27T09-52-15-<thread_id_244_2>.jsonl

• <thread_id_244_archived_1>

  • cwd: /Users/<user>/Documents/code/project_244
  • archived: 1
  • rollout: ~/.codex/archived_sessions/rollout-2026-04-01T09-03-55-<thread_id_244_archived_1>.jsonl

Counts

• state_5.sqlite contains 153 threads.
• The rollout JSONL files under sessions/ and archived_sessions/ also total 153 files.
• session_index.jsonl had only 100 entries after update, which suggested an incomplete or stale index. Rebuilding it to 154 lines did not restore UI visibility.

Suspicious Migration/UI State Details

~/.codex/.codex-global-state.json contains:

• electron-saved-workspace-roots including:
  • /Users/<user>/Documents/code/project_244
  • /Users/<user>/Documents/code/project_466
  • /Users/<user>/Documents/code/project_A
  • /Users/<user>/Documents/code/project_B

But project-order was truncated and only contained paths up to:

"/Users/<user>/Documents/code/project_244"

The following saved roots were missing from project-order after the update:

• /Users/<user>/Documents/code/project_A
• /Users/<user>/Documents/code/project_C
• /Users/<user>/Documents/code/project_B
• /Users/<user>/Documents/code/project_466

Manually adding them back did not restore visibility. Codex Desktop also appeared to rewrite .codex-global-state.json from an in-memory or separate persisted state on restart.

Attempted Workarounds

The following local recovery attempts were made after a full backup of ~/.codex:

1. Backed up the full ~/.codex directory.
2. Added missing saved workspace roots back into project-order.
3. Rebuilt session_index.jsonl from state_5.sqlite.
4. Added all non-archived threads to projectless-thread-ids.
5. Temporarily locked .codex-global-state.json with macOS uchg to prevent overwrite during restart, then removed the lock.
6. Investigated thread_source:
   • Newer visible-looking threads often had thread_source='user'.
   • Older missing project threads had thread_source set to NULL.
   • Updated 51 non-archived, non-automation old local threads from NULL to user.

None of these restored the missing conversations in the Codex Desktop UI.

Relevant Related Public Issues

These GitHub issues appear related:

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

  • Similar symptoms: macOS Desktop UI missing/stale history while local DB still contains threads.

• Windows Desktop: sidebar/project list lost after update; search still finds threads; projectless-thread-ids workaround restores flat chats but project grouping remains broken #19873

  • Similar symptoms: sidebar/project list lost after update while local state files still exist.

• Desktop project sidebar hides active threads after state DB migration drift and stale temporary sessions #17304

  • Mentions possible state DB migration/sidebar history issues and app-server thread APIs.

• Windows app: older local threads disappear from sidebar and sidebar search after restart while still present on disk #17540

  • Similar symptoms: older local threads disappear from UI while still present on disk.

Expected Behavior

Codex Desktop should display all non-archived local threads whose cwd points to saved workspace roots. For the affected projects, it should show at least:

• 2 non-archived threads under /Users/<user>/Documents/code/project_244
• 1 non-archived thread under /Users/<user>/Documents/code/project_466

Archived threads should remain visible through the archived/history view.

Actual Behavior

The affected project conversation histories are not visible in the Codex Desktop UI after the update, even though local SQLite rows and rollout JSONL files exist and remain readable.

Requested Help

Please advise how to repair or rebuild the Codex Desktop conversation sidebar/project-history index for existing local threads. If this is a known migration bug in Codex Desktop 26.519.22136, please provide:

1. A supported recovery procedure.
2. Whether state_5.sqlite, session_index.jsonl, .codex-global-state.json, or app-server state is authoritative for the Desktop UI.
3. Whether there is a command to force a full local history reindex/backfill.
4. Whether a fixed version is available or planned.

Attachments / Logs Available On Request

The user can provide:

• A redacted copy of ~/.codex/state_5.sqlite
• A redacted copy of ~/.codex/session_index.jsonl
• Selected redacted rollout JSONL files for the affected thread IDs
• ~/.codex/.codex-global-state.json
• logs_2.sqlite excerpts

Please note that some files may contain private conversation content, local paths, and authentication-related metadata. Redaction guidance would be appreciated.

[github-actions]

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

• Codex Desktop sidebar project groups only show threads from the first recent page; expanding a project does not load remaining project threads #23825
• Chat Tree lost all my chats #23966
• Codex Desktop project sidebar shows empty even when threads have matching cwd #23609
• Codex Desktop project sidebar shows No chats while local sessions still exist #22796
• Codex Desktop macOS hides unarchived local threads even when they are inside the recent-50 window #22592

Powered by Codex Action

[chenjxpp]

Codex Desktop: Older Project Chats Disappear From Sidebar

Cause

This is usually not data loss. Codex Desktop appears to load only a limited global recent-thread window for the sidebar, roughly the most recently updated conversations. A total 50 list.

When many other threads are newer, older project chats can fall outside that window and disappear from the project sidebar even though they still exist in local storage.

Typical evidence:

• The chat is missing from the Desktop sidebar.
• The thread still exists in %USERPROFILE%\.codex\state_5.sqlite.
• The rollout file still exists under %USERPROFILE%\.codex\sessions\....
• Archiving newer low-value threads or refreshing the missing thread makes it visible again.

Fixes

1. Archive low-value visible threads

Archive temporary, generated, test, or unneeded threads that currently occupy the sidebar. This frees space in the recent-thread window, so older useful project chats can show again.

Use Codex Desktop UI archive, or app-server thread/archive if you know the thread ids.

2. Resume or refresh the missing thread

If you know the missing thread id, resume it and send a very small test turn, for example:

test, please reply OK only.

This updates updated_at, pushing the thread back into the recent window. After that, restart Codex Desktop if the UI does not update immediately.

3. Pin important threads

For long-running or important project chats, pin them so they are less likely to disappear from the sidebar when they fall outside the recent window.

4. Use local state as the source of truth

Do not treat the sidebar as full history. Check local storage when a chat appears missing:

• %USERPROFILE%\.codex\state_5.sqlite
• %USERPROFILE%\.codex\sessions\...\rollout-*.jsonl

Product Bug

The sidebar should page by project, not only depend on the first global recent list. Search should also include all local threads, not only loaded recent threads.

Until that is fixed, the practical workaround is:

archive unneeded recent threads
or
resume the missing thread to refresh its updated_at
then restart Codex Desktop

[justalmostgreat]

+1 — same bug on macOS 26.519.41501 (build 3044), macOS 15.7.4 arm64. @chenjxpp's "~50-thread global window" analysis is likely compounded by a second effect on this machine: my session_index.jsonl is itself short relative to state_5.sqlite. So the window is small and the input feeding the window is truncated.

Reproducible drift signal

File	Count
state_5.sqlite threads rows	723
of which archived=1	13
session_index.jsonl lines	400
Threads in DB but not in JSONL index	323 (~45%)

The sidebar appears to be index-driven, so those 323 threads can't surface even though their rollout files in ~/.codex/sessions/ and their state_5.sqlite rows are intact.

Top affected projects (cwd → thread count in DB):

• ~/.openclaw/workspace: 196
• ~/Documents/repos/ai-tutor-platform: 154
• ~/Documents/repos/ai-tutor-platform-fresh-main: 103
• ~/Documents/repos/zeroclaw: 49 (13 archived)
• ~/Documents/repos/ai-tutor-esl-integrate: 47
• ~/Documents/PRB: 38
• (+ ~14 more)

History on this machine

• On 26.513.20950 (build 2816) until 26.519.x auto-updated on 2026-05-23.
• Symptom appeared after the first computer restart following the update.
• A clean reinstall of 26.519.41501 (verified codesign + spctl, Developer ID OpenAI OpCo LLC) did not fix it — the issue recurs because every launch the 26.519 startup path rewrites session_index.jsonl, and the rebuilt index is short.

What would help

• An official "Rebuild sidebar index from state_5.sqlite + sessions/" command, OR
• A fix in the 26.519 migration / startup path that fully backfills session_index.jsonl from the DB.

Happy to share a sanitized state_5.sqlite + session_index.jsonl snapshot privately if useful.

[sulmusic2-star]

+1 hitting this on Codex Desktop 26.519.41501 (Check for Updates confirms latest). Local thread bodies all render blank; cloud threads still work. Cmd+R, full quit/relaunch, and clearing renderer caches all unhelpful as standalone fixes. Detailed reproduction + correlated logs below — hopefully useful for triage.

Environment

• Codex Desktop: 26.519.41501
• Bundled CLI: codex-cli 0.133.0-alpha.1 (via /Applications/Codex.app/Contents/Resources/codex --version)
• Bundled codex-primary-runtime: 26.521.10419 (per ~/.cache/codex-runtimes/codex-primary-runtime/runtime.json)
• macOS arm64
• Auth: ChatGPT mode

Symptom

Every local thread in the sidebar opens to a completely blank body. Title bar shows the thread name, composer renders normally, but the message area is empty — no spinner, no error, no content. thread/list and thread/read both succeed in 50–150 ms with errorCode=null, so the app-server isn't refusing the requests — the renderer just doesn't paint the body. Cloud-mode threads (with the cloud-badge icon) render fine in the same session.

Timeline (from ~/Library/Logs/com.openai.codex/)

Time	Event
May 24, 23:22	Codex Desktop auto-updates to 26.519.41501 (per /Applications/Codex.app mtime)
May 24, 23:23:30	First error [electron-message-handler] Item not found in turn state itemId=call_qpN8JwKc8PiODD9Ib7WriQ45 fires, 8 min after the update. 4,483 occurrences that day.
May 25, ~09:36	Renderer caches (Local Storage, Session Storage, Code Cache, GPU/Dawn caches, blob_storage) backed up & cleared → threads render again temporarily
May 25, all day	3,289 Item not found in turn state errors continue in background
May 26, 14:07:34	Local automation in conversation 019df683-26de-7823-aaf2-8baa5f99b7ab (184 MB rollout) logs turn_completed_with_incomplete_plan completedPlanStepCount=3 planStepCount=4. Error rate explodes within seconds.
May 26, 14:10–14:18	1,400+ Item not found in turn state errors in 8 minutes. All local thread bodies now render blank.
May 26, all day	14,269 total Item not found in turn state errors
May 26, 16:38	Quarantined 019df683 out of ~/.codex/sessions/ → error rate drops to ~1–3/min
May 26, later	Cache cleared again + Codex fully restarted. Zero Item not found in turn state errors in fresh log. Threads still render blank.

Three stacked issues (after a fresh restart in latest state)

1. "Item not found in turn state" cascade (mitigated by quarantine)

2026-05-24T23:23:30.586Z error [electron-message-handler] Item not found in turn state itemId=call_qpN8JwKc8PiODD9Ib7WriQ45

• 109 unique itemId=call_* references that the renderer can't resolve in old rollouts
• Specifically triggered when an automation turn completes with completedPlanStepCount < planStepCount — references to tool-call items that were planned but never emitted
• Workaround: move the offending rollout out of ~/.codex/sessions/ and restart

2. MCP sidecar (node_repl) initialization timeout — active blocker even after fresh restart

2026-05-26T22:03:56.412Z warning [AppServerConnection] Failed to start local app-server sidecar after app-server initialization
errorMessage="Timed out waiting for MCP response to config/read"

2026-05-26T22:03:57.430Z warning [BundledPluginsMarketplace] bundled_plugins_marketplace_add_failed
errorMessage="Timed out waiting for MCP response to marketplace/add"
marketplaceName=openai-bundled
marketplaceRoot=/Users/timsullivan/.codex/.tmp/bundled-marketplaces/openai-bundled

2026-05-26T22:03:57.430Z warning [bundled-plugins] bundled_plugins_reconcile_failed
errorMessage="Timed out waiting for MCP response to marketplace/add"
hasExternalPluginStateSync=true reason=startup

Manual launch of /Applications/Codex.app/Contents/Resources/node_repl with proper env (CODEX_HOME, CODEX_CLI_PATH) immediately errors:

Error: failed to start stdio MCP server
Caused by:
    connection closed: initialize request

Five stale *.sock files accumulate in /tmp/codex-browser-use/. startup_timeout_sec = 120 is configured but the timeout fires after ~30s — looks like a different sub-call timing out under the main timeout.

3. Feature-flag mismatch (Desktop vs bundled CLI)

2026-05-26T20:23:55.647Z error [electron-message-handler] Request failed
error={"code":-32600,"message":"unsupported feature enablement `auth_elicitation`:
currently supported features are apps, memories, mentions_v2, plugins, remote_control, tool_suggest, tool_call_mcp_elicitation"}
method=experimentalFeature/enablement/set

Desktop renderer tries to enable auth_elicitation; bundled CLI 0.133.0-alpha.1 doesn't support it. Latest stable CLI (0.134.0) released today likely does, but "Check for Updates" reports "You're up to date" so there's no user-facing path to bundle a newer CLI.

What didn't help (in order tried)

• Cmd+R reload (just toggles browser tab, not the chat renderer)
• Full quit + relaunch (multiple times)
• Backing up & clearing renderer caches (Local Storage, Session Storage, GPU/Dawn caches, Code Cache, Cache, blob_storage) — fixed it temporarily on May 25 morning, didn't bite on May 26
• Quarantining large rollouts to lighten app-server load (dropped RSS from 1.3 GB → 128 MB, didn't change rendering)
• Quarantining the specific bad rollout 019df683 that was generating the error cascade (resolved issue update summary to auto #1 but not (cleanup) add link to https://cookbook.openai.com for apply_patch and minor tidy up #2/move all tests under tests/ #3)
• Waiting 90+ seconds past startup for the MCP sidecar to finish initializing

What works as workaround

Cloud-mode threads render fine. Local-mode is the only broken surface.

Hypothesis on root cause

The May 24 build appears to have introduced a Desktop ⇄ bundled-CLI version drift:

1. Renderer expects MCP-served plugin metadata to resolve tool-call items in rendered messages
2. MCP sidecar can't initialize because marketplace/add times out (looks like CLI doesn't recognize the request shape)
3. Without resolved plugin metadata, the renderer silently fails to paint message bodies — no user-facing error, the body area just stays empty
4. Underlying cause is likely that Desktop 26.519.41501 expects features only present in CLI 0.134.0+, but ships with 0.133.0-alpha.1 bundled — fix likely requires bundling CLI 0.134.0+ in Desktop

state_5.sqlite PRAGMA integrity_check returns ok — so this is not the DB-corruption shape that #20493 had.

Happy to share log slices, MCP transcript captures, or rollout samples if useful for triage.

[catink]

Update after further local testing:

I was able to confirm the apparent 50-conversation display window in Codex Desktop. After archiving/removing some currently visible conversations, previously missing conversations showed up again in the Desktop UI. This suggests the affected threads were not deleted locally; they were just outside the currently visible recent-conversation window.

I also found that conversations created by Codex automations count toward this same visible set. As a local workaround, I created a script that periodically archives automation-generated conversations after 72 hours, but only if I have not manually participated in that thread (has_user_event = 0). This helps prevent automation runs from occupying too many slots in the recent conversation list.

At the moment I have not found a better workaround other than regularly archiving/removing conversations that are no longer needed. A proper fix would likely be for Codex Desktop to paginate/load the full project history, or otherwise avoid letting automation-generated threads crowd out normal project conversations.

[wsy150728]

Another data point from macOS. This looks related to #20184, but in my case the custom provider was an OpenAI-compatible HTTP provider, not Azure.

Environment

• Codex Desktop: 26.519.81530 (CFBundleVersion 3178)
• Bundled CLI: codex-cli 0.133.0
• Platform: macOS arm64
• Local storage: ~/.codex/state_5.sqlite plus rollout JSONL files under ~/.codex/sessions / ~/.codex/archived_sessions

User-visible symptom

After adding a custom HTTP-only provider named openai_http and restarting Codex Desktop, multiple local project histories disappeared from the sidebar/project sections. Some projects showed No conversations even though their SQLite rows and rollout JSONL files still existed.

This looked like local Desktop history/index drift rather than data deletion.

Snapshot before repair attempts

A backup of state_5.sqlite taken before repair attempts showed:

PRAGMA integrity_check: ok

threads total: 303
archived threads: 145
threads with non-empty preview: 299
threads with non-empty first_user_message: 299

has_user_event distribution:
  0: 303

model_provider distribution:
  openai: 296
  openai_http: 7

Affected project-level rows were still present. Paths redacted:

<project-A>:       156 total, 68 active, 67 active with preview, 67 active with first_user_message, 0 active with has_user_event=1
<project-B>:       102 total, 72 active, 70 active with preview, 70 active with first_user_message, 0 active with has_user_event=1
<project-C>:        21 total, 12 active, 11 active with preview, 12 active with first_user_message, 0 active with has_user_event=1

The important part is that most rows still had preview and first_user_message, so this was not simply “all local thread content/title metadata is empty”. The rows were in SQLite and rollout files were still present, but Desktop did not surface them correctly.

Provider/config angle

The observed sequence was:

1. Add custom provider openai_http to ~/.codex/config.toml.
2. Set model_provider = "openai_http" while debugging a reconnect issue.
3. Restart Codex Desktop.
4. Project/sidebar history became missing/incomplete.

This may be related to provider filtering or a local state reindex/reconcile path after provider/config changes. It is similar to #20184 in that custom providers appear to make persisted local history unsafe or confusing, but this case used an OpenAI-compatible HTTP provider id (openai_http) rather than Azure.

Source-level observations

I inspected the public openai/codex source at current HEAD and the local bundled binary strings. The current Rust thread-list query appears to filter on threads.preview <> '', not directly on has_user_event. The current metadata upsert path also does not include has_user_event in the inserted/updated column set, while the schema still has:

has_user_event INTEGER NOT NULL DEFAULT 0

So I do not want to overstate has_user_event=0 as the sole cause. It is at least a strong drift signal in the bad state: every thread row had it set to 0 while user-facing preview metadata and rollout files still existed.

Expected behavior

• Changing or adding a provider should not make existing local project history disappear from Desktop.
• Desktop should be able to fully rebuild visible local history from state_5.sqlite plus rollout JSONL files.
• If session_index.jsonl, SQLite, provider filters, or renderer state disagree, there should be a supported repair/reindex command.
• Custom provider threads should remain visible under their original provider after restart, or Desktop should explicitly explain any provider-scoped filtering instead of looking like data loss.

Requested help

Please clarify which local source is authoritative for Desktop sidebar/project history:

• state_5.sqlite
• session_index.jsonl
• rollout JSONL files
• .codex-global-state.json
• an in-memory/electron persisted index

Also, is there a supported way to force a full local history reindex/backfill without manually editing SQLite or JSONL files?

I can provide redacted counts, schema output, or selected sanitized rows if useful.