One Link Can Bypass VS Code Workspace Trust. Here Is the Setting That Removes the Trigger

One Ctrl+click on a link in an untrusted folder can get past VS Code Workspace Trust and install an unsigned extension. The extension then runs code as you. That is the finding Remedio published on September 17, 2026. Microsoft rated it moderate and did not assign a CVE. Remedio reported no fix in the latest stable release as of that date.

This piece walks through how the attack gets around VS Code Workspace Trust and what Microsoft said. It covers which versions and editors the research names. It also covers two settings that reduce the risk, where each belongs, and what we could not confirm.

The short version: set "editor.links": false in your user settings today. If you manage a team, also deploy an extension allowlist through extensions.allowed or the AllowedExtensions policy. The first removes the click that starts the chain. The second limits what can be installed if something else gets through. Neither is a patch, and one question about project settings is still open.

How the bypass gets around VS Code Workspace Trust

The research comes from Omri Dar, Remedio’s lead vulnerability researcher. His post is titled Bypassing VS Code Workspace Trust with a Single Link. It chains two gaps. Neither one needs memory corruption or a zero-day.

The first gap is the link itself. VS Code supports command: links, which call internal editor commands instead of opening a web page. The rendered Markdown preview strips these links. Microsoft hardened it after CVE-2022-41034. That was a remote code execution bug fixed in VS Code 1.72.1, according to the NVD entry. The plain source editor, where you see the raw Markdown text, did not get the same treatment.

The second gap is the command the link calls. Remedio’s link runs workbench.extensions.installExtension and points it at a .vsix file sitting in the project folder. Per Remedio, a local VSIX is accepted with "No signature check. No publisher check." That path has one trust check. It only fires if the extension’s manifest says it does not support untrusted folders. So the attacker’s extension says it does.

How the link reaches the screen

A malicious link is only useful if someone sees it. Remedio used two small tricks to put it in front of the victim without any navigation.

First, the folder ships a .vscode/settings.json file that sets workbench.startupEditor to readme. VS Code then opens the README on its own when the folder loads. Second, the file is named README.markdown rather than README.md. According to Remedio, that name sends it to the source editor instead of the hardened preview.

The link text can say anything. Remedio’s example reads "Install project dependencies," which is the kind of line developers see in real projects every week. Hovering shows a small "Execute command" tooltip. Remedio calls the hint too weak. "The problem with that hint is that it is a mouse-over tooltip, not a warning, and in the shipped code the hint omits the command’s details."

What happens after the click

The extension installs silently while the folder stays in Restricted Mode. Remedio says the folder "never entered the trusted-folders list" during its test.

From there, the extension behaves like any installed extension. It activates at once, with no restart. It installs globally, so it runs again every time VS Code starts, whichever project is open. It survives closing the folder and rebooting the machine. It stays until someone notices it in the extensions list and removes it.

What it can reach is the rest of the problem. Per Remedio, the attacker ends up "running code on your machine, as you, with access to your files, your SSH keys, your cloud tokens, and your source code."

The absolute path limit, and why it is small comfort

The fully automatic version has one real constraint. The command: link takes its file path literally. So the attacker must know the absolute path where the victim will unzip or clone the folder. Remedio calls this version targeted rather than broadly distributable. It also tried a network share to get around the limit. VS Code’s UNC host allowlist blocked that attempt.

That limit narrows the attack. It does not remove it. Many developers keep projects in predictable places, such as a folder under their user profile. The proof of concept in Remedio’s post uses a Windows path of that kind. The two underlying primitives have no such limit, according to Remedio. One runs a command from an untrusted folder. The other installs unsigned code without a prompt.

What VS Code Workspace Trust is supposed to do

Microsoft updated its VS Code Workspace Trust documentation on September 16, 2026. It says Restricted Mode "disables or limits the operation of several VS Code features: AI agents, terminal, tasks, debugging, workspace settings, and extensions." Tasks and debugging ask for trust first. The terminal is blocked by default. Workspace settings tagged requireTrustedWorkspace are not applied, and extensions without Workspace Trust support are disabled or limited.

The same page is candid about its limits. "Workspace Trust can’t prevent a malicious extension from executing code and ignoring Restricted Mode." That line assumes the extension got installed some other way. Remedio’s finding is that an untrusted folder can do the installing.

So the bypass does not break VS Code Workspace Trust at its center. It goes around it. The feature decides whether a folder’s code may run. The attack turns the folder’s code into an installed extension. The feature’s own documentation says it cannot contain one of those.

Microsoft’s rating and the patch status

Remedio reported the issue to Microsoft before publishing. Here is its summary of the outcome. "Microsoft classified it as a Security Feature Bypass of Moderate severity, declined to assign a CVE, and noted that it duplicates an earlier submission."

According to Remedio, Microsoft based the moderate rating on two points: the attack needs a user click, and the editor shows the "Execute command" hint first. We found no Microsoft statement on the issue beyond what Remedio reports. The Hacker News carried the research in its September 2026 ThreatsDay roundup and added nothing on Microsoft’s position.

