›_ Codex Issues
Codex Issues / #38832

[Desktop latest] Task/thread search and listing intermittently hang across multiple machines

Open 💬 3 comments Opened Aug 16, 2026 by GirthTender

What version of the Codex App are you using (From “About Codex” dialog)?

Locally verified on this MacBook today:

  • ChatGPT desktop app 26.810.52044
  • build 6662
  • bundled Codex CLI 0.148.0-alpha.9

The same symptom is being seen on every machine currently running the latest desktop app available as of August 16, 2026. I did not capture the exact About-box values from the other machines before filing this public report.

What subscription do you have?

Not provided.

What platform is your computer?

Cross-machine report:

  • macOS on Apple silicon (locally verified)
  • at least one Windows desktop host (user-reported)

This does not appear tied to one repository, one task, or one host.

What issue are you seeing?

In the latest ChatGPT desktop app / Codex desktop experience, major task/thread search and listing can hang instead of returning results.

User-facing surfaces affected include:

  • searching past tasks/threads/chats
  • browsing/listing major task history / Recents / thread lists
  • reopening or locating prior work through those list/search surfaces

The problem is significant because it blocks access to existing work history rather than only slowing down one active thread.

The important point here is cross-machine scope: the same failure mode is happening on multiple latest-version desktop installs, so this does not look like a one-off corrupt local database on one machine.

Local inspection performed on the MacBook

I did a narrow local inspection on the currently affected MacBook before filing:

  • ~/.codex/state_5.sqlite integrity check: ok
  • ~/.codex/logs_2.sqlite integrity check: ok
  • ~/.codex/goals_1.sqlite integrity check: ok

So the inspected local SQLite state is structurally healthy.

Today’s desktop log (~/Library/Logs/com.openai.codex/2026/08/16/...) also shows many successful fast thread/list RPC completions, for example durations around 2-21 ms in several places. At the same time, the same log contains repeated renderer-side errors such as:

  • Received turn/started for unknown conversation
  • Received turn/completed for unknown conversation

That combination suggests the durable local state and the underlying app-server list path can be healthy while the desktop UI / bridge / renderer still gets into an inconsistent thread state.

I am intentionally not attaching raw logs publicly because they contain private local paths, task identifiers, and conversation metadata.

What steps can reproduce the bug?

  1. Open the latest ChatGPT desktop app and switch to Codex.
  2. Use the app long enough to accumulate a meaningful set of current and historical tasks/threads.
  3. Try to find prior work through task/thread search or the normal major thread/task listing surfaces.
  4. Observe intermittent hangs or non-returning search/list behavior instead of a bounded result or explicit error.
  5. Repeat the same workflow on another machine running the latest desktop app.
  6. Observe that the same class of failure occurs there as well.

Representative user actions include both search-driven access and ordinary thread/task list browsing.

What is the expected behavior?

Task/thread search and list surfaces should:

  • return promptly with results, or
  • fail promptly with a clear actionable error

They should not hang indefinitely or become unusable across multiple latest-version desktop installs.

Additional information

I searched existing open issues before filing. The closest related reports I found include:

  • #37668 - desktop thread tools hang before reaching AppServerConnection
  • #35030 - scheduled runs hang on list_threads
  • #36412 - remote SSH thread-management RPCs hang while app-server stays healthy
  • #36828 - long thread opens on the wrong/history portion despite successful pagination
  • #25084 - desktop hides active project chat history while local threads remain on disk

Those look related, but this report is narrower and current: latest desktop build, cross-machine, user-facing task/thread search and listing hang.

If maintainers want private follow-up, I can provide redacted log excerpts and exact affected task identifiers through an OpenAI-controlled support or in-app feedback channel rather than a public GitHub thread.

View original on GitHub ↗

3 Comments

mrybicki-enmark · 9 days ago

Windows reproduction on current Codex desktop:

  • App package: OpenAI.Codex 26.814.5167.0
  • A fresh, normal All Repos task—not created from Voice—called list_threads({ limit: 20 }) once.
  • The call produced no result or user-facing error after 62 seconds and was cancelled without retrying.
  • Read-only local checks were healthy at the same time:
  • state_5.sqlite opened successfully;
  • PRAGMA quick_check returned ok;
  • the threads table contained 213 rows;
  • session_index.jsonl contained the new diagnostic task.

This rules out a Voice-only failure and suggests the agent-facing task-list bridge can hang while durable local task state remains accessible. In the same app session, a Voice-failed task later remained visible but could not be archived because its thread record could not be found.

brokemac79 · 8 days ago

Additional Windows reproduction and bounded recovery evidence from 2026-08-19:

  • Codex Desktop package: 26.814.5517 on Windows.
  • list_threads(limit=5|20) does not return within 30–60 seconds. list_projects and read_thread also fail to return, while ordinary chat and direct thread mutations remain responsive.
  • Multiple full app restarts did not recover the inventory path.
  • Local SQLite integrity checks remained ok.
  • We found 247 active catalog rows where very large execution prompts had been duplicated into both title and preview. A guarded metadata-only repair reduced active catalog metadata from about 72 MB to about 1 MB, with no rollout/conversation files modified.
  • We also found and reversibly archived 341 unnamed, unindexed active catalog rows whose rollout files no longer existed, leaving zero active missing-rollout rows.
  • Before each repair, coherent SQLite/recovery backups were created. After each repair, integrity remained ok.
  • We separately archived 216 known duplicate automation-run tasks by exact human-visible title and changed the surviving recurring automation to archive its own completed run tasks.
  • After a final clean restart against the compacted, internally consistent catalog, task/project/thread-read inventory calls still hang.

App-server logs show repeated accepted thread/list requests without a corresponding completion or structured error. The evidence now rules out oversized local sidebar metadata, missing active rollout paths, and SQLite corruption as the remaining root cause. The narrowest surviving boundary is the Desktop inventory aggregation/coordination bridge. It should have bounded per-source timeouts and return partial local results plus a structured error when another source stalls, rather than blocking the entire task list indefinitely.

Raw logs, task IDs, user paths, conversation text, and backups are intentionally not attached publicly.

brokemac79 · 8 days ago

Additional symptom observed immediately after the inventory-hang reproduction: assistant turns complete successfully and remain available after restart, but their text is sometimes not rendered in the active Codex Desktop thread until the application is fully closed and reopened. The thread page itself remains open and interactive enough to continue voice input, so this appears to be renderer/bridge state divergence rather than a failed model response or lost durable turn. This strengthens the request to correlate app-server events with renderer acknowledgement and to provide a bounded renderer resynchronization action that does not require restarting the entire app.