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

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/20944
2. https://github.com/anthropics/claude-code/issues/17630
3. https://github.com/anthropics/claude-code/issues/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

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.

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

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

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

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 ;-)

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....

This is a security issue, I just pulled in a secret file and it got read by claude. By default this should be off.

please make this opt-in. i mostly do not want any file added as context. and often a file is listed that is not open nor relevant.

+1 on this. My workflow is almost entirely multi-file, broad changes - the open file is rarely (if ever) relevant to what I'm prompting about. I find myself toggling the eye icon off on every single message, which gets old fast.

A persistent setting like claudeCode.autoAttachContext: false would be a big quality-of-life improvement. The current per-message toggle resetting each time is the core friction - I'd just like to set it once and forget it.

+1 on this. Just discovered that my .env.gcp.prd.gcp file was being automatically sent as ide_opened_file context every time I opened a new Claude Code session in VSCode.

Beyond the convenience aspect, this is a security concern — users working with sensitive files (.env, credential configs, cloud deployment files) may unknowingly expose secrets to the model context. Files that are .gitignore-d are often sensitive for a reason.

Suggestions:

1. A simple toggle like claude.contextProviders.openFiles: false
2. Glob-based exclusion patterns (e.g., **/.env*, **/credentials*)
3. Respecting .gitignore patterns by default — if a file is excluded from version control, it probably shouldn't be auto-attached as context either

Any of these would significantly reduce the risk of accidental secret exposure.

+1 — this is a significant UX issue. Clicking a file in the explorer to copy/paste code auto-injects it into the conversation context, which derails the current thread. The per-message eye icon toggle is not a viable workaround since it resets every message. A persistent setting like claudeCode.autoAttachContext: false would solve this cleanly.

+1 to this - the feature should absolutely not be on by default.

It's so validating that I'm not the only one banging my head against the wall at this.

Normally I'd just +1 and move on, but on the off chance that Claude Code team doesn't even have human reviewers I'm chiming in to let our AI Overlords know what a pain in the ass this is, that it's still relevant, still a tremendous workflow killer, and should be a very simple and low risk fix with outsized value to users. Ergo, hop on it, @claude

Another +1 to keep this thread alive. I'm running out of hair to pull out, please disable this feature or create a setting to disable it. It's a hoop we have to jump through every time we start a new chat session and it's becoming a burden

Also going crazy using this. Please fix it ASAP. It creates an incredibly negative user experience.

Agreed — a persistent setting for this would be a big quality-of-life improvement. The per-prompt eye icon toggle is easy to forget and adds friction.

I'm using claude in the terminal of VS Code instead of using the VS Code extension to avoid this issue. Would be nice if it could be fixed.

THIS IS A MUST!

We’ve lost too many tokens because of this. Many times, we send the prompt without disabling this dumb feature that is forced on by default. Then we have to cancel and resend it because this adds noise to the prompt.

Be able to disabling this will likely improve results for almost all users, as it removes this noise and reduces token usage.

Codex already has a switch that lets you toggle off IDE context—this simple feature makes it work much better.

I've found a workaround that I'm quite happy with. Instead of using the sidebar version of Claude Code in VSCode, I've switched to using the 'panel' mode where claude code appears as tabs. This works well with the claude code session manager sidebar. I've got in the habit of using Cmd+K Shift+Enter to pin my claude tabs. I also have 'Pinned Tabs On Separate Row' enabled which moves my pinned claude tabs above my other tabs.

Benefit of this approach is that I can have multiple claude tabs at once, and importantly, claude as a tab doesn't include the current file as I have to explicitly move to the claude tab. If I use split tabs however, the file in the other split gets attached to my claude tab.

i cannot fathom how this issue has been open this long without being prioritized, the current state is effectively an auto context poisoning attack who decided this should be the default?

this problem is the biggest validation that this should be opensource, allowing us the ability to fix our own problems is a kindness all loyal claude code developers deserve

I'm genuinely baffled. The team has rapidly shipped an entire UI rewrite and a plethora of features, yet somehow failed to make the auto-attach of open files configurable for months.

Forcing users to manually click the eye icon on every message to prevent context poisoning, wasted tokens, and the serious security risk of accidentally exposing sensitive files (even those in .claudeignore) is causing massive frustration.

Surely this could be resolved by adding something as simple as a persistent toggle (e.g., claude-code.autoAttachContext: false).

At this point, the delay in resolving such major workflow disruption is becoming increasingly difficult to understand. Please can this be addressed as a matter of urgency.

