[FEATURE] VS Code extension: restore the exact set of open session tabs after a server/extension-host restart (Firefox-style session restore)
Preflight Checklist
- [x] I have searched existing requests and this feature hasn't been requested yet (related requests exist and were auto-closed as stale: see Problem Statement)
- [x] This is a single feature request (not multiple features)
Problem Statement
I run 10+ Claude Code sessions in parallel in editor tabs over Remote-SSH (macOS laptop -> Linux host). When the laptop sleeps longer than the reconnection grace time, the remote server and extension hosts shut down, and every Claude CLI process attached to a tab exits with them. On reopening, the tabs come back blank or not at all. The transcripts are intact in ~/.claude/projects/, but nothing records which sessions were open. I have to remember them and --resume or pick them from "Past conversations" one by one, and sessions that entered a git worktree don't appear in that list at all (#81024, #82802). With 10+ tabs this wipes out a working context that took hours to build.
Today's restore depends on VS Code's per-panel webview state. The serializer restores the tab shell but drops the session ID (#35004, #83322), and when the shell itself isn't restored there is nothing to fall back on. Even with that fixed, the extension has no durable list of its own.
Prior requests, both auto-closed as stale rather than declined: #60937 (auto-restore editor-area sessions after Reload Window), #35004, #83322.
Proposed Solution
Keep a small per-workspace manifest of open session tabs, for example in workspaceState or ~/.claude/ide/: {sessionId, cwd, position, title}.
- Add an entry when a tab opens or a session starts in it.
- Update it when the tab's session changes (new session, resume, worktree entered).
- Remove it only when the user closes the tab, never when the extension host or server shuts down.
- On activation, reopen every entry with
--resume <sessionId>in the recordedcwd, in the recorded position.
Optional setting claudeCode.restoreOpenSessions: always | ask | never, plus a "Restore previous sessions" command. This is the Firefox session-restore model: the list of open items is the source of truth, not the UI shell. It survives window reloads, extension-host and server restarts, crashes, Remote-SSH/WSL drops and worktree sessions.
Alternative Solutions
- Passing the saved
sessionIDindeserializeWebviewPanel(the one-line fix in #35004) fixes tabs VS Code restores, but not the cases above. claude-vscode.reopenClosedSession(Cmd/Ctrl+Shift+T, per #60937) reopens one session at a time and only if you know which.- Current workaround: sort
~/.claude/projects/*/*.jsonlby mtime and read each one's last prompt to guess what was open. - Running sessions in tmux with the CLI survives, but gives up the editor integration.
Priority
High - significant impact on productivity
Feature Category
Other (VS Code extension; no IDE option in this form)
Use Case Example
- Remote-SSH into a Linux host; 12 Claude tabs open across two editor groups, some in git worktrees.
- Close the laptop lid overnight.
- In the morning, open the laptop and reconnect. The old server is gone (the logs show: grace period expired, extension hosts exited, "all consumers inactive, shutting down", then a fresh server and new extension hosts on reconnect).
- Expected: the same 12 tabs reopen with their conversations, in the same groups.
- Actual: tabs are blank or missing and I rebuild the list from transcript timestamps.
Additional Context
Server log timeline (UTC, ids omitted), extension 2.1.284, VSCodium, macOS client to Ubuntu host:
21:26 client disconnected, will wait for reconnection 3h
22:10 another client connected, wait shortened to 5m
22:15 short grace time expired; Extension Host Process exited with code 0
22:20 ServerLifetime: all consumers inactive, shutting down
23:11 Unknown reconnection token (never seen); new server start
06:15 New connection established (fresh server + new extension hosts)
I did not verify in the Claude logs that the blank tabs at 06:15 are #35004 itself; that link is inferred from the timeline.
Related: #82878, #82802, #81024, #94743, #64756. The extension already persists recentSessions in globalState (per #60937), which may be a starting point for the manifest.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