[FEATURE] VS Code extension: add setting to disable auto-attach of open file / selection

[interconnectedMe]

Preflight Checklist

• I have searched existing requests and this feature hasn't been requested yet
• This is a single feature request (not multiple features)

Problem Statement

The VS Code sidebar chat automatically includes the currently open file and any text selection as context on every prompt. The only way to suppress this is the per-prompt eye-icon toggle, which resets after each message. There is no persistent setting to disable it.

Proposed Solution

Add a persistent VS Code extension setting (e.g. claude-code.autoAttachContext: false) that disables automatic inclusion of the active editor file and selection. The default can remain true to preserve current behaviour for users who want it.

Alternative Solutions

Make the eye-icon toggle "sticky" so it remembers the user's last choice across messages
Add a per-workspace setting so some projects auto-attach and others don't

Priority

Critical - Blocking my work

Feature Category

CLI commands and flags

Use Case Example

I frequently keep reference files open in tabs (docs, config, notes) that are unrelated to my current Claude conversation. Every single message I send requires an extra click on the eye icon to hide irrelevant context. Over a session with dozens of messages this adds up to significant friction.

Additional Context

The @-mention system already provides an explicit way to include files when needed, so disabling auto-attach doesn't remove any capability — it just makes inclusion opt-in rather than opt-out.

[github-actions]

Found 3 possible duplicate issues:

1. [FEATURE] - Add Setting to Disable Automatic IDE Selection Context #20944
2. [BUG] VS Code extension - ignore current file directive reverted #17630
3. VSCode extension consumes excessive tokens in background #19908

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[ldasilva-net]

Currently, when a file is listed in .claudeignore AND explicitly denied in .claude/settings.json permissions:

// .claudeignore
conclusiones.txt

// .claude/settings.json
"deny": ["Read(conclusiones.txt)"]

Claude Code correctly blocks its own tools from reading the file. However, when the user opens that same file in VS
Code/Cursor, the IDE extension still injects the full file contents into the conversation context as a system
reminder, completely bypassing both ignore rules.

This means sensitive or private files that are explicitly configured to be hidden from Claude are still exposed
whenever the user happens to open them in the editor.

Expected behavior: Files matching .claudeignore patterns (and deny rules in settings.json) should be
excluded from IDE auto-attach context, just as they are blocked from direct tool access. The ignore configuration
should be a single source of truth across all context injection paths — not just tool calls.

This would also make the per-prompt eye-icon toggle unnecessary for files that are already explicitly ignored.

[nratzan]

These posts keep getting closed. They should not be closed - it should be fixed.

[alicercedigital]

This is a must! This feature is poisoning everyone context. We could do something like:
claude-code.autoAttachContext: fals

[z2k-gwp]

I can't tell you how this is the bane of our existence in our development team. Every hour one of us screams ARGH!!! because we forgot to click this off. I'd pay an extra month of max++ for just this enhancement

[interconnectedMe]

You legends @claude ;-)

That made me smile when I updated to 2.1.70, had to check it wasn't a bug ;-)

No more typey-typey > tab space space space > tab space > tab tab tab space.

Now I have to relearn a little muscle-memory ;-)

[interconnectedMe]

No, it's back again - or maybe it only hides if using Sonnet Vs Opus, idk, but now I have an attachment on every chat session again, for a file that hasn't been open for hours, or since yesterday....