[FEATURE] Persistent config option to disable IDE context sharing (opened files, selections)

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/68837
2. https://github.com/anthropics/claude-code/issues/24726
3. https://github.com/anthropics/claude-code/issues/20944

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

Related issues requesting similar functionality:

• #24726 (open since Feb 2026, 15+ comments, no dev response)
• #40869 (open since May 2026, reports of accidental credential leaks)
• #53518 (closed as stale without resolution)

This request differs in a specific way: the per-session eye icon toggle in the input field UI already exists, but it resets on every session restart or reboot. I'm asking for a persistent config option so I don't have to remember to disable it every time I open the editor.

Additionally, the eye icon toggle is only visible when there are open editors. If no files are open when I start the session, there is no indication that this behavior is active. As soon as I open a file, it gets shared silently before I even have a chance to toggle it off.

I use Claude Code as a sidebar panel alongside normal editor work. Every file I open or select text in gets silently sent as API context. When I have personal or sensitive documents open, there is no persistent way to prevent this from being shared. The toggle resetting on restart means the default is always "share everything" regardless of my preference.

Proof-of-concept patch (updated)

I traced the relevant code in the extension webview (version 2.1.159, webview/index.js).

What controls the behavior:

The includeSelection React state determines whether the currently opened file name and text selection are injected into the API request as <ide_opened_file> and <ide_selection> tags. This state is initialized via useState(!0) (i.e. true), meaning context sharing is always on when the extension loads.

The eye icon toggle in the input field calls a state setter to flip this value, but since it is component state (useState), it resets to true on every session start, window reload, or reboot.

Where it lives in the minified code (2.1.159):

In webview/index.js, the oe1 component (which receives {session:$, context:Z, ...}) initializes the state at byte offset ~4748401:

useRef(!0),[P,_]=n1.useState(!0),[M,w]=n1.useState(!1)
//                            ^^-- includeSelection default (true)

P is passed as includeSelection to the input component, which gates whether the selection/file data reaches the EB1 function (byte offset ~3154893) that builds the user message content array:

