Repository navigation
Codex Desktop session cannot be resumed or forked after successful task completion, with duplicate Guardian subagent threads exposed in conversation list #32035
Description
What version of the Codex App are you using (From “About Codex” dialog)?
Codex Desktop 0.144.0-alpha.4
What subscription do you have?
Codex Desktop 0.144.0-alpha.4
What platform is your computer?
Windows 10 Pro 64-bit, version 10.0.19045, zh-CN
What issue are you seeing?
A Codex Desktop thread successfully completed its coding task and created the expected files, but afterward the thread became impossible to reopen, resume, or fork.
Main thread ID:
019f4a0e-21b8-71f0-9ee3-2d125bdc9a85
Session file:
C:\Users\LYX\.codex\sessions\2026\07\10\rollout-2026-07-10T11-24-33-019f4a0e-21b8-71f0-9ee3-2d125bdc9a85.jsonl
The original task successfully created four Codex Agent TOML files and one AGENTS.md file. The task result exists on disk and was successfully validated.
However, afterward:
- Opening the original thread in Codex Desktop causes the app to hang or show a blank conversation pane.
codex resume <session_id>fails.codex fork <session_id>also fails.- Multiple internal Guardian subagent threads were exposed in the normal conversation list.
- These internal threads were incorrectly titled with content such as:
<recommended_plugins> Here is a list of plugins that are available...
The main thread metadata is valid and identifies it as a normal user thread:
thread_source = usersession_id = 019f4a0e-21b8-71f0-9ee3-2d125bdc9a85cwd = E:\Code\Python_Project\2605marketcode_under_codex
The child threads identify themselves as:
thread_source = subagentsource.subagent.other = guardianparent_thread_id = 019f4a0e-21b8-71f0-9ee3-2d125bdc9a85
The session JSONL file is valid JSON, has no UTF-8 BOM, and begins with valid session_meta.
codex doctor reports:
- state databases healthy
- state DB integrity ok
- rollout files and state DB thread inventory agree
- rollout DB scan errors: 0
- duplicate rollout thread IDs: 0
- WebSocket connected successfully with HTTP 101 Switching Protocols
- 0 warnings
- 0 failures
Despite this, both resume and fork fail.
Resume error:
Error: Failed to resume session from C:\Users\LYX\.codex\sessions\2026\07\10\rollout-2026-07-10T11-24-33-019f4a0e-21b8-71f0-9ee3-2d125bdc9a85.jsonl
### What steps can reproduce the bug?
Feedback ID: no-active-thread-019f4a82-606e-74e2-b84f-6c41ff9db7fb
### What is the expected behavior?
The successfully completed thread should reopen normally and should be resumable or forkable.
Internal Guardian subagent threads should not appear as normal user conversations with incorrect `<recommended_plugins>` titles.
The original thread cannot be reopened, resumed, or forked despite valid session metadata, healthy databases, valid rollout inventory, successful WebSocket connectivity, and valid JSONL content.
Multiple internal Guardian subagent threads are exposed in the normal conversation list with incorrect titles.
### Additional information
This issue also caused significant wasted Codex usage while troubleshooting and attempting recovery. I am separately contacting OpenAI Support to request restoration or compensation of the usage lost because of this product failure.
Activity
github-actions commentedon Jul 10, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Iamfoodman commentedon Jul 10, 2026
Thanks for identifying the potential duplicates.
I reviewed the suggested issues, but my case appears to include additional symptoms that may distinguish it from a simple resume failure:
<recommended_plugins>....codex doctorreports healthy databases, matching rollout/thread inventory, successful WebSocket connectivity, 0 warnings, and 0 failures.For these reasons, I am keeping this issue open unless it is confirmed that one of the suggested issues covers the same combination of symptoms and root cause.
Iamfoodman commentedon Jul 10, 2026
Iamfoodman commentedon Jul 10, 2026
Additional evidence:
codex resume 019f4a0e-21b8-71f0-9ee3-2d125bdc9a85returns:
fengyat commentedon Jul 17, 2026
Seeing a related symptom in the same guardian-subagent / user-thread area, filed separately as #33765.
In our case the guardian sub-session isn't just exposed in the list — its judge
base_instructions("You are judging one planned coding-agent action...") end up pinned on the user-facing thread (source: cli,thread_source: user). Becausebase_instructionsare fixed at session creation and never re-derived on resume, the main model then answers every normal request with approval JSON ({"outcome":"allow"}) instead of doing the work — and it gets worse after each auto-compaction, since the pinned judge prompt dominates once history is summarized.Same root area as this issue (guardian subagent boundary not preserved when a thread is persisted/resumed), different observable failure. Details + redacted
session_metaevidence in #33765.