VS Code extension: tab silently attached to a different session, no user action

Status Open
Reported on v2.1.261
Maintainer reply None cached
Activity 0 comments · opened Sep 17, 2026

Summary

A single, continuously-open Claude Code tab in the VS Code extension silently became attached to a different underlying session, with no action taken by me to close, reopen, or switch anything. This caused real confusion: I asked the assistant to do something, it (from its perspective) had no record of a change that had actually been made moments earlier in "the same conversation," and we spent a long time trying to reconstruct what had happened before finding the second session file.

Environment

  • Claude Code VS Code extension, version 2.1.261
  • macOS (Darwin 25.6.0)
  • Workspace: /Users/julielegendre/mgnl-docs

Timeline (from the two session JSONL files under ~/.claude/projects/-Users-julielegendre-mgnl-docs/)

  • Session A: fc0340b7-32d4-4463-a5e7-7fd2e1926902 — active from 2026-09-15 14:39 UTC, last activity before the gap ~2026-09-15 15:00 UTC.
  • Session B: f868bcbd-64ac-40f9-aa0e-dc28d882fb01 — a separate, pre-existing session (history going back to 2026-09-12), active again 2026-09-16 07:38–08:23 UTC, working on the same repo. It made a real commit (git commit, hash 1a6297a) at 08:14:35 UTC.
  • Session B's last activity: 08:23:20 UTC.
  • Session A resumes: 08:26:32 UTC — 3 minutes later.

Both sessions share identical entrypoint: claude-vscode, version: 2.1.261, and cwd. I did not close the tab, open a new one, or otherwise take any action that should have changed which session was active. From my side this read as one uninterrupted conversation; the assistant's later inspection of its own transcript showed no gap, error, or restart marker in session A's log around that boundary, and no crash indicators in session B's log either.

Impact

The assistant (working from session A) had no memory of work actually done in session B — including a real commit to the branch we were both working on. When I said "we did this together," the assistant initially couldn't find any evidence of that in its own session and it took considerable back-and-forth (and me insisting) before it located the other session's transcript file on disk and confirmed the commit had, in fact, been made by "the same tab," just under a different session ID.

What I'd like investigated

What can cause a VS Code Claude Code tab to become attached to a different session ID than the one it started with, without the user closing/reopening the tab or explicitly switching sessions? Whether that's an extension-host restart, a reconnect-to-stale-session bug, or something else, there was no user-visible indication that it had happened.

Suggested improvement

If a tab's active session ever changes underneath it, surface that to the user directly (e.g., a system message noting the session ID changed), rather than continuing as if nothing happened.

View original on GitHub ↗