Product:
- Codex VS Code extension / `openai.chatgpt`
- Extension version observed in logs: `26.422.30944`
- Codex app/server version observed in logs: `0.125.0-alpha.3`
- Environment: VS Code Remote on Windows 11 with WSL2 and current folder mounted to a FAT32.
- Codex state path: user-level `~/.codex`
- Note that the current project is small (~50 files) and VSCode and Codex Extension version is up-to-date as of this writing
Summary:
After VS Code reload/restart, existing Codex chats initially appear not to open. Clicking active chat history entries can appear to do nothing. After waiting around 5-10 seconds, the current chat appears and older active chats can then be opened and switched between normally. This makes the UI look broken even though the chat history data is present and eventually usable. Clicking away before the delay elapses seems to cancel the startup process so that subsequent clicks have the same issue. If the delay period completes before clicking out of the chat, all historic chats are then accessible.
Expected behaviour:
The UI should show a clear loading/restoring/startup state while Codex extension/app-server/history restore is still warming up. If chat history is not ready yet, clicking a chat should either queue the action or display a clear “Codex is starting / restoring chats” message.
Actual behaviour:
Immediately after reload/restart, chat panes can appear blank and chat history clicks can appear to do nothing. There is no obvious indication that Codex is still starting. After a short delay, the same chats become readable.
Reproduction notes:
1. Have at least two active Codex chats in the VS Code extension.
2. Reload or restart VS Code.
3. Immediately try opening a current chat and an older active chat.
4. Observe that the UI can look blank/unresponsive.
5. Wait about 5-10 seconds.
6. The current chat appears; the older active chat can then also be opened.
Local investigation:
- Active chat rollout files exist under `~/.codex/sessions/YYYY/MM/DD/`.
- The older active chat rollout was valid JSONL and parsed successfully.
- SQLite `threads` table marked both chats active and pointed to valid rollout paths.
- A stale `session_index.jsonl` timestamp was repaired, but the main observed issue remained startup/readiness latency rather than missing data.
- The CLI exposes `codex resume <SESSION_ID>`, suggesting the underlying session data is recoverable.
Relevant log patterns:
- Extension log shows startup and app-server spawn:
- `Activating Codex extension`
- `[CodexMcpConnection] Spawning codex app-server`
- `[startup][renderer] app routes mounted after 1280ms`
- `[startup][renderer] app routes mounted after 1810ms`
- `maybe_resume_success conversationId= …`
- During/after startup there are repeated warnings:
- `codex_app_server::transport: dropping overload response for connection ConnectionId(0): outbound queue is full`
- `[IpcClient] Received broadcast but no handler is configured method=thread-stream-state-changed`
- `[IpcClient] Received broadcast but no handler is configured method=thread-read-state-changed`
Impact:
This creates the impression that Codex chat history restore is broken or that old conversations are lost. A visible readiness/loading state would prevent confusion and reduce risky user attempts to manually edit/delete `~/.codex` state.
Suggested fix:
- Add a startup/restoring indicator in the VS Code extension while app-server and chat history restore are warming up.
- Disable or queue chat-history clicks until `thread/resume`/history APIs are ready.
- Avoid silently ignoring clicks during app-server backpressure.
- Consider surfacing a non-scary message like “Codex is restoring chats…” with retry/progress feedback.
reaction to help increase its visibility.