Remedio said it repeated the attack on the latest stable release before publishing. It still worked. With no CVE, there is also no advisory number to track. A fix, if one comes, may arrive in regular release notes with little signal. A medium rating that undersells the real path is not new. Our coverage of a medium-severity SSRF that opened the door to 41 production servers follows the same pattern.

Which versions and editors are affected

Remedio does not name a version number. It says it confirmed the chain on "the latest stable release" at the time of writing. Treat current VS Code as affected until Microsoft says otherwise. It also does not state which operating systems it tested beyond the Windows paths in its proof of concept.

Whether the same VS Code Workspace Trust gap exists in editors built on VS Code’s code base is an open question. Cursor, for example, describes itself as based upon the VS Code codebase. Remedio’s post does not mention Cursor, Windsurf, VSCodium or any other derived editor. We found no source that tested them. If your team uses one, do not assume either way. Check whether it shows clickable command: links in source view and whether it honors editor.links. Our explainer on Cursor covers how that editor relates to VS Code.

The setting that removes the trigger: editor.links

The whole chain depends on one Ctrl+click in the source editor. Remove that click and this route around VS Code Workspace Trust has no trigger. VS Code has a built-in setting that removes clickable links there. It is editor.links, which controls whether the editor detects links and makes them clickable. It defaults to on.

{
  "editor.links": false
}

With it off, links in the source editor lose their underline and Ctrl+click does nothing, according to Remedio. Remedio is specific about placement. "Set it in your User settings so it applies to every folder you open, including untrusted ones." Open the Command Palette, run Preferences: Open User Settings (JSON), and add the line.

There is a cost. Ordinary links in code and comments stop being clickable too. For most people, copying a URL is a small price for removing the trigger.

The extension allowlist: extensions.allowed

The second control limits what can be installed at all. Microsoft’s enterprise extensions documentation describes extensions.allowed as an "application-wide setting." Per the same page, "Support for allowed extensions is available starting from VS Code version 1.96," which shipped in November 2024.

You can allow or block by publisher, by extension ID, by version, and by platform. Publisher IDs have no period. Extension IDs do. Microsoft is clear on the default. "When you configure this setting, only listed extensions can be installed, and unlisted extensions are blocked." The only wildcard is "*". It allows or blocks everything. An extension already installed that the list blocks is disabled.

{
  "extensions.allowed": {
    "microsoft": true,
    "github": true,
    "esbenp.prettier-vscode": true,
    "dbaeumer.vscode-eslint": ["3.0.0"]
  }
}

Remedio advises managed teams to "restrict extension installation to a vetted allow-list via enterprise policy, so a stray local .vsix cannot install at all." Microsoft’s pages do not say in plain terms how the list treats a local VSIX, so treat that as Remedio’s claim and test it on one machine first.

Deploying the allowlist as policy

A setting in user settings can be changed by the user. A policy cannot. Per Microsoft, the AllowedExtensions policy "overrides any user-configured extensions.allowed setting on individual devices." The settings documentation adds that policy settings always override other values. The VS Code policies page lists how each platform receives it.

The policy list we read has no entry for editor.links. That setting stays a per-user job. Put it in onboarding notes, and in a shared dotfiles repo if your team keeps one. We covered the same gap for AI tools in our look at agent configuration management.

Why agencies and in-house web teams should care

Web agencies open other people’s code for a living. A client sends a zip of the old theme. A contractor hands over a repo at the end of an engagement. A partner shares a plugin to review. In those moments a careful developer relies on VS Code Workspace Trust. This research says it is not enough on its own.

The pattern is familiar from recent weeks. GitSpawn showed that a repo handed to an AI coding agent could run a program through its git config. That piece held up IDE trust controls as a lesson the agent tools had yet to learn. This finding shows the IDE control has a gap of its own. Our Plugin4Shell coverage of AI coding agent plugins comes at the same question from the plugin side: what gets to install and run inside a developer tool. The npm worm that harvests AI keys from build servers shows what an attacker wants from a developer machine.

For nonprofit, association and higher education clients, the stakes are practical. The developer workstation often holds SSH keys for the production host, CMS admin sessions, and cloud credentials. One installed extension has access to all of it.

What to do this week

These steps do not depend on a Microsoft fix.

• Turn off editor links: add "editor.links": false to user settings on every developer machine, including contractors’.
• Deploy an allowlist: set extensions.allowed through the AllowedExtensions policy on managed devices. Start from the extensions your team uses.
• Audit installed extensions: remove anything nobody recognizes. The attack’s extension lives in the global list, not the project.
• Look before you open: check a new folder for a .vscode directory and .vsix files first.
• Keep trust strict: do not trust folders from unfamiliar sources, and do not follow links inside them.

What we could not confirm

Several points about the VS Code Workspace Trust bypass remain open as of late September 2026. Remedio names no affected version range and no operating systems beyond its Windows example. We could not confirm whether a project’s settings file can re-enable editor.links in Restricted Mode. Microsoft’s documentation does not say how extensions.allowed handles a local VSIX. Nor does it say whether the check looks past the publisher and name a VSIX declares. No fork of VS Code has been tested in public that we could find. And Microsoft has not published its own statement, so its reasoning reaches us only through Remedio.

Frequently Asked Questions