What version of the Codex App are you using (From “About Codex” dialog)?
Codex Desktop 26.825.32147 (build 7303)
Bundled codex-cli 0.150.0-alpha.12.2
Standalone codex-cli 0.150.1
What platform is your computer?
macOS 26.5.2 (25F84), arm64
What issue are you seeing?
After Codex Desktop updated/restarted while a parent task had long-running subagents, the subagents resumed successfully and continued writing to their original worktrees, but their chats could no longer be opened from the Desktop UI.
The underlying child threads were intact and active. App-server diagnostics showed for each affected child:
status: active
title: null
history: readable
However, the child thread IDs were absent from the ordinary thread listing and sidebar section item keys. This made the chats inaccessible through normal navigation even though the agents were still running and sending progress to the parent.
Two concurrently active child threads reproduced the same state after the restart. Private thread IDs, task names, paths, and conversation contents are omitted.
What steps can reproduce the bug?
- In Codex Desktop on macOS, start a parent task that spawns multiple long-running subagents.
- Leave at least two subagents actively working in their existing child threads.
- Update or restart Codex Desktop.
- Confirm that the subagents resume as active and continue producing progress.
- Try to open the resumed subagent chats from the parent task / subagent UI.
- Observe that the chats cannot be opened normally.
- Inspect the threads through app-server thread tools:
- direct
read_thread(child_id) succeeds and returns the full active history;
- the resumed child has
title: null;
list_threads does not include the child ID in normal threads, pinned threads, or sidebar section item keys.
Actual behavior
- The subagent process/turn resumes and remains genuinely active.
- Its child-thread history remains readable by exact ID.
- Its display title is lost (
null).
- The child is filtered out of normal thread/sidebar discovery.
- Clicking or otherwise opening the chat through the normal subagent UI fails.
Expected behavior
- An active subagent restored after an application restart should retain its display name and parent/child navigation route.
- The user should be able to reopen the child chat from the parent task while it is working.
- Resume reconciliation should keep execution state, thread metadata, and UI discoverability consistent.
Verified workaround and its limitation
The histories were recovered without touching local state files or stopping the agents:
- Recover each child thread ID from the parent task's persisted subagent activity.
- Call
read_thread(child_id) to verify that the thread is intact and active.
- Restore a display title with
set_thread_title(child_id, name).
- Open it with direct
navigate_to_codex_page(child_id).
Direct navigation succeeded and allowed both chats to be opened one at a time. Worktrees, turns, and cached build state were unaffected.
This is only a partial workaround:
move_thread_to_sidebar_section returned success for both chats and pinned, but a subsequent list_threads still omitted the child IDs and reported no pinned child threads.- Attempting the non-destructive reindex path
set_thread_archived(child_id, false) failed with already has an active writer, which is correct for an active thread but means archive/unarchive cannot repair discoverability while the agent is working.
- Renaming plus direct navigation repairs access for the current session, not the missing sidebar/index relationship.
Additional information
This appears to be a metadata/UI reconciliation regression in the multi-agent resume path rather than thread corruption or failed agent resumption. The important invariant is:
active resumed child + readable exact-ID history
but title is null + child is absent from normal discovery/navigation
Potentially related, but not duplicates:
The official changelog for the 0.150.0 line mentions multi-agent resume-test and resumed-thread capability work, so this may be an uncovered UI/index reconciliation edge case in that path.
Privacy note: exact thread IDs, repository paths, mathematical task names, and conversation contents are intentionally omitted. Sanitized app-server outputs can be provided if maintainers request them.
What version of the Codex App are you using (From “About Codex” dialog)?
What platform is your computer?
What issue are you seeing?
After Codex Desktop updated/restarted while a parent task had long-running subagents, the subagents resumed successfully and continued writing to their original worktrees, but their chats could no longer be opened from the Desktop UI.
The underlying child threads were intact and active. App-server diagnostics showed for each affected child:
However, the child thread IDs were absent from the ordinary thread listing and sidebar section item keys. This made the chats inaccessible through normal navigation even though the agents were still running and sending progress to the parent.
Two concurrently active child threads reproduced the same state after the restart. Private thread IDs, task names, paths, and conversation contents are omitted.
What steps can reproduce the bug?
read_thread(child_id)succeeds and returns the full active history;title: null;list_threadsdoes not include the child ID in normal threads, pinned threads, or sidebar section item keys.Actual behavior
null).Expected behavior
Verified workaround and its limitation
The histories were recovered without touching local state files or stopping the agents:
read_thread(child_id)to verify that the thread is intact and active.set_thread_title(child_id, name).navigate_to_codex_page(child_id).Direct navigation succeeded and allowed both chats to be opened one at a time. Worktrees, turns, and cached build state were unaffected.
This is only a partial workaround:
move_thread_to_sidebar_sectionreturned success for bothchatsandpinned, but a subsequentlist_threadsstill omitted the child IDs and reported no pinned child threads.set_thread_archived(child_id, false)failed withalready has an active writer, which is correct for an active thread but means archive/unarchive cannot repair discoverability while the agent is working.Additional information
This appears to be a metadata/UI reconciliation regression in the multi-agent resume path rather than thread corruption or failed agent resumption. The important invariant is:
Potentially related, but not duplicates:
already has an active writerafter latest update #37403 — active-writer conflict during Desktop/Remote handoffThe official changelog for the 0.150.0 line mentions multi-agent resume-test and resumed-thread capability work, so this may be an uncovered UI/index reconciliation edge case in that path.
Privacy note: exact thread IDs, repository paths, mathematical task names, and conversation contents are intentionally omitted. Sanitized app-server outputs can be provided if maintainers request them.