What version of the IDE extension are you using?
26.422.71525
What subscription do you have?
plus
Which IDE are you using?
cursor
What platform is your computer?
OS: Microsoft Windows NT 10.0.26200.0 x64 PowerShell: 5.1.26100.8115, Desktop edition VS Code: 1.109.5, 072586267e68ece9a47aa43f8c108e0dcbf44622, x64 Cursor: 3.2.16, 3e548838cf824b70851dd3ef27d0c6aae371b3f0, x64
What issue are you seeing?
After restarting or reloading VS Code/Cursor, the first Codex history session I click fails to render its chat history.
The issue is order-dependent, not tied to a specific conversation.
For example, if I open session A first after startup, session A stays blank / does not lo
ad. If I then open session B, session B loads normally. If I close session B and try session A again, session A still does not load until I restart VS Code/Cursor.
After restarting VS Code/Cursor and changing the order, if I open session B first, then session B fails, while session A can load if opened second.
So the broken session is always the first history session opened after extension startup, and it remains stuck until the editor is restarted.
Expected behavior:
Any Codex history session should load normally regardless of whether it is opened first or second after extension startup.
Actual behavior:
The first clicked history session after extension startup becomes stuck and remains unloadable until VS Code/Cursor is restarted. The affected session changes depending on opening order.
Relevant logs:
maybe_resume_success conversationId=... latestTurnStatus=completed markedStreaming=true turnCount=67
[IpcClient] Received broadcast but no handler is configured method=thread-stream-state-changed
[IpcClient] Received broadcast but no handler is configured method=thread-stream-state-changed
### What steps can reproduce the bug?
1. Restart or reload VS Code/Cursor.
2. Open Codex.
3. Click a Codex history session, for example session A.
4. Observe that session A stays blank / does not load its chat history.
5. Click another history session, for example session B.
6. Observe that session B loads normally.
7. Close session B.
8. Try to open session A again.
9. Observe that session A still does not load.
10. Restart or reload VS Code/Cursor.
11. Open session B first this time.
12. Observe that session B now fails, while session A can load if opened second.
### What is the expected behavior?
Any Codex history session should load its chat history normally after VS Code/Cursor starts or reloads.
The first clicked history session should behave the same as the second and later clicked sessions. Opening order should not affect whether a session can be restored.
If the backend successfully resumes a conversation, the UI should render the restored chat history or retry/rehydrate the session instead of leaving the panel blank.
### Additional information
_No response_
What version of the IDE extension are you using?
26.422.71525
What subscription do you have?
plus
Which IDE are you using?
cursor
What platform is your computer?
OS: Microsoft Windows NT 10.0.26200.0 x64 PowerShell: 5.1.26100.8115, Desktop edition VS Code: 1.109.5, 072586267e68ece9a47aa43f8c108e0dcbf44622, x64 Cursor: 3.2.16, 3e548838cf824b70851dd3ef27d0c6aae371b3f0, x64
What issue are you seeing?
After restarting or reloading VS Code/Cursor, the first Codex history session I click fails to render its chat history.
The issue is order-dependent, not tied to a specific conversation.
For example, if I open session A first after startup, session A stays blank / does not lo
ad. If I then open session B, session B loads normally. If I close session B and try session A again, session A still does not load until I restart VS Code/Cursor.
After restarting VS Code/Cursor and changing the order, if I open session B first, then session B fails, while session A can load if opened second.
So the broken session is always the first history session opened after extension startup, and it remains stuck until the editor is restarted.
Expected behavior:
Any Codex history session should load normally regardless of whether it is opened first or second after extension startup.
Actual behavior:
The first clicked history session after extension startup becomes stuck and remains unloadable until VS Code/Cursor is restarted. The affected session changes depending on opening order.
Relevant logs: