openai / openai/codex

[macOS Desktop] Resumed active subagent chats lose titles and cannot be reopened

Open
#41,471 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

app app-server bug session subagent
Dominant language
Rust
Stars
125k
Forks
19.4k
PR merge metrics
PR metrics pending

Description

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?
  1. In Codex Desktop on macOS, start a parent task that spawns multiple long-running subagents.
  2. Leave at least two subagents actively working in their existing child threads.
  3. Update or restart Codex Desktop.
  4. Confirm that the subagents resume as active and continue producing progress.
  5. Try to open the resumed subagent chats from the parent task / subagent UI.
  6. Observe that the chats cannot be opened normally.
  7. 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:

  1. Recover each child thread ID from the parent task's persisted subagent activity.
  2. Call read_thread(child_id) to verify that the thread is intact and active.
  3. Restore a display title with set_thread_title(child_id, name).
  4. 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:

  • #25341 — child threads counted as top-level recent conversations / stale spawn edges
  • #33700 — completed subagents remain open and restore stale MCP stacks
  • #37403 — active-writer conflict during Desktop/Remote handoff
  • #40199 — documentation request for side-conversation lifecycle

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.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Reproduce the restart flow, then inspect the app-server entry points read_thread, list_threads, set_thread_title, navigate_to_codex_page, and the sidebar/archive operations. Done means an active resumed child retains its title and parent/child route, remains discoverable in normal thread and sidebar listings, and can be reopened while working.

Written by the indexing model from the issue text.

Assessment

Tech stack
macos, rust
Domain
backend, desktop
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.