Codex Desktop can remain blank indefinitely when opening tasks with stale subagents
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) andthread/resumecalls both succeed, returning 331 items with zero parse errors. - The Desktop app repeatedly sends
thread/readandthread/resumerequests, 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 asWorking. - In the same local database, 33 active parent tasks have 284
openchild 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:
- Open a long-running task that previously used subagents.
- Quit and restart Codex Desktop.
- Select the task.
- 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
openspawn 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.
3 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Feedback id = 019fafd0-2c16-7630-a098-c52175537aab
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:
thread/startrequests each timed out after 30 seconds. Other app-server requests, includingconfig/read, continued to complete normally, so this was not a queue-wide stall.git rev-parsein a workspace under~/Documents/Codextimed out after 60 seconds.~/Documentsand~/Desktopalso hung inside the macOSopen()syscall, while~/Projectsremained accessible. This was not a memory-pressure problem.Limited post-fix verification:
thread/startcompleted in 154 ms.turn/startcompleted in 9 ms.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.