Codex Desktop can remain blank indefinitely when opening tasks with stale subagents

Open 💬 3 comments Opened Aug 12, 2026 by phillbee
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using?

Codex Desktop 26.803.61601 (build 6396), bundled CLI 0.147.0-alpha.6.5.

What platform is your computer?

macOS 26.5.2 (25F84), Apple silicon (arm64).

What issue are you seeing?

Some existing tasks never finish opening. Selecting an affected task leaves the conversation blank with a loading spinner for several minutes. Quitting and reopening the app does not resolve it, while other existing tasks load normally.

This makes the affected work inaccessible. The app shows no error, retry option or indication of what it is waiting for.

A local diagnostic check found:

  • The affected task's history is present and valid: about 1.3 MB, 331 JSONL records and one turn.
  • Direct app-server thread/read (including turns) and thread/resume calls both succeed, returning 331 items with zero parse errors.
  • The Desktop app repeatedly sends thread/read and thread/resume requests, but the renderer remains blank.
  • The affected parent task has three month-old child-agent edges still marked open. None has a writer lock, but the UI reports three subagents as Working.
  • In the same local database, 33 active parent tasks have 284 open child edges older than 24 hours; 256 are older than seven days.

The stale child-agent state is a strong correlation, not a confirmed root cause. The backend can read and resume the parent task successfully, so this looks like a Desktop task-loading or state-rehydration problem rather than missing or malformed history.

What steps can reproduce the bug?

I do not yet have a minimal fresh-task reproducer, but the failure is repeatable for the affected task:

  1. Open a long-running task that previously used subagents.
  2. Quit and restart Codex Desktop.
  3. Select the task.
  4. The task remains blank with a loading spinner and does not render its history.

Clearing disposable renderer caches and reconciling the active thread database with the available history files did not fix this task. A different existing task loaded successfully afterward.

What is the expected behaviour?

An existing task with valid local history should render promptly. Historical or stale child-agent records should not prevent the parent task from opening.

If the app cannot complete task rehydration, it should show a bounded error with a retry or repair action rather than spin indefinitely.

Related issues

  • #37041: historical subagents rehydrated as active when a task opens
  • #25179: stale subagents accumulate in the Desktop app
  • #25341: stale open spawn edges
  • #29590: Desktop becomes unresponsive opening previous conversations

Thread titles, IDs, paths and conversation contents are omitted. I can provide sanitised logs or additional database summaries if useful.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 15 days ago

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

  • #37041

Powered by Codex Action

phillbee · 15 days ago

Feedback id = 019fafd0-2c16-7630-a098-c52175537aab

phillbee · 15 days ago

Follow-up: separate new-chat failure traced to stuck macOS Documents access

During the same period, creating a new local chat also became repeatably stuck: the send button spun and eventually returned without sending.

Local evidence:

  • Three thread/start requests each timed out after 30 seconds. Other app-server requests, including config/read, continued to complete normally, so this was not a queue-wide stall.
  • Each attempt reached session initialisation and created a provisional thread plus shell snapshot, but the thread was not persisted and the prompt was not submitted.
  • Immediately beforehand, Desktop's git rev-parse in a workspace under ~/Documents/Codex timed out after 60 seconds.
  • Read-only directory listings of both ~/Documents and ~/Desktop also hung inside the macOS open() syscall, while ~/Projects remained accessible. This was not a memory-pressure problem.
  • Resetting only ChatGPT's Documents and Desktop privacy records, restarting the app, and accepting the resulting “ChatGPT would like to access files in your Documents folder” prompt resolved the problem. Full Disk Access was not enabled.

Limited post-fix verification:

  • Documents enumeration completed in 2.39 seconds instead of hanging.
  • A new thread/start completed in 154 ms.
  • Its first turn/start completed in 9 ms.
  • No further composer, Git or app-server timeout appeared during the test.

This appears to explain the new-chat failures for workspaces under Documents. It does not establish that the original blank existing-task/stale-subagent problem has the same cause. In either case, Desktop should surface the missing/stuck folder permission or a bounded error rather than leave chat creation spinning indefinitely.