[severe; security] GitHub Copilot per-workspace enablement doesn't persist in v1.117+, forcing user to open entire system to information leakage

[garretwilson]

v1.117 breaks per-workspace opt-in because the per-workspace setting does not persist after workspace restart. (Remember that v1.116 forced AI to be enabled on a system basis, breaking the ability to opt-in AI on a per-workspace basis; see #310143 .)

1. Open Workspace 1 in a VS Code instance. (This workspace has never been used with GitHub Copilot.)
2. Ctrl+X to bring up installed extensions.
3. Search for "GitHub Copilot Chat".
4. Right-click and select "Disable AI Features. (Optional: Restart by closing and opening Workspace 1 in a VS Code instance.)
5. Open Workspace 2 in a separate VS Code instance. (This workspace has a long history of AI.)
6. Ctrl+X to bring up installed extensions.
7. Search for "GitHub Copilot Chat".
8. Right-click and select "Enable AI Features (Workspace)".
9. The previous chat history appears in the side panel.
10. Close the VS Code instance.
11. Reopen Workspace 2 in a separate VS Code instance.

Expected: The side chat panel continues to show the ongoing chat history.

Actual: The side chat panel is blank. AI features have been toggled back off for that workspace.

Bug: Restarting the session discards the "Enable AI Features (Workspace)" setting; it is not persisted.

Workaround: Each time an AI workspace is loaded, manually reenable AI. Unfortunately there is no workaround, because GitHub Copilot does not function correctly if not enabled when VS Code starts, due to #312610.

Note that I am relying on per-workspace storage in ``C:\Users\user\AppData\Roaming\Code\User\workspaceStorage. I do not have a separate .vscode` for the workspace. This should make no difference.

Version: 1.117.0 (user setup)
Commit: 10c8e557c8b9f9ed0a87f61f1c9a44bde731c409
Date: 2026-04-21T16:12:14-07:00
Electron: 39.8.7
ElectronBuildId: 13841579
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26200

[garretwilson]

@TylerLeonhardt have you reviewed this ticket?

@bpasero and @sandy081, since you were both involved with #310143 (the source of this issue), can you acknowledge this problem and verify that it will be addressed quickly?

As you know security issues should have high priority. I'm asking because there should have been a fix already, but there has been no acknowledgement at all on this ticket; I wonder if the system/bot swept it under the rug somehow.

[garretwilson]

This bug has other serious ramifications: if GitHub Copilot is not enabled when the workspace is opened (i.e. if I enable it after opening the workspace, as this bug is forcing me to do), then new sessions never show up in the sessions list! I have filed #312610 , as that must be some other race condition that checks the GitHub Copilot status upon startup but never updates it. Nevertheless, that bug is severely compounded by this bug.

[garretwilson]

This is still broken in v1.118, forcing a user to leave an entire system open to information leakage. @TylerLeonhardt , @bpasero , @sandy081

Version: 1.118.0 (user setup)
Commit: 9b8ae15a8cf95b9bce1b590b42954530f440e816
Date: 2026-04-28T15:54:22-07:00
Electron: 39.8.8
ElectronBuildId: 13870025
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26200

[garretwilson]

I have found a workaround! It appears that although the mechanism for persisting the GitHub Copilot Chat extension enabled status on a per-workspace basis is broken, but one can still opt-in by overriding chat.disableAIFeatures to false in per-workspace settings.

The trick is that you have to do this manually in the settings.json file; it cannot be done inside the settings UI, because the Boolean checkbox is by default turned off. They made the chat.disableAIFeatures an opt-out feature rather than an opt-in feature, so there is no way for the UI to distinguish between "not set" or "unset". 🤦 Thus it has to be explicitly set to the desired value in the per-workspace settings.json file.

This issue could be mitigated with a tri-state checkbox in the settings UI. It wouldn't need to be mitigated if chat.disableAIFeatures had been made opt-in instead of opt-out, as security best-practices advocate. (After all, even an opt-in mechanism could be enabled opted-in system-wide if the user desires. Making a backwards Boolean settings flag to set to false to mean "enabled" is quintessential bad design.) And of course if the GitHub Copilot Chat extension enabled status persistence mechanism weren't broken, that approach would work as well. So this entire workaround is required because of a security-averse design coupled with a backwards setting naming decision on top of an anemic UI on top of a broken extension disable/enable persistence mechanism.

Here is the workaround:

1. In the global (user) settings, check chat.disableAIFeatures or set "chat.disableAIFeatures": true in the user settings.json file. Shortcut: Command Preferences: Open User Settings (JSON).
2. For per-folder workspaces, add "chat.disableAIFeatures": false to .vscode/settings.json. For multi-root workspaces, add "chat.disableAIFeatures": false to the "settings" section in .code-workspace or project.code-workspace. Shortcut: Command Preferences: Open Workspace Settings (JSON).

.vscode/settings.json

{
  …,
  "chat.disableAIFeatures": false
}

.code-workspace

{
  "folders": [
    …,
  ],
  "settings": {
    …,
    "chat.disableAIFeatures": false
  }
}

[dmitrivMS]

@garretwilson I have a draft here, can use help in testing it if you're interested.