Codex Desktop: clicking one completed session can break opening all existing sessions #22969

Summary

In Codex Desktop on Windows, clicking a specific completed session in the session/history list fails to open its chat window. After clicking that session, opening other existing sessions also stops working until the app/runtime state is reset.

The affected session data itself appears valid: the JSONL parses, the SQLite thread row exists, and the session has a completed final turn. This looks more like a Desktop UI/runtime routing or hydration issue than a corrupted session file.

Environment

• OS: Windows 10.0.19045
• Locale: ko-KR
• Codex Desktop package path observed in logs: OpenAI.Codex_26.513.3673.0_x64__2p2nqsd0c76g0
• Codex Desktop release string observed in logs: 26.513.31313
• Session cli_version: 0.131.0-alpha.9
• Source: Codex Desktop / source: vscode

Reproduction

1. Have an existing completed session in Codex Desktop history.
2. Click the completed session in the chat/session list.
3. The selected session does not open in the chat pane.
4. After that, clicking other existing sessions also fails to open them.
5. Fully restarting Codex and clearing stale child processes appears to be the only recovery path.

The session ID that triggered the issue locally was:

019e2f5f-cf51-7fc0-b0bb-e475b222d4c1

Expected behavior

• Clicking a completed session opens that session's chat view.
• If one session fails to hydrate, the failure should be isolated and should not prevent opening other existing sessions.
• Session read/resume errors should surface visibly instead of leaving the UI in a state where no existing session opens.

Actual behavior

• The selected completed session does not open.
• After clicking it, other existing sessions also fail to open.
• The backend session data remains present and parseable.

Local diagnostics

The session file was present under .codex/sessions/... and validated successfully:

jsonl lines: 336
bad JSON lines: 0
contains task_complete: yes

The thread row existed in state_5.sqlite:

id: 019e2f5f-cf51-7fc0-b0bb-e475b222d4c1
archived: 0
rollout_path: <CODEX_HOME>/.codex/sessions/.../rollout-...019e2f5f....jsonl
tokens_used: 5231496

SQLite integrity checks also passed:

state_5.sqlite: PRAGMA integrity_check = ok
logs_2.sqlite: PRAGMA integrity_check = ok

Relevant log signatures

Around the same period, Desktop logs show the target conversation being created and turns routed normally during the original run:

Conversation created conversationId=019e2f5f-cf51-7fc0-b0bb-e475b222d4c1
response_routed ... method=turn/start ... conversationId=019e2f5f-cf51-7fc0-b0bb-e475b222d4c1
response_routed ... method=thread/name/set ... conversationId=019e2f5f-cf51-7fc0-b0bb-e475b222d4c1

But the same app log stream also repeatedly contains unknown-conversation routing errors:

[electron-message-handler] Received turn/started for unknown conversation conversationId=<different-id>
[electron-message-handler] Received turn/completed for unknown conversation conversationId=<different-id>

For previously opened sessions, resume also produced goal hydration errors:

Request failed ... method=thread/goal/get ... error={"code":-32600,"message":"goals feature is disabled"}
Failed to hydrate thread goal after resume ... error={"code":-32600,"message":"goals feature is disabled"}
maybe_resume_success ... markedStreaming=true

A process check also showed multiple lingering Desktop child app-server processes after the affected sessions completed:

codex.exe app-server --listen stdio://
node_repl.exe

Notes

• This does not appear to be caused by corrupt JSONL or SQLite storage.
• A missing Git safe.directory entry existed for the workspace and was fixed, but that did not explain the already-valid session file and repeated unknown conversation UI routing errors.
• I can provide more sanitized log excerpts if helpful, but I avoided attaching raw logs because they contain local paths and user/session metadata.