+1 extremely pressing issue. Are we not fixing it in order to allow Claude to vacuum up large collections of user credentials for some nefarious future use? Why else would a simple fix go un-addressed for so long? Would take a couple minutes for Claude to write and submit the PR based on the feedback in this issue...

Sorry for the people I'll notify 🙏
Just adding a message to share my pain and prevent this issue from going stale.
A setting, or at least a command/keyboard shortcut would be nice.

+1 for this issue. I want to control when context is added and just want the default to be not to add the open file as context.

Don't know how you guys use claude code, but I use VS Code > Terminal > Terminal and I type in claude there and that is how I use it. Now we all have this issue that it shares context of VS code. I tried disabling the extension, various env vars, and a config setting, but what actually worked was chmod 000 ~/.claude/ide to block VS Code from writing its WebSocket connection lock file. I haven't restarted my mac yet, but I thought I would share.

Give it a try, and let me know.

Why is this happening? I can't confirm now, but claude says:
Claude Code ships with a built-in VS Code integration. When VS Code detects Claude Code is installed, it automatically starts a local WebSocket server and writes a lock file to ~/.claude/ide/ so the CLI can find and connect to it. It's baked into VS Code's terminal integration, not something you opt into.

Given the continued lack of any official response, I am wondering if this issue is slipping under the radar because it is currently labelled as an enhancement and the title is prefixed with [FEATURE].

Because the current behaviour actively bypasses .claudeignore rules, causes context poisoning, is a massive security concern and results in unintended token drain, I would strongly argue that this should be reclassified as a bug rather than a feature request.

Could a maintainer please review the triage labels on this? Alternatively, if GitHub Issues is not the best place for this, is there another channel to escalate a fix that is causing the community so much daily friction?

It also bothers me that in the few cases I do intentionally add my open file / selection to the prompt, Claude simply assumes it's not relevant to the prompt/context and ignores it.

Please, it's annoying. I don't want to detach files everytime.

+1 — running into this on the VS Code extension (2.1.120) on macOS. Keeping reference files open in adjacent tabs while chatting about something else means every message either picks up irrelevant context or needs a per-prompt eye-icon click that does not stick.

A persistent claude-code.autoAttachContext: false would fix it cleanly. Related: #39267 covers the per-pill X gap, which is the other half of the same UX problem — together a global toggle plus a per-pill dismiss would let users handle both "I never want this" and "I want it usually but not for this message" without resetting the conversation.

This is the most annoying bug I've ever seen, I clicked on a file in a conversation with claude, then opened a new session for something else, them boom it added a 22000 lines file into the session for nothing.

Not ideal, but I use this workaround for now: https://github.com/dorian-marchal/vscode-claude-code-no-auto-attach
That's a small VSCode extension that patch the currently installed VScode extension to avoid that.

Working fix: default the auto-attach chip to OFF (ext 2.1.123)

This addresses both <ide_opened_file> (active file) and <ide_selection> (highlighted text) auto-injection — they share the same producer.

Why this matters beyond UX. #36523 documented that .claudeignore and deny-rules in settings.json do not suppress <ide_opened_file> — credential files like .env are silently injected into every message when open in the editor. Defaulting the chip to OFF closes that exposure.

What does NOT work (frequently suggested workaround): CLAUDE_CODE_DISABLE_ATTACHMENTS=1. The env var IS honored by the CLI binary's WC_() attachment pipeline, but the <ide_opened_file> tag arrives pre-baked from webview/index.js as plain text before the binary sees it. Verified empirically — env var present in /proc/<pid>/environ, tags still injected.

The fix

The chip's state in webview/index.js is declared as [P,_]=n1.useState(!0) (true = ON by default). The submit handler computes let k5 = P && !isSlash and passes it through send() → VB1(), which gates injection on if(J). The original code already handles a falsy J correctly — only the default value is wrong.

Flipping useState(!0) → useState(!1) is a length-preserving 1-byte patch:

• Chip starts OFF on every new chat.
• Toggle button stays fully functional — click ON to attach the open file for the current chat.
• Other attachments unaffected: paste images, drag-drop files, @-mention, plain text.

WV=$(find ~/.vscode{,-server}/extensions -path '*anthropic.claude-code-*/webview/index.js' 2>/dev/null | tail -1)
cp "$WV" "$WV.bak"
perl -i -pe 's{useRef\(!0\),\[([A-Za-z_\$][\w\$]*),([A-Za-z_\$][\w\$]*)\]=([A-Za-z_\$][\w\$]*)\.useState\(!0\)}{useRef(!0),[$1,$2]=$3.useState(!1)}' "$WV"

Then Ctrl+Shift+P → Developer: Reload Window. To revert: cp "$WV.bak" "$WV" and reload.

