[macOS Desktop] Newly spawned subagent cards bounce closed because conversation state is not registered

What version of the Codex App are you using (From “About Codex” dialog)?

Codex Desktop 26.825.51511 (build 7377), bundled codex-cli 0.151.0-alpha.7.2

What subscription do you have?

Paid ChatGPT subscription (exact tier omitted from this public report)

What platform is your computer?

Darwin 25.4.0 arm64 arm

What issue are you seeing?

Newly spawned subagents appear normally as cards in the parent task, but clicking either of the newest cards briefly attempts to open the child detail view and immediately returns to the parent. Older subagent cards in the same parent remain viewable.

The child threads and histories are intact:

• direct app-server thread/read(child_id) succeeds;
• both a running child and a completed child reproduce it;
• both fork_turns: "all" and a bounded fork reproduce it;
• rollout size is not the trigger.

For both affected children, Desktop logs show:
Received turn/started for unknown conversation
Received item/started for unknown conversation
Received item/completed for unknown conversation
Conversation state not found

On card click, thread/read succeeds and is immediately followed by:
No conversation state for conversation ID

Direct navigation to the exact child ID triggers maybe_resume_started -> thread/read -> thread/resume -> maybe_resume_success. After that one navigation, the same card opens normally. This points to a renderer conversation-store hydration gap, not corruption or an app-server read failure.

What steps can reproduce the bug?

1. Open a long-running local parent task in Codex Desktop.
2. While it remains open, spawn a new subagent.
3. Wait until its activity card appears and the child starts producing events.
4. Click the new child card while it is running.
5. Observe that the detail view immediately closes/returns to the parent.
6. Repeat after the child completes; the same failure can occur.
7. Confirm older child cards in the same parent still open.
8. Confirm thread/read(child_id) succeeds.
9. Navigate directly to that child ID once; afterward the card becomes usable.

Observed ordering:
subAgentActivity.started -> thread/list refresh -> about 50 ms later child turn/started arrives for an unknown conversation.

What is the expected behavior?

A newly spawned child should have at least a placeholder conversation state before its turn/item notifications are processed. Early events should be buffered and replayed. If a card is clicked while state is absent, Desktop should perform thread/read -> upsert -> resume and keep the detail view open. Running and completed children should both remain inspectable.

Additional information

Bundled-code inspection suggests an initialization race exposed by a missing fallback:

• discoverForSpawn checks the child through threadsById;
• a just-created child may not exist there yet, so execution falls back to broad descendant discovery;
• reconcileSubagentDescendantSnapshot records threadsById/summary metadata but does not create a missing conversations entry;
• later readThread success alone does not upsert the renderer conversation state.

Suggested fixes: create a placeholder on subAgentActivity.started; buffer early child events; and add upsert/resume-on-miss to the card-opening path.

Related but not exact duplicates: #25836, #31090, #36894, #41471.

Privacy: task names, prompts, project paths, thread IDs, conversation content, and full logs are omitted. Sanitized timestamped excerpts can be provided privately.

Start by tracing the renderer conversation-store flow through discoverForSpawn and reconcileSubagentDescendantSnapshot, then follow subAgentActivity.started and the card-opening path while reproducing the unknown-conversation logs. Check that newly spawned children have state before events arrive, that early events are handled, and that a card click keeps the detail view open for both running and completed children.