Side Chat cannot be opened because the desktop reports “unknown conversation” despite an existing local session

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

26.825.51511 (build 7377）

What subscription do you have?

PRO 20x

What platform is your computer?

macOS Darwin 24.5.0 arm64 arm

What issue are you seeing?

Summary

Some Side Chats cannot be opened from the Codex desktop UI. The corresponding subagent session exists on disk and in the Codex state database, but the desktop renderer reports that the conversation is unknown.

Environment

• OS: macOS
• Codex desktop app: 26.825.51511 (build 7377)
• Bundled Codex version: 0.151.0-alpha.7.2
• History mode: paginated
• Project type: local project
• Parent conversation type: normal user thread
• Child conversation type: Side Chat/subagent thread

Current behavior

The Side Chat does not open or displays no conversation.

The desktop log reports messages such as:

Received item/started for unknown conversation conversationId=<redacted>
Received item/completed for unknown conversation conversationId=<redacted>
Conversation state not found conversationId=<redacted>

These errors can occur repeatedly for the same Side Chat ID.

Diagnostic observations

For affected Side Chats, I verified that:

• the corresponding JSONL session file exists;
• the session JSONL is valid;
• the child thread has a record in state_5.sqlite;
• the parent-child spawn edge exists;
• the child is still marked as open;
• the conversation is not present in the desktop application's normal local conversation catalog.

In one affected parent thread, 106 child spawn records remained in the open state. Another affected thread contained 26 open child records. This may contribute to the synchronization problem, but I have not established it as the root cause.

Root-cause hypothesis

The backend/session layer appears to know about the subagent conversation, but the desktop renderer has not registered the corresponding conversation state before receiving its events.

As a result, the renderer receives valid child events associated with a conversation ID it cannot resolve.

This is a hypothesis based on the local state and logs, not a confirmed implementation-level root cause.

Impact

• Side Chat results can become inaccessible from the UI.
• Users cannot reliably inspect work performed by subagents.
• Restarting the desktop application does not consistently restore access.
• The raw conversation still exists locally, creating a discrepancy between stored data and visible history.

Potential approaches

Maybe we can consider:

1. registering Side Chat conversation state before dispatching child events;
2. reconstructing missing Side Chat state from the local session and spawn-edge records;
3. reconciling orphaned open child records after startup;
4. showing a recoverable error when a Side Chat cannot be resolved;
5. adding a supported way to reopen or export an existing Side Chat transcript.

I can provide sanitized desktop log excerpts and metadata for affected conversation IDs if needed.

What steps can reproduce the bug?

Steps to reproduce

1. Open a normal thread in a local Codex project.
2. Start work that creates one or more Side Chats/subagent conversations.
3. Allow a Side Chat to produce events or finish a turn.
4. Navigate to another thread in the same project.
5. Return to the parent thread.
6. Click the Side Chat entry or card to open its conversation.

The failure becomes more frequent in parent threads containing many Side Chat children.

What is the expected behavior?

Expected behavior

Clicking a visible Side Chat should open its transcript.

If Side Chats are intentionally excluded from the normal top-level thread list, the parent thread should still be able to resolve and render their conversation state.

Additional information

Thanks

Start by reproducing the failure and comparing the desktop logs with the session JSONL and state_5.sqlite records for an affected Side Chat. Trace how the desktop renderer resolves the child conversation before processing its events. Done means an existing Side Chat opens from its parent and no longer produces unknown-conversation errors, with coverage added for the reported navigation sequence.