Anchor: useRef(!0),[X,Y]=N.useState(!0) — unique across webview/index.js because the preceding useRef(!0) discriminates the chat-input component among 6 total useState(!0) hits. Identifier names (P, _, n1 in 2.1.123) are wildcarded with regex backreferences for stability across minifier renames. Re-run after each extension auto-update.

<details>
<summary><b>Hardcore alternative: chip non-functional, zero injection possibility</b></summary>

If you want zero chance of accidental injection (chip stays visible but its toggle does nothing), excise the entire if(J){...} block from VB1() instead:

WV=$(find ~/.vscode{,-server}/extensions -path '*anthropic.claude-code-*/webview/index.js' 2>/dev/null | tail -1)
cp "$WV" "$WV.bak"
perl -0 -i -pe 's{if\(([A-Za-z_\$][\w\$]*)\)if\(\1\.selectedText\)([A-Za-z_\$][\w\$]*)\.push\(\{type:"text",text:`<ide_selection>The user selected the lines \$\{\1\.startLine\} to \$\{\1\.endLine\} from \$\{\1\.filePath\}:\n\$\{\1\.selectedText\}\n\nThis may or may not be related to the current task\.</ide_selection>`\}\);else \2\.push\(\{type:"text",text:`<ide_opened_file>The user opened the file \$\{\1\.filePath\} in the IDE\. This may or may not be related to the current task\.</ide_opened_file>`\}\);}{}' "$WV"

~405-byte deletion. More aggressive — chip remains visible but its toggle does nothing.

</details>

Caveats

Targets ext 2.1.123 minified bundle. Anchors are on stable English text + property names, but bundle restructures will eventually break them — re-validate with grep -c 'useRef(!0),\[.,.\]=.\.useState(!1)' "$WV" after each extension auto-update (expect 1). Undocumented, use at your own risk.

Happy to clarify the anchor logic or help if folks hit different versions.

please can you update vs code with the fix ? sounds complicated to implement.

please can you update vs code with the fix ? sounds complicated to implement.

@nostradam Just point Claude to my comment - and it will implement this fix in 3-5 min - then after testing, ask Claude to make this fix persistent between updates - that's it - hope it helps

I am genuinely starting to believe this is some money-making context-draining deliberate bug. The sheer amount of context waste from attaching every open file is insane.

Not an accusation, just a belief...

Anthropic, your bug is actively costing people £££, so why won't you fix it?

I am genuinely starting to believe this is some money-making context-draining deliberate bug. The sheer amount of context waste from attaching every open file is insane. Not an accusation, just a belief... Anthropic, your bug is actively costing people £££, so why won't you fix it?

I probably wasted millions of tokens because of this shit bug.

# Working fix: default the auto-attach chip to OFF (ext 2.1.123) This addresses both <ide_opened_file> (active file) and <ide_selection> (highlighted text) auto-injection — they share the same producer. Why this matters beyond UX. #36523 documented that .claudeignore and deny-rules in settings.json do not suppress <ide_opened_file> — credential files like .env are silently injected into every message when open in the editor. Defaulting the chip to OFF closes that exposure. What does NOT work (frequently suggested workaround): CLAUDE_CODE_DISABLE_ATTACHMENTS=1. The env var IS honored by the CLI binary's WC_() attachment pipeline, but the <ide_opened_file> tag arrives pre-baked from webview/index.js as plain text _before_ the binary sees it. Verified empirically — env var present in /proc/<pid>/environ, tags still injected. ## The fix The chip's state in webview/index.js is declared as [P,_]=n1.useState(!0) (true = ON by default). The submit handler computes let k5 = P && !isSlash and passes it through send() → VB1(), which gates injection on if(J). The original code already handles a falsy J correctly — only the _default value_ is wrong. Flipping useState(!0) → useState(!1) is a length-preserving 1-byte patch: Chip starts OFF on every new chat. Toggle button stays fully functional — click ON to attach the open file for the current chat. Other attachments unaffected: paste images, drag-drop files, @-mention, plain text. WV=$(find ~/.vscode{,-server}/extensions -path 'anthropic.claude-code-/webview/index.js' 2>/dev/null | tail -1) cp "$WV" "$WV.bak" perl -i -pe 's{useRef\(!0\),\[([A-Za-z_\$][\w\$]),([A-Za-z_\$][\w\$])\]=([A-Za-z_\$][\w\$])\.useState\(!0\)}{useRef(!0),[$1,$2]=$3.useState(!1)}' "$WV" Then Ctrl+Shift+P → Developer: Reload Window. To revert: cp "$WV.bak" "$WV" and reload. Anchor: useRef(!0),[X,Y]=N.useState(!0) — unique across webview/index.js because the preceding useRef(!0) discriminates the chat-input component among 6 total useState(!0) hits. Identifier names (P, _, n1 in 2.1.123) are wildcarded with regex backreferences for stability across minifier renames. Re-run after each extension auto-update. Hardcore alternative: chip non-functional, zero injection possibility If you want zero chance of accidental injection (chip stays visible but its toggle does nothing), excise the entire if(J){...} block from VB1() instead: WV=$(find ~/.vscode{,-server}/extensions -path 'anthropic.claude-code-/webview/index.js' 2>/dev/null | tail -1) cp "$WV" "$WV.bak" perl -0 -i -pe 's{if\(([A-Za-z_\$][\w\$])\)if\(\1\.selectedText\)([A-Za-z_\$][\w\$])\.push\(\{type:"text",text:<ide_selection>The user selected the lines \$\{\1\.startLine\} to \$\{\1\.endLine\} from \$\{\1\.filePath\}:\n\$\{\1\.selectedText\}\n\nThis may or may not be related to the current task\.</ide_selection>\}\);else \2\.push\(\{type:"text",text:<ide_opened_file>The user opened the file \$\{\1\.filePath\} in the IDE\. This may or may not be related to the current task\.</ide_opened_file>\}\);}{}' "$WV" ~405-byte deletion. More aggressive — chip remains visible but its toggle does nothing. ## Caveats Targets ext 2.1.123 minified bundle. Anchors are on stable English text + property names, but bundle restructures will eventually break them — re-validate with grep -c 'useRef(!0),\[.,.\]=.\.useState(!1)' "$WV" after each extension auto-update (expect 1). Undocumented, use at your own risk. Happy to clarify the anchor logic or help if folks hit different versions.

