[VS Code extension] Restore the active sidebar conversation after window reload or restart
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 125k
- Forks
- 19.4k
- PR merge metrics
- PR metrics pending
Description
What variant of Codex are you using?
vscode
What feature would you like to see?
Suggested type: Feature request / enhancement
Suggested labels: extension, session, enhancement
Summary
The Codex VS Code extension should remember which conversation is currently open in the sidebar and automatically restore that same conversation after:
Developer: Reload Window- restarting VS Code
- reopening the same workspace
The conversation history is not necessarily lost. The problem is that the sidebar forgets which conversation was active, returns to its initial/home state, and requires the user to find and reopen the previous conversation manually.
If restoring the active sidebar route is already intended behavior, this should be classified as a bug instead of an enhancement.
Current behavior
- Open a workspace in VS Code.
- Open the Codex sidebar.
- Select or start a conversation.
- Continue working in that conversation.
- Run
Developer: Reload Window, or completely close and reopen VS Code. - Reveal the Codex sidebar again.
The previous conversation still exists in the conversation history, but the sidebar does not automatically reopen it. The user must locate and select it again.
This is especially disruptive with long conversation lists and with failures that require reloading VS Code as a recovery step.
Expected behavior
For each VS Code window or workspace, the extension should persist the identity of the active sidebar conversation.
After a reload or restart, when the Codex sidebar is restored or revealed, it should reopen the same conversation and route, for example:
/local/<conversationId>
The extension should not create a new conversation or select an unrelated recent conversation.
Window and workspace isolation
The active conversation must be persisted per VS Code window or workspace, not as one user-global selection.
For example:
- Window A, open on project A, has conversation A selected.
- Window B, open on project B, has conversation B selected.
- Reloading either window should restore its own conversation.
- Activity in one window must not change what another window restores.
This matters for users who keep multiple VS Code windows and Codex sessions open simultaneously.
Recovery and fallback behavior
On startup or reload:
- Read the last active conversation ID for the current window/workspace.
- Verify that the conversation still exists and is accessible.
- Restore the corresponding route and conversation state.
- If the conversation was still running, reconnect to its current canonical state.
- If it was deleted, archived, or is no longer accessible, fall back gracefully to the normal home/history view.
A missing conversation must not leave the sidebar blank or stuck during startup.
Why this matters
Reloading or restarting VS Code is a commonly suggested recovery action for Codex extension failures. However, it currently adds another recovery step: finding the conversation that was active before the reload.
This is particularly painful when:
- a task is still running in the background;
- the Codex panel becomes blank or gray;
- many conversations have similar names;
- several VS Code windows are open;
- the conversation is not among the few immediately visible recent items.
Restoring the active conversation would make reload-based recovery substantially safer and less confusing.
Related issues
- #14812 — Previous conversation history is not restored after restarting VS Code. That report concerns conversations disappearing from the visible history. In this request, the history may remain available, but the previously active conversation is not automatically reopened.
- #26772 — Opening native VS Code Chat Sessions should route to
/local/<conversationId>and survive reload. This overlaps with conversation routing, but does not specifically request automatic restoration of the last active Codex sidebar conversation. - #19603 — The VS Code extension session sidebar should match the Codex CLI resume-picker semantics. This concerns session discovery and resume behavior, rather than persistence of the active sidebar selection.
- #33968 and #9615 — Blank or gray Codex views for which restarting or reloading VS Code may be attempted as recovery. Restoring the active conversation would reduce the disruption caused by those failures.
Acceptance criteria
- Reloading a VS Code window restores the conversation previously open in its Codex sidebar.
- Closing and reopening the same workspace restores that conversation.
- Separate VS Code windows can remember different active conversations.
- The restored conversation belongs to the correct workspace/project.
- An active task reconnects to its existing thread rather than creating a duplicate.
- Deleted, archived, or inaccessible conversations produce a safe fallback view.
- Restoration failure never results in an empty, gray, or permanently loading sidebar.
Environment where observed
- Product: Codex VS Code extension (
openai.chatgpt) - OS: Linux Mint 22.3
- Display session: X11
- VS Code: 1.137.0
- Extension builds observed: 26.901.22334 and 26.903.61454
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing the VS Code extension's sidebar conversation routing around the /local/<conversationId> route and the Developer: Reload Window lifecycle. Check how window or workspace state is persisted and restored, then verify separate-window isolation, active-task reconnection, and safe fallback for missing conversations without leaving an empty or stuck sidebar.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- vscode
- Domain
- desktop-dev, tooling
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100