async function EB1($,Z,J,Y,X,Q,G){
  let q=[];
  if(J)  // J = includeSelection, when true:
    if(J.selectedText)
      q.push({type:"text",text:`<ide_selection>...`});
    else
      q.push({type:"text",text:`<ide_opened_file>...`});

What the patch does:

The oe1 component already has access to the session config via $.config.value?.claudeSettings?.effective, which mirrors all keys from ~/.claude/settings.json. The settings schema has "additionalProperties": {} at the root, so custom keys are accepted without schema changes.

The patch replaces the hardcoded useState(!0) with a check against a disableEditorContext key in settings.json:

// Before:
[P,_]=n1.useState(!0)

// After:
[P,_]=n1.useState(!($.config.value?.claudeSettings?.effective?.disableEditorContext===true))

When "disableEditorContext": true is in ~/.claude/settings.json, the toggle defaults to off. The eye icon toggle still works for per-message override. The setting persists across sessions and reboots.

To use:

1. Apply the patch: https://gist.github.com/ScrewTSW/3b9fc6f053fae26ef60f3e73e6f7d7e2
2. Add to ~/.claude/settings.json:

``json
"disableEditorContext": true
``

1. Reload VS Code/VSCodium

This is a workaround patch against minified code (written for 2.1.159, variable names will differ across versions). The proper fix from Anthropic would be adding disableEditorContext to the official settings schema and reading it natively in the source.

Update: image paste remount fix

The original patch had a bug where pasting an image or adding an attachment would reset the toggle back to ON.

The oe1 component has key={$.activeSession.value.internalId} as a React key. Pasting an image can cause React to remount the component, which re-evaluates the useState initial value. If $.config.value hasn't loaded yet at that point, the optional chaining falls through and the toggle defaults back to ON, silently re-enabling context sharing.

Fixed with a three-way check:

// Before (broken on remount):
$.config.value?.claudeSettings?.effective?.disableEditorContext===true?!1:!0

// After (safe default when config not loaded):
$.config.value?.claudeSettings?.effective?.disableEditorContext===true?!1:$.config.value?.claudeSettings?!0:!1

Logic:

1. disableEditorContext === true -> OFF
2. claudeSettings exists but key is absent -> ON (original behavior)
3. claudeSettings is undefined (config not loaded) -> OFF (safe default)

Gist updated with the fix.

Automatically injecting the active editor's full file content into every API request poses a serious security risk (e.g., when developers inadvertently have .env or credentials open in a tab).

Asking users to remember toggling off the context button for every message is error-prone. To improve workspace safety, could we consider:

Adding a global setting to disable automatic active-file context injection (e.g., claude.autoIncludeActiveFile: false)?

This would make the extension much safer for enterprise and security-conscious environments.

Automatically injecting the active editor's full file content into every API request poses a serious security risk (e.g., when developers inadvertently have .env or credentials open in a tab). Asking users to remember toggling off the context button for every message is error-prone. To improve workspace safety, could we consider: Adding a global setting to disable automatic active-file context injection (e.g., claude.autoIncludeActiveFile: false)? This would make the extension much safer for enterprise and security-conscious environments.

my patch does it via a config entry, that could easily be added into VSCode/VSCodium settings interface and defaults it to off, with an easy per-case toggle at the usual Claude Code interface location. It behaves exactly like if you hide the file manually, only does it by default

I've updated the patcher gist to run against 2.1.220 (latest at time of making) and added version pinning option https://gist.github.com/ScrewTSW/3b9fc6f053fae26ef60f3e73e6f7d7e2

Unrelated to the issue, but I've also added --add-bars optional flag that enables usage statistics in the bottom bar
https://gist.github.com/ScrewTSW/3b9fc6f053fae26ef60f3e73e6f7d7e2

Third Party provider shows total conversation tokens used:
<img width="750" height="102" alt="Image" src="https://github.com/user-attachments/assets/86567cf4-ced8-4cf4-864a-7e0f29ce9fb4" />
Anthropic subscription shows the standard Account and Subscriptions bars:
<img width="700" height="108" alt="Image" src="https://github.com/user-attachments/assets/67f3d3cb-78b3-47f5-93b6-a668d5f6f27b" />

Thanks for raising this. There is one persistent option today, though it is per-path rather than global: adding a Read deny permission rule for a file or pattern prevents both the selected text and the open-file notice for that path from being sent to Claude, and permission rules persist in your settings across sessions.

See: https://code.claude.com/docs/en/vs-code#how-the-extension-and-cli-connect (the "Selection and open-file context" note) and https://code.claude.com/docs/en/permissions#read-and-edit

A global, persistent "never share editor context" setting is not available yet, so we'll leave this open to track that.

🤖 Generated with Claude Code

Thanks for raising this. There is one persistent option today, though it is per-path rather than global: adding a Read deny permission rule for a file or pattern prevents both the selected text and the open-file notice for that path from being sent to Claude, and permission rules persist in your settings across sessions. See: https://code.claude.com/docs/en/vs-code#how-the-extension-and-cli-connect (the "Selection and open-file context" note) and https://code.claude.com/docs/en/permissions#read-and-edit A global, persistent "never share editor context" setting is not available yet, so we'll leave this open to track that. 🤖 Generated with Claude Code

Thank you for the update.

How about this? https://github.com/anthropics/claude-code/issues/68838#issuecomment-5107193890 should I open feature request? Since this repository contains no source code, I cannot open a PR myself. In my opinion it's a very simple and useful visual feedback without having to open multiple menus while actively using the chat (since it has love for scrolling you away and popping up dialogs constantly which also closes any menus that are currently open)

Adding a use case that is neither privacy nor token cost, since both are already well covered above.

My routing signal to Claude is explicit: a set of markdown issue files, one topic per file, and the one I name in the prompt is the one I want worked on. The editor context adds a second, implicit routing signal — "the user is currently looking at file X" — and the two disagree most of the time, because the file I happen to have open is rarely the file I am asking about. The failure mode here is not a larger bill; it is an answer quietly bent toward the wrong topic. A wrong file pulled in by a tool call is visible in the transcript. This hint is not visible at the point where it does the damage.

On the Read deny workaround: it does not cover this case. The files I would have to deny are the same markdown files Claude legitimately reads when I ask it to. Denying them to suppress the implicit hint also removes the ability to read them on request. A deny rule says "never look at this file". What is missing is "read this file when I ask, but do not bring it up just because it is open in my editor". Those are different statements, and only the first one is currently expressible.

So the per-path option, useful as it is for secrets, does not substitute for a global persistent setting here. Making the existing eye toggle persist across sessions would be enough for my case.