Chip disabled needs to be made the default functionality. There is absolutely no user-facing reason for this not to be the default.

Why isn't there a config to turn this off by default? I have to remember to disable the file EVERY time I start a chat. Is this costing us any session context / tokens? We should be able to disable it.

Lessons learned applying this to 2.1.128 (for future agents/users)

The perl one-liner from the fix works unchanged on 2.1.128 — same variable names (P, _, n1), same anchor. However, the verification step grep -c 'useRef(!0),\[.,.\]=.\.useState(!1)' silently reports 0 even after a successful patch, because the dot . in that grep doesn't match _ (underscore) when the shell expands the pattern differently on some systems. Use this to verify instead:

grep -c 'A=n1\.useRef(!0),\[P,_\]=n1\.useState(!1)' "$WV"
Expected output: 1 = patched, 0 = not patched.

Also: cp "$WV" "$WV.bak" runs before perl -i in the one-liner chain, so the backup is clean even if run as a single &&-chained command. No issue there.

Quick sanity check for any version:

grep -oP 'A=\w+\.useRef\(!0\),\[.+?\]=\w+\.useState\(!.\)' "$WV"
Output ending in !0 = unpatched, !1 = already patched.

I don't want to be a conspiracy theorist, but it's in Anthropic's best interest not to do this (more training data, you burn tokens faster), but will tag along this to both prevent their auto-close-instead-of-fix-issues bot from being grim reaper on this one.

+1, this is a daily friction point.

I want to add a specific failure mode that I don't see covered in the original report and that I think is the strongest argument for making this opt-in rather than opt-out: the auto-attached file can be silently swapped mid-prompt.

Concrete scenario (happens to me regularly):

1. I open FileA.java --- the extension auto-attaches it to the prompt.
2. I start typing a prompt about FileA.
3. Mid-prompt, I switch to FileB.java in another tab to double-check something (a method signature, a related type, whatever).
4. I switch back, finish the prompt, and hit send.
5. Claude receives FileB as context, not FileA --- because the auto-attached file followed the active editor, silently, without any confirmation step.

The attachment chip updates, but if you're focused on writing the prompt you don't necessarily look at it before sending. The mental model is "I attached FileA earlier, it's still there" --- but the extension's model is "whatever is active right now is what gets sent."

This isn't just friction. It's:

• A correctness problem --- Claude answers based on the wrong file and the user may not immediately realize why the response is off.
• A privacy/security problem --- if I happen to glance at a file containing credentials, a .env, or a sensitive customer file while composing an unrelated prompt, that file gets shipped to the model without explicit consent. See also #36523.
• Asymmetric with the rest of the UX --- @-mentions and Shift+drag are explicit, deliberate actions. The auto-attach is the only context source that changes under you without an explicit user action.

