[BUG] IDE selection state persists across file close + new CLI session — closed file's selection re-appears in subsequent context

Preflight Checklist

• [x] I have searched existing issues — neighbors are #52419 (deny-rule bypass for currently-open files), #24726 / #45344 / #53518 / #58620 (feature requests to disable auto-attach). This issue describes a different surface: stale selection state from a closed file appearing in a new session.
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code (CLI 2.1.138, VS Code extension 2.1.140)

What's Wrong?

Selection state from a closed editor tab appears to persist in the IDE bridge and surface in subsequent Claude Code sessions — including new CLI sessions started after the file is closed.

I observed this while doing a routine copy-paste workflow with an env file. The selection was made for clipboard purposes (copying a value between dashboards), not as intentional context for the assistant. Closing the file and opening a different one did not clear the bridged selection.

How I Encountered It

I was working on an unrelated task and wanted to test whether a CLI-mode session (claude in a terminal, no --ide flag) sees less IDE context than the VS Code chat panel. My sequence:

1. Earlier in the session, I had opened .env.production.local and selected two lines (Supabase key values) to copy-paste the value into another tool. This is a normal workflow when syncing env vars between local and a dashboard.
2. I closed that file.
3. I opened a different file in the editor (an unrelated TypeScript file).
4. I opened a terminal and ran claude to start a fresh CLI session.
5. I asked the session a generic question — something like "can you see the file open in my IDE?" — expecting either "no IDE context" or a reference to the currently-open TypeScript file.

Instead, the new session reported the path and selection content from the previously-closed env file — specifically the two lines I had selected for clipboard, including the Supabase publishable + service-role key values.

Why this is a problem

The IDE selection surface exists to share intentional context. In practice, users select text for many non-AI reasons — most commonly clipboard copy-paste. Treating those selections as durable, cross-session, post-close context creates a leak path that's hard to anticipate:

• Selection-for-clipboard is the most common selection event in normal use
• Closing the file is the user signal that "I'm done with this context"
• Starting a new CLI session is reasonably expected to be a clean slate

When all three signals are overridden by a cached selection from a previous tab, the user has no clear mental model for what's in context. In my case the cached selection was a service_role key, which I rotated as a precaution — but the cost of rotation is real, and most users wouldn't notice the leak in the first place.

What I'd hope to see

In rough priority order — even just (1) would be a significant improvement:

1. Clear selection state when the source file is closed. A closed file shouldn't have a live selection. This seems like the simplest invariant to enforce.
2. Don't serve IDE selection state to a new CLI session. A fresh claude invocation could reasonably treat the IDE bridge as un-initialized until the user takes an explicit action.
3. Honor .claudeignore and settings.json permissions.deny rules on the IDE-selection codepath — currently bypassed per #52419. This is a separate but adjacent ask; (1) and (2) would substantially mitigate even without it.
4. (Lower priority, covered by #24726 et al.) A persistent opt-out for IDE auto-attach as a defense-in-depth.

Steps to Reproduce

1. Open an env file (e.g. .env.production.local) in VS Code with the Claude Code extension installed.
2. Select two consecutive lines containing values you'd recognize (e.g. FOO_KEY=abc / BAR_KEY=def).
3. Close the file (the tab, not the window).
4. Open a different file in the editor.
5. Open a terminal in the same VS Code window and run claude (with no flags).
6. Ask the new session what file is open in the IDE.
7. Observe whether the reported selection contains values from the closed file.

Error Messages/Logs

N/A — no error is surfaced. The relevant signal is in the session's JSONL transcript at
~/.claude/projects/<workspace-key>/<session-id>.jsonl, which would show either an
<ide_selection> system-reminder containing the closed file's contents, or a Read
tool-use against that file path.

I did not capture the transcript at the time. If it would help to provide one for a controlled repro, I'm happy to follow up.

Claude Model

Not sure / Multiple models (default for the session)

Is this a regression?

Unknown — first time I've noticed this pattern.

Last Working Version

N/A

Claude Code Version

CLI: 2.1.138
VS Code extension: anthropic.claude-code-2.1.140-win32-x64

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell (in VS Code integrated terminal) — claude CLI session, not the extension chat panel

Additional Information

• Rotated the affected Supabase keys as a precaution.
• Related issues that informed this report: #24726, #39267, #40869, #44694, #45344, #52419, #53518, #58620. None describe the close-and-restart-into-stale-selection pattern specifically.
• Happy to help with a controlled repro or transcript capture if useful.