Codex Desktop session cannot be resumed or forked after successful task completion, with duplicate Guardian subagent threads exposed in conversation list

Open 💬 6 comments Opened Jul 10, 2026 by Iamfoodman

💡 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 (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 = user
session_id = 019f4a0e-21b8-71f0-9ee3-2d125bdc9a85
cwd = E:\Code\Python_Project\2605marketcode_under_codex

The child threads identify themselves as:

thread_source = subagent
source.subagent.other = guardian
parent_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.

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 1 month ago

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

#31047
#31090
#30903

Powered by Codex Action

Iamfoodman · 1 month ago

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:

The original task completed successfully and created the expected files.
The original thread cannot be reopened, resumed, or forked.
Multiple internal Guardian subagent threads were exposed in the normal conversation list.
These subagent threads were incorrectly titled with <recommended_plugins>....
codex doctor reports 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 · 1 month ago

Thanks for identifying these potential duplicates.

I reviewed the suggested issues. My case appears closest to #31090 because it also involves a parent thread with multiple subagents and a subsequent conversation/session-state failure.

However, my case has additional symptoms:

The original parent task completed successfully and created the expected files.
The original thread cannot be reopened in Codex Desktop.
codex resume <session_id> fails.
codex fork <session_id> also fails.
Multiple internal guardian subagent threads are exposed directly in the normal conversation list.
These internal threads are incorrectly titled with <recommended_plugins>....
codex doctor reports healthy databases, matching rollout/thread inventory, successful WebSocket connectivity, 0 warnings, and 0 failures.

Because the failure affects not only the Desktop renderer but also CLI session replay/forking, and because internal Guardian threads are exposed in the normal conversation list, I am keeping this issue open unless maintainers confirm that one of the suggested issues has the same root cause.

AAA脑白金批发商罗总
@.***

Iamfoodman · 1 month ago

Additional evidence:

codex resume 019f4a0e-21b8-71f0-9ee3-2d125bdc9a85

returns:

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

fengyat · 1 month ago

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). Because base_instructions are 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_meta evidence in #33765.

shleder · 11 days ago

This combination — valid rollout/inventory, resume+fork failure, and internal Guardian threads leaking into the user conversation list — is a strong field case for codex-rescue. I’m testing it specifically on persisted-session boundary failures, not just outright malformed JSONL.

If you still have the affected local thread, could you run the read-only path first?

pipx install codex-rescue
codex-rescue sessions
codex-rescue doctor --latest

A HEALTHY, UNKNOWN, or concrete finding are all useful; the important part is that Rescue must not guess merely because Codex itself cannot resume/fork. If diagnosis identifies an interrupted state and you actually want recovery, the optional path is salvage --latest --fork then verify <rescue-id>.

Please share sanitized output/versions/exit codes only—no raw rollouts/SQLite, prompts, credentials, or private paths. Repo: https://github.com/shleder/codex-rescue