Proposed minimum fix, in order of preference:

1. A persistent setting claudeCode.autoAttachActiveEditor: false (default true for backward compatibility). This is what the original issue asks for and would solve everything.
2. If (1) is too invasive: make the auto-attached file sticky to the editor that was active when the prompt input was first focused, instead of following the active editor in real time. Switching tabs would no longer silently swap the attachment; the user would have to explicitly re-attach.
3. As a complement to either: make the eye-slash toggle persist across messages within a session.

The @-mention system already covers explicit inclusion perfectly, so disabling auto-attach removes zero capability --- it just makes context inclusion an intentional act rather than a default that quietly mutates.

Extension version: anthropic.claude-code 2.1.143.

Bump, getting pretty frustrating to see some random file in the IDE has been attached to a claude session. I might have 2-4 active sessions on the go at once and it's often too late by the time I notice it's been attached.

Even weirder that from Claude - "Each one is tagged \"This may or may not be related to the current task\"" so you were clearly aware that random files might get attached and cause issue and you wrote an instruction to intentionally cause claude to have to consider if the file is even relevant rather than fixing the feature?

Should be a pretty basic toggle?

The issue isn't dead; it's critical that this is enabled by default. You can have an editor with a huge file and have tokens stolen from you without your knowledge from the start.

A particularly frustrating part for me is that the toggle re-enables itself when use the /clear command or simply switch session - you haven't opened a different tab or anything; why does the toggle _always_ re-enable itself on session swap? Even when you swap back to a session you previously disabled it on.

A default setting would be nice but it's not really necessary. It just needs to stop turning itself back on. Its state should be attached to the tab, not the session.

Confirmed that @xlurie's fix works great. I modified it to work with Cursor, and added a check for duplicate extensions, which Cursor doesn't always remove.

#!/usr/bin/env bash
#
# Patch the Claude Code Cursor extension's webview to fix initial state.
# See: https://github.com/anthropics/claude-code/issues/24726#issuecomment-4343376892

# Warn if multiple copies of the extension are installed.
ls -d ~/.cursor/extensions/anthropic.claude-code-* 2>/dev/null \
  | wc -l \
  | awk '{if ($1 > 1) print "Duplicate extensions found:", $1, "\nUninstall extension, then run `rm -rf ~/.cursor/extensions/anthropic.claude-code-*`, then reinstall extension and run this again."; exit}'

# Locate the most recently matched webview bundle across cursor / cursor-server installs.
WV=$(find ~/.cursor{,-server}/extensions \
       -path '*anthropic.claude-code-*/webview/index.js' 2>/dev/null \
     | tail -1)

# Back up the bundle, then flip useState(!0) -> useState(!1) for the matched useRef pattern.
cp "$WV" "$WV.bak"
perl -i -pe 's{useRef\(!0\),\[([A-Za-z_\$][\w\$]*),([A-Za-z_\$][\w\$]*)\]=([A-Za-z_\$][\w\$]*)\.useState\(!0\)}{useRef(!0),[$1,$2]=$3.useState(!1)}' "$WV"

I have auto-update off, so I periodically update the extension manually and run the script.

Tested on 2.1.156 (Opus 4.8)

The thing that annoys me the most about this feature is that Anthropic knows it's a problem, but their "solution" is to add "This may or may not be related to the current task." to the prompt, causing Claude to often not read the file when you actually did intentionally attach the file. You have to always remember to explicitly refer to the file in your prompt if you want Claude to read it.

Easiest solution:

Don't expand the feature, change the default behaviour.

Don't include the file in the context by default, just include it if the user clicks the eye-icon toggle.

Such a simple question, and don't even want to make any changes. really arrogant🤮.

This is a security concern.

Temporary fix guide: Stop Claude Code for VS Code from Auto-Attaching Your Open Files

How many times have you had a file open with secure data in it, like a .env file with registry keys, and forgot to turn it off? This is a security hazard. At least set the default to off!

Many months have passed since we, the people with this problem, started having it, but they refuse to solve it. We are not being heard.

대체 이게 왜 아직도 해결되지 않은걸까요.
무슨 고집이죠?

Not sure how many have already accidentally leaked their credentials to Anthropic due to this stupid issue which probably won't take more than afew hours of fix.
@claude could you please raise this to concerned people...or may be just...fix it please? Thanks!

Those auto-fixes are temporary and not safe. The safest, simplest way is to just ban Claude extension for VS Code (deleting it is not enough, it reappears immediately):

  "extensions.allowed": {
    "anthropic.claude-code": false,
    "*": true,
  },

Simple and forever.

This is very annoying. Hope it gets fixed soon.