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

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

• #23825
• #23966
• #23609
• #22796
• #22592

Powered by Codex Action

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

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

+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 #1 but not #2/#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.

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.

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.

Another macOS data point on Codex Desktop 26.519.81530 / bundled CLI 0.133.0.

This looks like the same local-history/sidebar indexing bug, but I want to add one important detail: refreshing updated_at, adding session_index.jsonl rows, toggling thread_source, and writing the sidebar/project assignment keys into .codex-global-state.json still did not restore the affected project threads.

Symptom

• A project sidebar shows only the current/recent recovery thread.
• Many older project threads are missing from the Desktop UI after restart.
• The missing threads still exist locally and are not archived.
• Opening/restarting the app after local repair attempts does not bring them back.

Environment

• Product: Codex Desktop
• Platform: macOS
• Desktop version: 26.519.81530
• Bundled CLI observed in session metadata: 0.133.0
• Local storage: ~/.codex/state_5.sqlite, ~/.codex/session_index.jsonl, rollout JSONL under ~/.codex/sessions/...

Local evidence

For one affected project root, ~/.codex/sessions has 255 session_meta rows matching the project cwd, and state_5.sqlite has 255 matching thread rows with archived=0.

Representative rows still present in state_5.sqlite:

id                                    title                         archived  thread_source  rollout_path exists
019e1f37-f41d-7092-a8a6-6133763ad522  <project thread>              0         NULL           yes
019dc7bd-6c69-7723-8df9-d98e15a2a1db  <project thread>              0         NULL           yes
019d7031-9c36-7592-9fdf-8ef5ce45eea6  <project thread>              0         NULL           yes
019d4812-87f3-7c33-a383-e8cde18d6264  <project thread>              0         NULL           yes

session_index.jsonl timestamp parse check is clean:

bad_count=0

The affected project path includes non-ASCII characters and spaces, redacted here as:

/Users/<user>/Desktop/<non-ascii>/3_tokflow-delivery

Workarounds attempted

The following were tried after backups, but the missing threads still did not show in the Desktop sidebar:

1. Updated updated_at / updated_at_ms for missing rows.
2. Appended refreshed entries to ~/.codex/session_index.jsonl.
3. Fixed one malformed session_index.jsonl timestamp (...03:21:53.6NZ -> valid ISO timestamp), then verified bad_count=0.
4. Tried setting old rows' thread_source to user.
5. Restored thread_source back to NULL to match another old thread that was visible in a different project.
6. Added/updated these .codex-global-state.json keys:

• projectless-thread-ids
• thread-workspace-root-hints
• thread-project-assignments
• sidebar-project-thread-orders
• sidebar-thread-metadata

1. Repeated the sidebar-state write after fully quitting Codex Desktop, then relaunched Codex.

None of the above restored the missing project threads.

Source inspection / hypothesis

I inspected the packaged Desktop renderer chunks from app.asar.

Relevant observations:

• Sidebar thread keys are formatted as local:<thread_id>.
• The sidebar code reads settings keys such as THREAD_PROJECT_ASSIGNMENTS, PROJECTLESS_THREAD_IDS, THREAD_WORKSPACE_ROOT_HINTS, and SIDEBAR_THREAD_METADATA.
• Project grouping appears to operate on the app-server conversation/task list first, then group those tasks by cwd/project roots.

So the current hypothesis is: if the app-server conversation list does not emit these valid local SQLite/session records, manually adding sidebar/project state is insufficient. The frontend never receives the missing local tasks to group/render.

What would help

Please provide either:

1. A supported "rebuild local history/sidebar index" command that fully backfills from state_5.sqlite + sessions/, or
2. A Desktop fix so project sidebar expansion queries/paginates all local threads for that cwd instead of only a recent/global app-server subset, or
3. Guidance on which local source is authoritative for Desktop UI: state_5.sqlite, session_index.jsonl, rollout JSONL, .codex-global-state.json, or another app-server cache.

I can provide redacted diagnostics privately if useful.

bump

I hit a very similar Codex Desktop update issue locally: old project sessions still existed in local storage, but the new UI did not show them in the project history/sidebar.

I documented the recovery workflow I used here:

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

It is an unofficial workaround, not an upstream fix. The workflow does a dry-run first and checks the local session index, global project/sidebar state, SQLite threads.cwd, exact cwd matching, and Windows \\?\ path mismatches. It creates timestamped backups before writing and verifies that the relevant missing_* counts are zero afterward.

This may be useful if state_5.sqlite and sessions/**/*.jsonl still contain the missing threads, but Codex Desktop no longer surfaces them after the update.

Same bug, new version: my reproduction recurs on Codex Desktop 26.527.31326 (bundled CLI 0.135.0-alpha.1) after auto-update today (May 31 10:04 local). The earlier May 26 comment was on 26.519.41501; the issue persists in 26.527.x without OpenAI shipping any visible fix.

What recurred

Local mode chat input is unusable, past conversation bodies render blank. Same identical log signature as before:

2026-05-31T14:13:14.567Z warning [AppServerConnection] Failed to start local app-server sidecar after app-server initialization
  errorMessage="Timed out waiting for MCP response to config/read" hostId=local

