[BUG] Workspace file tags leak across sessions
Preflight Checklist
- [ ] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
Description
The workspace file chips/tags displayed in the chat input area are shared across all Claude Code sessions, not scoped per-session. This causes files created or opened in one session to appear in the input box of unrelated sessions.
Steps to Reproduce
- Open VS Code with Claude Code extension
- Open Session A (e.g., "futures calculator" workspace)
- Create or edit a file (e.g.,
index.html) — file tag appears in Session A's input area - Switch to Session B (e.g., "Xiaohongshu workflow") in the same VS Code window
- Observe that Session B's chat input area now also shows the
index.htmlfile tag from Session A
Expected Behavior
Each Claude Code session should have its own isolated workspace file context. Files created in Session A should not appear in Session B's input area.
Actual Behavior
All sessions share the same workspace file tags. This is problematic because:
- Accidental message pollution: When typing in Session B, the shared file tag can be accidentally included in the message sent to Claude, providing irrelevant file context
- Confusion: Users see file references in their chat that have nothing to do with the current conversation
- No workaround: There is no setting (
claudeCode.*) to disable workspace file tags entirely
Environment
- VS Code Extension: Claude Code v2.1.153
- Platform: Windows 11
Proposed Fix
- Scope workspace file tags to each individual Claude Code session
- Or provide a setting like
claudeCode.showWorkspaceFilesto disable the feature entirely
Additional Context
There is no existing claudeCode.* VS Code setting to control this behavior. The feature appears to be hardcoded in the extension's webview.
What Should Happen?
Each Claude Code session should have its own isolated workspace file context. Files created or opened in one session should not appear in the input area of other sessions.
Error Messages/Logs
Steps to Reproduce
Description
The workspace file chips/tags displayed in the chat input area are shared across all Claude Code sessions, not scoped per-session. This causes files created or opened in one session to appear in the input box of unrelated sessions.
Steps to Reproduce
- Open VS Code with Claude Code extension
- Open Session A (e.g., "futures calculator" workspace)
- Create or edit a file (e.g.,
index.html) — file tag appears in Session A's input area - Switch to Session B (e.g., "Xiaohongshu workflow") in the same VS Code window
- Observe that Session B's chat input area now also shows the
index.htmlfile tag from Session A
Expected Behavior
Each Claude Code session should have its own isolated workspace file context. Files created in Session A should not appear in Session B's input area.
Actual Behavior
All sessions share the same workspace file tags. This is problematic because:
- Accidental message pollution: When typing in Session B, the shared file tag can be accidentally included in the message sent to Claude, providing irrelevant file context
- Confusion: Users see file references in their chat that have nothing to do with the current conversation
- No workaround: There is no setting (
claudeCode.*) to disable workspace file tags entirely
Environment
- VS Code Extension: Claude Code v2.1.153
- Platform: Windows 11
Proposed Fix
- Scope workspace file tags to each individual Claude Code session
- Or provide a setting like
claudeCode.showWorkspaceFilesto disable the feature entirely
Additional Context
There is no existing claudeCode.* VS Code setting to control this behavior. The feature appears to be hardcoded in the extension's webview.
Claude Model
None
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
2.1.153
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
VS Code integrated terminal
Additional Information
_No response_
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