2026-05-31T14:13:15.325Z warning [BundledPluginsMarketplace] bundled_plugins_marketplace_add_failed
  errorMessage="Timed out waiting for MCP response to marketplace/add"
  marketplaceRoot=/Users/timsullivan/.codex/.tmp/bundled-marketplaces/openai-bundled

2026-05-31T14:13:33.306Z warning [electron-fetch-handler] Failed to check workspace dependencies feature for developer instructions
  errorMessage="Timed out waiting for MCP response to experimentalFeature/list"

Manually launching /Applications/Codex.app/Contents/Resources/node_repl with the full env from ~/.codex/config.toml immediately exits with:

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

ps -ef | grep node_repl shows zero processes after Codex startup — the sidecar never establishes.

A side effect on this version specifically

Right after the 26.527.31326 update, ~/.codex/.tmp/bundled-marketplaces/openai-bundled/ was missing several plugin asset PNGs/SVGs that exist in /Applications/Codex.app/Contents/Resources/plugins/openai-bundled/ (117 MB extracted vs 120 MB in app bundle). Many electron-message-handler … Failed to inline local image … ENOENT warnings followed:

ENOENT: no such file or directory, open '/Users/timsullivan/.codex/.tmp/bundled-marketplaces/openai-bundled/plugins/browser/assets/browser.png'
ENOENT … plugins/chrome/assets/google-chrome.png
ENOENT … plugins/chrome/assets/google-chrome-composer.png
ENOENT … plugins/latex/assets/latex-logo.svg
ENOENT … plugins/computer-use/assets/app-icon.png

I rsync'd the source bundle over the tmp extraction (which cleared the ENOENTs) but the MCP sidecar timeout still fires — so the missing assets were a symptom of incomplete extraction, not the cause of the timeout.

What's preserved across versions (the May 26 fix held)

• Workspace root in ~/.codex/.codex-global-state.json: canonical (Documents - Tim's Mac Studio/New project with the curly apostrophe)
• All 73 active threads' cwd in state_5.sqlite: canonical path, matching workspace root
• Zero Item not found in turn state errors today (that bug was resolved by quarantining the dangling-tool-call rollouts)

So the path-normalization bug from my last comment is fixed at the data layer — but the MCP sidecar timeout is a separate blocker that re-emerged on the new version with no workaround I've found.

Reproduction every time on 26.527.31326

1. Quit Codex
2. Clean /tmp/codex-browser-use/*.sock (15 stale ones accumulated from prior failed attempts)
3. Relaunch Codex
4. Within ~30s of launch: Failed to start local app-server sidecar after app-server initialization: Timed out waiting for MCP response to config/read
5. node_repl never appears in ps

Other users on this version

The thread now has 9 comments, several from the past week (@wangyaok1 May 29, @gregory-fanous May 30, @huajiexiewenfeng May 31 hours ago) reporting matching symptoms across 26.519.x builds. The new 26.527.x rollout hasn't fixed it — it's the same failure mode with the same log signature.

Could someone from the team confirm whether this is on the triage radar? Happy to provide:

• Full app-server log slice from launch through first timeout (~2 MB)
• node_repl stderr capture if there's a flag to enable it (I tried DEBUG=* and RUST_LOG=trace env vars without visible effect)
• ~/.codex/config.toml (sanitized) showing the [mcp_servers.node_repl] block

Local mode has been broken for me for ~5 days now. Cloud mode continues to work, so it's not blocking entirely — but flagging that the fix-rollout in 26.527 did not address this regression.

Cross-version confirmation: this bug is in every Codex Desktop version on the appcast feed.

After my comment a few hours ago, I tested every version listed in https://persistent.oaistatic.com/codex-app-prod/appcast.xml:

| Version | Build | Published | MCP sidecar timeout fires? |
|---|---|---|---|
| 26.527.31326 | 3390 | May 29 21:52 UTC | ✅ ~30s after launch |
| 26.527.30818 | 3370 | May 29 16:48 UTC | (implied — same family) |
| 26.519.81530 | 3178 | May 26 23:59 UTC | ✅ ~32s after launch |
| 26.519.41501 | 3044 | May 22 23:29 UTC | (had to work around it last week) |
| 26.519.31651 | 3017 | May 22 01:59 UTC | ✅ ~30s after launch |

That's every published version. Same identical log signature on each:

warning [AppServerConnection] Failed to start local app-server sidecar after app-server initialization
  errorMessage="Timed out waiting for MCP response to config/read"
warning [BundledPluginsMarketplace] bundled_plugins_marketplace_add_failed
  errorMessage="Timed out waiting for MCP response to marketplace/add"
warning [bundled-plugins] bundled_plugins_reconcile_failed reason=startup

ps -ef | grep node_repl shows zero processes on every version. Running /Applications/Codex.app/Contents/Resources/node_repl manually with the env from ~/.codex/config.toml exits immediately on every version:

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

What's different in 26.527.x specifically

On 26.519.x the renderer would silently degrade — the timeout fired but you could still type and submit (you just lost browser/computer-use plugins). My @sulmusic2-star May 26 workaround relied on this degradation path.

In 26.527.31326 the renderer now hard-blocks the composer until the permission dropdown resolves. Concretely:

• composer.permissionsDropdown.default.label (the "Default permissions" dropdown) stays in a perpetual loading state because it waits for marketplace-registered permission profiles to populate
• The send arrow stays disabled (grey) and clicking it shows "Unable to send message" → "loading"
• Past local-mode threads' message bodies don't render — the renderer waits on the same plugin metadata before painting

Cloud-mode in the same window works fine because cloud routes around the local app-server entirely.

Things I tried on 26.527.31326 that did not help

1. Fresh download of Codex.dmg from https://persistent.oaistatic.com/codex-app-prod/Codex.dmg → reinstalled cleanly → bug persists
2. rm -rf ~/.codex/.tmp ~/.codex/plugins/cache → relaunch (Codex re-extracts) → bug persists
3. Cleaning /tmp/codex-browser-use/*.sock (15+ stale sockets accumulate per session) → bug persists
4. Commenting out [mcp_servers.node_repl] in ~/.codex/config.toml → renderer still hangs on permission dropdown (so the sidecar block isn't tied only to node_repl being declared as an MCP server)
5. rsync -a /Applications/Codex.app/Contents/Resources/plugins/openai-bundled/ ~/.codex/.tmp/bundled-marketplaces/openai-bundled/ (the tmp extraction was missing ~3MB of plugin assets right after auto-update) → cleared the ENOENT warnings but did not clear the MCP timeout
6. Downgrading via Sparkle zip URLs back to 26.519.31651 → bug persists

Local data is healthy

Verified across all reinstalls — these are all intact and matching:

• ~/.codex/.codex-global-state.json workspace root: canonical macOS path with curly apostrophe
• state_5.sqlite all 73 active threads' cwd: same canonical path
• state_5.sqlite PRAGMA integrity_check: ok
• has_user_event=1 for 80/81 threads
• Auth: ChatGPT mode, tokens fresh (refreshed today)
• Disk: 52 GB free
• Bundled marketplace dir: 117 MB extracted, plugins present (browser, chrome, computer-use, latex)

So the bug isn't in user data, isn't auth, isn't disk, isn't config, isn't paths. It's in the bundled node_repl MCP server failing to respond to its initialize handshake — which then cascades to marketplace-registration timeout, permission-profile load failure, and a fully blocked composer.

What would help

This thread has six independent reports now (myself x2, @chenjxpp, @justalmostgreat, @wangyaok1, @gregory-fanous, @huajiexiewenfeng) since May 22, no OpenAI response. Could someone from the Codex team confirm this is on the radar? A working node_repl build, even as a separate download, would unblock all of us — every other piece of the local stack works.

Currently on cloud mode as the only workaround. Auto-update disabled (defaults write com.openai.codex SUAutomaticallyUpdate -bool false) to avoid further regressions.

我今天也遇到了类似的问题，让Codex进行了解决，有需要的可以参考

中文版

问题概述

Codex Desktop 侧边栏历史对话展示不完整。历史线程数据仍存在于本地线程数据库中，但侧边栏项目分组只展示部分最近线程，导致大量旧线程在 UI 中缺失。

影响范围

• 影响位置：Codex Desktop 侧边栏的项目分组与历史对话列表
• 影响对象：本地未归档线程
• 数据状态：线程数据仍在本地数据库中
• 展示状态：侧边栏只加载并展示最近一部分线程
• 已归档线程：继续按产品逻辑隐藏

复现现象

1. 打开 Codex Desktop。
2. 查看左侧侧边栏的项目分组。
3. 展开项目分组后，只能看到部分历史对话。
4. 通过本地线程查询接口或数据库检查，可以确认更多旧线程仍然存在。
5. 重启客户端后，缺失线程仍然无法完整展示。

根因分析

侧边栏初始化时只执行一次 recent threads 拉取：

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

其中 recentConversationPageCount 默认值为 1，初始加载只覆盖首批最近线程。项目分组依赖已经加载到内存的线程生成，因此分页之外的线程虽然存在于本地数据库，也无法进入侧边栏分组。

代码中存在 loadMoreRecentConversations() 分页加载逻辑，但当前侧边栏初始化流程没有稳定触发完整分页加载。

诊断结果

脱敏后的本地检查结果：

• 未归档本地 Codex 线程：约 <UNARCHIVED_THREAD_COUNT> 条
• 已归档线程：约 <ARCHIVED_THREAD_COUNT> 条
• 项目线程映射：约 <PROJECT_ASSIGNMENT_COUNT> 条
• 首批 recent threads：只覆盖最近一部分线程
• 分页之外线程：数据存在，侧边栏初始化未加载

涉及的本地路径与项目名已脱敏：

• 用户目录：<USER_HOME>
• Codex 状态目录：<CODEX_STATE_DIR>
• 项目路径：<PROJECT_ROOT_A>, <PROJECT_ROOT_B>, <PROJECT_ROOT_C>
• 线程 ID：<THREAD_ID>

本地修复方案

将侧边栏初始刷新逻辑改为使用已有的完整分页接口：

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

该方式让侧边栏启动时加载完整未归档线程列表，再交给项目分组逻辑渲染。

同时完成了本地状态修复：

• 修复空 thread_source 字段
• 恢复 thread-project-assignments
• 保持非目标工作区线程不变
• 保持已归档线程隐藏逻辑不变

推荐产品修复

在源码层面调整 runRecentConversationRefresh，让侧边栏初始化使用完整分页加载：

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

可选方案：

while (this.hasMoreRecentConversations()) {
  await this.loadMoreRecentConversations()
}

推荐采用 listAllThreads 路径，逻辑更直接，且复用现有完整分页实现。

建议附带的补丁

建议提交源码级补丁。不要提交本地 app.asar 二进制文件，也不要提交任何包含用户名、真实项目路径、线程 ID 的备份文件。

源码级补丁建议：

 async runRecentConversationRefresh(sortKey) {
   this.params.dispatchMessageToView({
     type: "invalidate-thread-search",
     hostId: this.params.hostId,
   })
   await this.loadThreadHydrationState()
   this.recentConversationSortKey = sortKey
-  let page = await this.listRecentThreads({
-    limit: 50 * this.recentConversationPageCount,
-    cursor: null,
-  })
+  let page = {
+    data: await this.listAllThreads({ modelProviders: null }),
+    nextCursor: null,
+  }
   this.fetchedRecentConversations = true
   this.nextRecentConversationCursor = page.nextCursor
   // Existing recentConversationIds rebuild logic remains unchanged.
 }

如果产品希望保留分页语义，也可以使用循环加载：

let firstPage = await this.listRecentThreads({
  limit: 50,
  cursor: null,
})

let data = [...firstPage.data]
let cursor = firstPage.nextCursor

while (cursor != null) {
  let page = await this.listRecentThreads({
    limit: 50,
    cursor,
  })
  data.push(...page.data)
  cursor = page.nextCursor
}

let page = {
  data,
  nextCursor: null,
}

临时本地热修

仅在无法修改源码、需要先恢复本机侧边栏时使用。该方式会修改本地安装包资源，客户端更新会覆盖修改。

热修目标：

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

替换为：

{
  data: await this.listAllThreads({ modelProviders: null }),
  nextCursor: null
}

本地热修必须满足：

• 修改前备份原始资源文件
• 替换后确认旧表达式数量为 0
• 替换后确认新表达式数量为 1
• 重启 Codex Desktop 后验证侧边栏
• 出现启动异常时恢复备份

本地状态修复脚本要点

如果线程数据存在但仍然无法进入侧边栏，可检查本地线程元数据。

需要检查的字段：

select archived, thread_source, count(*)
from threads
where cwd not like '<EXCLUDED_WORKSPACE_PREFIX>%'
group by archived, thread_source
order by archived, thread_source;

空 thread_source 的修复逻辑：

update threads
set thread_source = 'user'
where archived = 0
  and (thread_source is null or thread_source = '')
  and source = 'vscode';

子线程来源修复逻辑：

update threads
set thread_source = 'subagent'
where archived = 0
  and (thread_source is null or thread_source = '')
  and source like '{"subagent":%';

项目映射也需要确认：

thread-project-assignments should contain mappings for all project threads.
projectless-thread-ids should contain projectless local threads.

这些状态修复属于辅助步骤。核心产品 bug 仍然是侧边栏初始化没有完整加载未归档线程。

验证标准

修复后应满足：

• 侧边栏项目分组能够展示所有未归档本地线程
• 旧线程可在对应项目分组中出现
• 已归档线程继续隐藏
• 搜索功能仍可命中历史线程
• 项目分组数量与本地线程数据库统计一致

提交摘要

Suggested commit message:

Fix sidebar history hydration to load all unarchived threads

Suggested GitHub issue title:

Sidebar project groups only show first page of recent threads

---

English Version

Issue Summary

Codex Desktop sidebar does not display the full conversation history. The historical thread records still exist in the local thread database, while the sidebar project groups only show a subset of recent threads. As a result, many older conversations are missing from the UI.

Impact

• Affected area: Codex Desktop sidebar project groups and conversation history
• Affected data: local unarchived threads
• Data status: thread records remain present in the local database
• UI status: sidebar loads and renders only a recent subset
• Archived threads: still hidden according to product behavior

Reproduction

1. Open Codex Desktop.
2. Inspect the left sidebar project groups.
3. Expand a project group.
4. Only a subset of historical conversations appears.
5. Local thread queries or database checks confirm that additional older threads still exist.
6. Restarting the client does not fully restore the missing sidebar entries.

Root Cause

During sidebar initialization, recent threads are fetched once:

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

recentConversationPageCount defaults to 1, so the initial load only covers the first recent page. Project groups are built from the threads already loaded into memory. Threads outside that first page remain present in the local database, yet they never enter the sidebar grouping pipeline.

The codebase already contains loadMoreRecentConversations() for paginated loading, but the sidebar initialization path does not reliably trigger full pagination.

Diagnostic Findings

Redacted local findings:

• Unarchived local Codex threads: approximately <UNARCHIVED_THREAD_COUNT>
• Archived threads: approximately <ARCHIVED_THREAD_COUNT>
• Project thread assignments: approximately <PROJECT_ASSIGNMENT_COUNT>
• First recent page: covers only the latest subset
• Threads outside the first page: present in data storage, absent from initial sidebar hydration

Redacted local identifiers:

• User home directory: <USER_HOME>
• Codex state directory: <CODEX_STATE_DIR>
• Project roots: <PROJECT_ROOT_A>, <PROJECT_ROOT_B>, <PROJECT_ROOT_C>
• Thread IDs: <THREAD_ID>

Local Hotfix

Update the sidebar initial refresh path to use the existing full pagination helper:

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

This lets the sidebar load the full unarchived thread list at startup before rendering project groups.

Additional local state repairs:

• Filled empty thread_source values
• Restored thread-project-assignments
• Preserved unrelated workspace threads
• Preserved archived-thread hiding behavior

Recommended Product Fix

Update runRecentConversationRefresh to hydrate all unarchived threads through the existing full pagination path:

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

Alternative implementation:

while (this.hasMoreRecentConversations()) {
  await this.loadMoreRecentConversations()
}

The listAllThreads approach is the preferred fix because it is direct and reuses the existing full pagination implementation.

Patch To Attach

Attach the source-level patch. Do not attach a local app.asar binary, and do not attach backups containing real usernames, project paths, or thread IDs.

Recommended source-level patch:

 async runRecentConversationRefresh(sortKey) {
   this.params.dispatchMessageToView({
     type: "invalidate-thread-search",
     hostId: this.params.hostId,
   })
   await this.loadThreadHydrationState()
   this.recentConversationSortKey = sortKey
-  let page = await this.listRecentThreads({
-    limit: 50 * this.recentConversationPageCount,
-    cursor: null,
-  })
+  let page = {
+    data: await this.listAllThreads({ modelProviders: null }),
+    nextCursor: null,
+  }
   this.fetchedRecentConversations = true
   this.nextRecentConversationCursor = page.nextCursor
   // Keep the existing recentConversationIds rebuild logic unchanged.
 }

If the product needs to preserve explicit pagination semantics, use a loop:

let firstPage = await this.listRecentThreads({
  limit: 50,
  cursor: null,
})

let data = [...firstPage.data]
let cursor = firstPage.nextCursor

while (cursor != null) {
  let page = await this.listRecentThreads({
    limit: 50,
    cursor,
  })
  data.push(...page.data)
  cursor = page.nextCursor
}

let page = {
  data,
  nextCursor: null,
}

Temporary Local Hotfix

Use this only when source changes are unavailable and the local sidebar needs immediate recovery. This modifies local app resources and may be overwritten by a client update.

Hotfix target:

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

Replacement:

{
  data: await this.listAllThreads({ modelProviders: null }),
  nextCursor: null
}

Local hotfix requirements:

• Back up the original resource file before editing
• Confirm the old expression count is 0 after replacement
• Confirm the new expression count is 1 after replacement
• Restart Codex Desktop and verify the sidebar
• Restore the backup if startup fails

Local State Repair Notes

If thread records exist but still do not appear in the sidebar, inspect local thread metadata.

Check source metadata:

select archived, thread_source, count(*)
from threads
where cwd not like '<EXCLUDED_WORKSPACE_PREFIX>%'
group by archived, thread_source
order by archived, thread_source;

Repair empty user thread sources:

update threads
set thread_source = 'user'
where archived = 0
  and (thread_source is null or thread_source = '')
  and source = 'vscode';

Repair empty subagent thread sources:

update threads
set thread_source = 'subagent'
where archived = 0
  and (thread_source is null or thread_source = '')
  and source like '{"subagent":%';

Project mapping should also be checked:

thread-project-assignments should contain mappings for all project threads.
projectless-thread-ids should contain projectless local threads.

These state repairs are supporting steps. The core product bug is the sidebar initialization path failing to hydrate all unarchived threads.

Verification Criteria

After the fix:

• Sidebar project groups show all unarchived local threads
• Older conversations appear under their corresponding project groups
• Archived conversations remain hidden
• Search still finds historical threads
• Project group counts match local thread database counts

Submission Summary

Suggested commit message:

Fix sidebar history hydration to load all unarchived threads

Suggested GitHub issue title:

Sidebar project groups only show first page of recent threads

Thanks @Ten-xu — that's a solid diagnosis and fix, but I want to flag for maintainers that this thread now contains two distinct bugs, and @Ten-xu's fix only addresses one of them. They shouldn't be closed together.

Bug A — missing sidebar history (this issue's title)

• Symptom: older unarchived threads exist in state_5.sqlite + sessions/** but don't appear in the Desktop sidebar project groups.
• Root cause (per @Ten-xu): sidebar init calls listRecentThreads({ limit: 50 × recentConversationPageCount, cursor: null }) once with recentConversationPageCount = 1, so only the first page hydrates; project grouping only uses in-memory threads.
• Fix: switch the init path to listAllThreads({ modelProviders: null }). This looks correct for Bug A.

Bug B — local app-server MCP sidecar handshake timeout (different bug, NOT fixed by the pagination patch)

Several of us on macOS (26.519.x → 26.527.x) have a different failure: local mode can't send at all — the composer's permission ("Full access") control never resolves out of its loading state, and the send arrow spins forever. Cloud mode works. Renderer log signature:

warning [AppServerConnection] Failed to start local app-server sidecar after app-server initialization
  errorMessage="Timed out waiting for MCP response to config/read"
warning [BundledPluginsMarketplace] bundled_plugins_marketplace_add_failed
  errorMessage="Timed out waiting for MCP response to marketplace/add"

This is gated on the MCP sidecar startup, not on thread pagination, so listAllThreads does not touch it. Evidence it's a separate, app-server-side defect (gathered with RUST_LOG=trace on the bundled app-server):

• node_repl (the sidecar binary) is healthy. Driven directly over stdio it answers initialize in <1s and executes a real js tool call (spawning its Node kernel) in ~0.25s, returning valid results — both sandboxed and with --disable-sandbox. Inside the app-server's own list_all_tools trace it also returns its 3 tools.
• The app-server spawns node_repl (stdio pipes + unix sockets all connected, verified via lsof), then tears it down ~2–3s later while still waiting the full 31s for its config/read/marketplace/add response.
• The app-server aggregates tools across all local MCP servers (list_all_tools{mcp_server_count=N}) before the composer's permission control resolves; if that aggregation/handshake doesn't complete, the chip never settles and local send stays disabled.
• Reproducible from a 100%-clean state (all Codex processes killed, caches/sockets cleared, single launch) and on every published build on the appcast. It's intermittent across identical builds — a launch on May 31 succeeded with marketplace_added firing 5 ms after marketplace_written; subsequent launches on the same binary fail.
• codex exec from the terminal (same machine, same ~/.codex/auth.json) runs local prompts fine, and cloud mode works — isolating the fault to the Desktop app-server's local sidecar lifecycle, not auth/CLI/model/network.

Request to maintainers: please keep Bug B open and route it to whoever owns the Desktop local app-server / node_repl / app-server --listen stdio:// sidecar wiring, even if @Ten-xu's pagination fix lands for Bug A. They have different root causes. Happy to provide a RUST_LOG=trace app-server log slice from a failing launch, lsof/codesign output, or the node_repl stdio-handshake repro on request. (Also filed via OpenAI support case 09438125.)

I can add one more macOS datapoint that narrows the bug down further.

Environment:

• Codex Desktop observed on this machine: 26.519.22136
• Platform: macOS arm64
• Local storage under ~/.codex

What I verified locally:

1. The missing project chats were still present in:

• state_5.sqlite
• sessions/**/rollout-*.jsonl
• session_index.jsonl

1. A one-time local state repair does restore the broken association layer:

• projectless-thread-ids: 71 -> 0
• thread-workspace-root-hints: 71 -> 0
• exact saved/project roots: 21 -> 104
• missing session_index.jsonl entries: 19 -> 0

1. However, while Codex Desktop was still running, .codex-global-state.json later reverted by itself back to the broken shape:

• saved workspace roots: 105 -> 22
• project order entries: 105 -> 17
• projectless-thread-ids: 0 -> 71
• thread-workspace-root-hints: 0 -> 71

So at least on this machine, this is not just a one-off stale file. The running Desktop app appears able to re-write the old broken global state back to disk from in-memory state or another internal cache.

That means a one-time local repair is not durable by itself.

Additional observation:

• The global recent-window symptom is also real here. With 238 active threads, the top recent window only covered 13-14 distinct cwd values. After bumping a hidden project's latest thread into the recent set, that project immediately entered the modeled recent window.
• In other words, there are two overlapping problems:

1. broken project/thread association state
2. project visibility tied to a small global recent-thread window

Temporary local workaround I ended up using:

• repair .codex-global-state.json and session_index.jsonl
• then run a file-watching local watchdog that re-applies the repair whenever .codex-global-state.json changes again
• optionally “surface” a specific old project by bumping its latest thread metadata into the recent window

I packaged that recovery flow here in case it helps others reproduce/debug:

• https://github.com/Stephen-creater/codex-desktop-session-recovery-skill

The new bit that may be useful to maintainers is the live regression behavior: Desktop can restore the bad state back onto disk after a successful repair, so the authoritative bug may be in the running app's state hydration / persistence layer, not only in a one-time migration.

Follow-up from the macOS data point I posted earlier.

This is still impacting a real production project, and the local evidence continues to indicate "UI/sidebar discovery failure" rather than deleted data.

Current affected project snapshot:

• Platform: macOS
• Codex Desktop: 26.519.81530
• Affected project has 255 local project sessions / SQLite thread rows.
• Matching state_5.sqlite rows have archived=0.
• Matching rollout JSONL files still exist under ~/.codex/sessions/....
• session_index.jsonl timestamp parsing is now clean (bad_count=0).

Recovery attempts that did not restore the Desktop sidebar:

• bumped updated_at / updated_at_ms
• appended/refreshed session_index.jsonl
• toggled old rows' thread_source between user and NULL
• wrote sidebar/project state keys such as:
• thread-workspace-root-hints
• thread-project-assignments
• sidebar-project-thread-orders
• projectless-thread-ids
• repeated global-state writes after quitting/restarting Codex Desktop

I also dry-ran the community codex-session-recovery workflow. It found:

exact_project_sessions: 255
sqlite_project_threads: 255
missing_from_session_index: 59
missing_global_hints: 255
missing_project_assignments: 255
missing_sidebar_order: 255

But on macOS that script does not detect running Codex processes, and in this case manual global-state repair has already proven non-durable. So I am not comfortable using write-mode or a watchdog workaround against a live production ~/.codex.

Could someone from the Codex team confirm whether this is on the triage radar?

The two concrete product asks are:

1. Fix the sidebar/project hydration path so it does not build project groups only from the first global recent thread window.
2. Provide a supported "rebuild local sidebar/thread index" command from durable local state (state_5.sqlite + sessions/**/*.jsonl), so users do not need to patch app.asar or manually edit SQLite/global-state files.

Happy to provide more redacted diagnostics if useful.

Follow-up: this appears to still be active across newer Desktop builds, and the number of duplicate reports is increasing.

Recent related reports I noticed:

• #20741: users still report only the most recent ~50 threads showing in Codex Desktop 26.601.21317.
• #17540: Windows user reports the same class of issue on Microsoft Store package OpenAI.Codex_26.602.4764.0_x64__2p2nqsd0c76g0; local state exists, but Desktop sidebar/search still omits older project conversations.
• #25463: macOS reports where search can find older local threads, but opening them results in a blank/loading conversation view even though JSONL/session data remains readable.
• #26634: duplicate detector is now pointing to multiple similar issues (#25463, #25574, #26157, #25761, #26031), which suggests this is affecting a broader set of users rather than one local corruption case.

For my affected macOS project, the situation remains unchanged: the missing project threads still exist locally in ~/.codex/sessions and state_5.sqlite, but Codex Desktop does not hydrate them back into the project sidebar after restart. Manual global-state/sidebar edits were not durable because Desktop rewrote the state on launch.

Request for maintainers:

1. Please confirm whether this is tracked internally as a Desktop sidebar/project-history hydration bug.
2. Please consider changing project/sidebar hydration so it is not bounded by the first global recent-thread window.
3. Please provide a supported local repair/reindex command, for example something that rebuilds project/thread sidebar metadata from state_5.sqlite and session JSONL files without patching the app bundle.

Several community workarounds now involve patching/rebuilding the Desktop app or mutating local state. Those are risky for production users, so an official recovery path would help a lot.

This is really getting in the way of my codex workflow and causes substantial productivity drop especially because the workarounds mentioned are risky to use for me. So Codex team please plan a fix for this soon

If you access codex through terminal and have it audit the problem, it can disable what may be causing it like computer use or browser use, not sure what it exactly is and codex will work again without those features.

I hit a very similar issue on macOS with Codex Desktop 26.602.71036, but was able to narrow down one concrete root cause and a working local recovery path.

Symptom

Several older local project threads disappeared from the Desktop sidebar and in-app search, while the underlying local data was still present:

• ~/.codex/sessions/**/rollout-*.jsonl files existed.
• ~/.codex/state_5.sqlite still had matching threads rows.
• ~/.codex/session_index.jsonl could be rebuilt and contained the missing thread IDs.
• .codex-global-state.json could be updated with correct thread-workspace-root-hints, but that alone did not restore visibility.
• Resetting ~/Library/Application Support/Codex did not restore visibility.

Key finding

For the missing older threads, the first JSONL line, session_meta.payload.model_provider, used lowercase:

"model_provider":"openai"

Visible newer threads used:

"model_provider":"OpenAI"

Only updating state_5.sqlite was not enough. On app startup, Codex appeared to re-sync thread metadata from the rollout JSONL session_meta header and changed the SQLite row back to the lowercase provider value.

Minimal reproduction / validation

For one missing thread:

1. Backed up state_5.sqlite and the target rollout JSONL file.
2. Updated the first line of the rollout JSONL file:

"source":"vscode",
"model_provider":"OpenAI"

1. Updated the matching SQLite row:

UPDATE threads
SET source = 'vscode', model_provider = 'OpenAI'
WHERE id = '<thread_id>';

1. Relaunched Codex Desktop.

That specific hidden thread reappeared in the project sidebar. After applying the same normalized model_provider='OpenAI' fix to the remaining affected non-archived user threads and their rollout JSONL headers, the missing project conversations came back.

Additional observations

The affected rows matched roughly:

SELECT id, source, model_provider, cwd, title
FROM threads
WHERE archived = 0
  AND thread_source = 'user'
  AND model_provider = 'openai';

In my case, all remaining affected rows were valid user threads. After synchronizing both SQLite and JSONL session_meta, the lowercase-provider count became zero and the Desktop UI showed the conversations again.

Suggested fix area

The migration / thread-listing layer probably should normalize provider IDs case-insensitively, or migrate old local rollout session_meta.payload.model_provider values from openai to OpenAI without causing those threads to be filtered out of the Desktop UI/search.

A supported recovery command would also help, e.g. something that rebuilds state_5.sqlite, session_index.jsonl, and workspace hints from rollout JSONL while normalizing provider/source metadata safely.

I am not attaching raw DB/JSONL files because they contain private conversation content and local paths, but the above was enough to reproduce and repair the issue locally.

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.

@wangyaok1 I also noticed the same results after the latest update. A partial recovery, but still several older projects with a lot of work performed still show "No chats".

Just happened to me this morning after I clicked 'Update' in the app and it restarted So this is still happening.

Product:
Codex Desktop app

Platform:
macOS

What happened:
After restarting Codex Desktop, part of an existing thread’s visible chat history was missing. The current thread continued, but earlier messages from the same day were no longer available to the assistant/context. I did not manually delete/archive the thread.

Impact:
I lost important conversation context and could not provide screenshots because I only noticed after restart.

Expected:
Restart should preserve full visible thread history or clearly indicate if context was compacted. Local UI thread history should not disappear.

I am seeing what appears to be the same class of issue after a recent Codex Desktop update: local thread data still exists, but the Desktop sidebar/project history UI shows no chats/projects except the currently resumed conversation.

Environment:

• macOS: 26.5.1 (25F80)
• Codex Desktop: 26.623.42026 (bundle version 4514)
• Current session metadata shows cli_version: 0.142.3
• App process version path includes Chromium 149.0.7827.197

Observed behavior:

• After restarting Codex Desktop, the current thread can be resumed and continued.
• All other directories/project histories disappear from the UI/sidebar.
• Recent conversations from the last several days are not visible in the UI.
• The underlying local data is still present.

Local data checks:

~/.codex/state_5.sqlite integrity_check = ok
threads total = 331
active = 229
archived = 102
latest updated_at = 2026-06-27 16:34:59 local time

Recent threads are present in ~/.codex/state_5.sqlite and corresponding rollout JSONL files exist under ~/.codex/sessions/2026/06/.... Example IDs/titles from the DB:

019f0802-9061-7582-beed-6cac9cbc49c1  current thread, resumes successfully
019f0020-19b2-70d0-a685-f55a4e7f2aaf  recent project thread, not visible in UI
019f06c7-c1c2-78a3-b972-8633e688834f  recent project thread, not visible in UI
019efff4-ac0f-7d62-8d71-ca1d732c5eb7  recent project thread, not visible in UI

~/.codex/sessions and ~/.codex/archived_sessions also still contain the raw rollout files. I created local backups before trying any workaround.

Additional diagnostics:

• There is an older migrated DB at ~/.codex/sqlite/state_5.sqlite whose latest thread timestamp is stale, but the newer root DB ~/.codex/state_5.sqlite is current and contains the missing threads.
• ~/.codex/sqlite/codex-dev.db had local_thread_catalog = 0 rows after restart while state_5.sqlite had hundreds of threads.
• I manually backfilled local_thread_catalog from ~/.codex/state_5.sqlite to 228 active rows and set initial_build_complete = 1; integrity check passed, but the Desktop UI still did not restore the missing histories.
• The catalog remained populated after restart, so the UI either ignores it, reads another source, or is blocked elsewhere.
• There is also some path split in the data: older project records use a symlink path, while newer records use the resolved realpath. However the issue affects more than one project, so it does not appear to be only a single-project path grouping issue.

Potentially related but may be a separate problem: chatgpt.com/backend-api/conversations?offset=0&limit=1 currently returns HTTP/2 403 with cf-mitigated: challenge from this network. Model/current-thread traffic still works. This may explain why the app cannot repopulate from remote history, but it does not explain why local state_5.sqlite/rollout threads are not shown.

Expected behavior:

• Codex Desktop should show local project/thread history from the current local state database and rollout files, or at least provide a recovery/reindex path when local data exists but the sidebar/catalog is empty.

Happy to provide additional schema counts or logs if helpful. I avoided attaching full rollout files because they contain private conversation content.

Reproduced on a newer macOS build with additional catalog-level evidence.

Environment

• ChatGPT/Codex desktop: 26.707.62119 (CFBundleVersion 5211)
• Bundled Codex CLI/app-server: 0.144.2
• macOS: 26.5.2
• Apple M2 Max
• Reproduced repeatedly on 2026-07-13 (Asia/Dubai)

Symptom

Assigned project tasks appear in the sidebar for roughly one second after launch, then disappear and affected projects show No tasks. The same thing happens after every full quit/relaunch.

The earlier config.toml custom-provider error was repaired; this failure reproduces independently.

Data integrity and catalog evidence

Both local SQLite databases return PRAGMA integrity_check = ok. No authoritative task rows were deleted.

Running the installed app-server read-only against a snapshot, using the desktop catalog's startup thread/list query shape, returns all 60 eligible unarchived top-level tasks in one page:

{
  "listedEligibleTasks": 60,
  "pages": 1,
  "nextCursor": null
}

At the same time, the live derived sidebar catalog contains only 23 visible tasks and never records a completed initial build:

{
  "visibleCatalogTasks": 23,
  "watermarkUpdatedAt": null,
  "initialBuildComplete": 0,
  "observationSequence": 575,
  "catalogRevision": 78
}

Project-assignment restoration cannot fix visibility by itself because grouping operates only on task IDs already present in the derived catalog.

Mechanism observed in the shipped app

The shipped renderer uses feature gate 567837310 to select the discovery limit. The persistent-catalog path uses 50; only an explicitly false gate uses the prior 500-task fallback. A routine refresh then clears the broader thread summaries when the effective limit is 50.

The startup catalog service schedules a full sync after five seconds and should complete this dataset in one page, but the catalog remains at initialBuildComplete=0 with a null watermark across relaunches. This explains the visible flash followed by disappearance: startup briefly renders broader state, then the incomplete derived catalog replaces it.

Requested product fix

1. Fail open to the 500-task history until the persistent catalog reports complete.
2. Do not clear broader summaries while the replacement catalog is incomplete or unavailable.
3. Surface catalog-sync errors/readiness and provide a supported Rebuild task catalog action.
4. Roll back/gate the 50-item path for affected builds until readiness handling is fixed.
5. Preserve project assignments through catalog migrations.

A schema-guarded reconstruction of only the derived catalog was tested twice on cloned databases: 23 → 60 visible rows, watermark/completion set atomically, integrity remained ok, and a second run was idempotent. The authoritative task database was never written.

Raw logs/databases were not attached because they contain private task, client, and repository metadata. A secure upload route can be used if maintainers need them.