There is a Caution box on VS Code’s own Workspace Trust page that retires most of what gets written about the feature. It reads: “Workspace Trust can’t prevent a malicious extension from executing code and ignoring Restricted Mode. You should only install and run extensions that come from a well-known publisher that you trust.” Two sentences. The first disclaims containment in plain language; the second hands the actual security work back to human judgment about publishers.
VS Code Workspace Trust is a consent gate on automatic execution, and that is the whole of it. It is not a sandbox, not an isolation boundary, and not a permission system in the sense a mobile OS or a browser extension manifest means those words. The page one click away is equally blunt about why: “The extension host has the same permissions as VS Code itself. This means that any action that VS Code can perform, an extension can also perform through the extension host” — reading and writing files, making network requests, running external processes, modifying workspace settings. There is no capability manifest and no per-API consent prompt.
That leaves an obvious question. VS Code’s process architecture is the most-praised thing about it, and extensions run in their own process. If that separation is not protecting you from an extension, what is it for? Microsoft answered that in 2022, in public, in one engineering blog post.
The 2022 Migration That Settles What the Process Boundary Is For
On 28 November 2022 the team published Migrating VS Code to Process Sandboxing, describing a substantial hardening effort. The renderer — the process that draws the editor UI and previously had raw Node.js access — was moved behind Electron’s sandbox model. The stated motivation is a real, historical vulnerability class, quoted verbatim from that post: “We have had security issues in the past where attackers were able to execute arbitrary Node.js code from the renderer process. A sandboxed renderer process greatly reduces the risk of these attacks.”
That is a security boundary in the strict sense: built to stop a specific escalation path, at the cost of removing every Node.js dependency from the renderer.
Now watch what happened to the extension host in the same migration, in the same document. It did not go into the sandbox. It went the other way. The post lists the requirements the team set for the process that would host it:
“Isolated process with support for spawning child processes”
“Full Node.js support”
“Use message ports for direct IPC with sandboxed processes”
Electron had no API meeting those requirements, so, in the post’s own words, “we contributed a new utility process API to Electron.” Microsoft hardened the process that shows you pixels and built new upstream platform machinery specifically to preserve full Node.js access in the process that runs third-party code.
| Process | What the 2022 work did to it | What that establishes |
|---|---|---|
| Renderer (workbench UI) | Moved into an Electron sandbox; all Node.js dependencies removed | A real security boundary, aimed at renderer-to-Node escalation |
| Extension host | Moved out, into a new utility process with “Full Node.js support” and child-process spawning | Deliberately unsandboxed; the boundary here is not about containment |
| Main process | Retained as the coordinator, reached over message ports | IPC surface, not a privilege wall around extensions |
This is not an oversight. Extensions need file, process and network access to do their jobs: language servers spawn compilers, debug adapters spawn debuggees, the Git extension spawns git. A sandboxed extension host would break most of the ecosystem on day one. The point is narrower than a complaint: “VS Code got sandboxed in 2022” is true of the renderer and false of extensions, and citing it as evidence that extensions are contained is citing the wrong process.
The Extension Host documentation says the same thing from the other direction, by enumerating what the boundary was built to prevent: “Impacting startup performance, Slowing down UI operations, Modifying the UI.” None of them is “prevents extensions from reading your SSH keys.” And the other half of the same misreading is worth naming: the boundary protects the core from extensions, not extensions from each other — all extensions in a window share one host and one crash domain.
What Restricted Mode Gates, and What It Hands Straight Back
The honest framing of Restricted Mode, then, is that it changes what runs without you asking, not what is possible. VS Code says as much: “Restricted Mode tries to prevent automatic code execution by disabling or limiting the operation of several VS Code features: AI agents, terminal, tasks, debugging, workspace settings, and extensions.” Note the verb in the feature’s own opening line — it lets you decide “whether code in your project folder can be executed by VS Code and extensions without your explicit approval.” Approval for execution. Not containment of execution once approved.
| Feature | What Restricted Mode does | The stated reason |
|---|---|---|
| AI agents | Disabled entirely in the workspace | Any file pulled into context “could theoretically result in a prompt injection attack” |
| Terminal | Opening one is blocked by default; overridable via terminal.integrated.allowInUntrustedWorkspace | Shells auto-execute from workspace contents — sourcing .env, shell init scripts |
| Tasks | Require trust | Task definitions live in the committed .vscode folder and ship to “every user of that repo” |
| Debugging | A debug session will not start | “debug extensions can run debugger binaries when launching a debug session” |
| Workspace settings | Trust-tagged keys fall back to the user/global value | “Some settings contain paths to executables (for example, linter binaries), which if set to point to malicious code, could cause damage” |
| Extensions | Disabled unless the extension declared support | Self-declared capability; see below |
And what stays on: “you can still browse and edit source code in Restricted Mode. Some language features may be disabled, but text editing is always supported.” That is the correct design — it was built so you can read a stranger’s repository safely, and reading is what it protects.
One detail before you rely on the prompt you think you saw: security.workspace.trust.startupPrompt defaults to never, so a new folder opens in Restricted Mode with a banner, not a modal — and the banner is governed by security.workspace.trust.banner, default untilDismissed. An engineer who habitually dismisses banners has habituated past the only signal.
“By Design”: What Happened When Someone Tested the Model
On 13 April 2026 someone filed issue #309406 against microsoft/vscode, titled “Security: .vscode/tasks.json with runOn: folderOpen enables silent arbitrary code execution from cloned repositories.” The mechanism is documented and mundane: a task can declare "runOn": "folderOpen", and presentation options exist that keep its terminal from being revealed or focused — so it runs on open with no visible artifact. VS Code’s Tasks documentation states the guardrail plainly: task.allowAutomaticTasks defaults to off, and “Automatic tasks never run in an untrusted workspace, regardless of this setting.”
⚠️ A correction to this hub’s own research. Our note recorded #309406 as open and unresolved. It is not. Checked against the GitHub API on 2026-09-04: the issue was closed as completed on 13 April 2026 — the same day it was filed.
The closing comment, from a VS Code team member, is the most valuable sentence in this article, because it defines the model rather than describing a feature:
“The team’s attempts to repro required the user to confirm in the Workspace Trust dialog… After that point, it’s By Design that opening a directory can trigger automatic scripts. If you’ve found a way get execution without clicking the Workspace Trust dialog on the directory (or parent directory), please report it via our official security reporting mechanisms.”
Read that as a specification and it tells you exactly where the boundary is. Execution without the trust dialog is a vulnerability. Execution after it is a feature. The reporter came back on 11 May 2026 asking for a reopen, arguing that a one-time dialog is not a sufficient warning for one of the most widely used editors in the industry; the maintainer redirected them to MSRC. The issue remains closed as of 2026-09-04.
You can disagree with that call — the reporter did, publicly — but you cannot call the position unclear, and you should not build a threat model that assumes something stronger. Auto-executing tasks and the hardening around them deserve their own treatment, and a companion piece in this series covers them. The point here is narrower: the consent click is the boundary, and there is nothing behind it.
A Registry of Restrictions, Not a Wall
The other reason “sandbox” is the wrong word is architectural: Workspace Trust is not implemented as a container. It is implemented as a set of individually registered protections, opted into one at a time.
Independent researcher Ammar Askar documented this precisely in a 30 May 2023 write-up. Looking at how core settings are protected in untrusted workspaces, he found that VS Code’s own registerConfiguration path requires each setting to explicitly pass 'restricted': true. An undocumented internal setting — _workbench.experimentsUrl, which controls where the editor fetches A/B experiment configuration from — had never been registered that way. A workspace could therefore set it in an untrusted folder, the exact case Restricted Mode exists to cover. Microsoft fixed it on 24 May 2023. MSRC assessed it Severity: Moderate, Security Impact: Spoofing and ruled it ineligible for the bug bounty on the grounds that only important or critical cases qualify — a call the researcher publicly disputed.
The severity argument is not the interesting part. The shape is. A missing entry in a registry is a gap, not a wall that was breached, and gaps of that shape are what you get from “restrict specific dangerous operations by category,” never from “isolate untrusted code.”
The same voluntary character runs through the extension side. The Workspace Trust extension guide defines a capabilities.untrustedWorkspaces declaration in an extension’s package.json with three values — true, false, or 'limited' — plus a restrictedConfigurations array naming which of the extension’s own settings must ignore workspace values while untrusted. At runtime an extension reads workspace.isTrusted and subscribes to onDidGrantWorkspaceTrust.
All of it is self-declared, and nothing inspects what an extension actually does. It is a coordination protocol that lets a large ecosystem behave consistently around one user decision — genuinely useful, and worth exactly as much as the author’s good faith. extensions.supportUntrustedWorkspaces lets you override a declaration for your fleet; what does not exist is enforcement.
Trust Is Scoped to a Folder. Consequences Are Scoped to a Machine.
Three places where the scope of the decision and the scope of the blast radius come apart.
Trusting a Parent Folder Trusts Every Clone You Put Under It
Add a parent path to the Trusted Folders list and “when you trust a parent folder, all subfolders are trusted.” Convenient if you keep everything under ~/src. It also means the next repository you clone into that tree is trusted before you have looked at it, and VS Code says so quietly: instead of the usual Don’t Trust button, text noting the folder is trusted because of another folder. Trust your whole code directory once and you have opted every future clone in.
An Empty Window Is Trusted by Default
With no folder open, VS Code runs the window with full trust; security.workspace.trust.emptyWindow defaults to true. Loose files opened into it prompt separately, governed by security.workspace.trust.untrustedFiles.
Remote-SSH and Dev Containers Move the Machine, Not the Model
Workspace Trust applies to remote and containerized folders exactly as it does locally — same prompt, same semantics. What changes is whose machine runs the code, which the folder-level model was never built to answer. A malicious workspace is content on a machine you control; a compromised remote host is the execution environment itself. The follow-up question is what you brought with you: forwarded SSH agents, mounted credentials, tokens injected into a container with its own outbound network access. Workspace Trust asks whether you trust the authors of the files; remote development also asks whether you trust the host, and what of yours it can now reach.
Separate these two while you are here: Git’s safe.directory ownership check is Git-enforced and merely surfaced in VS Code’s Source Control view. Clicking through the “unsafe repository” prompt writes to your Git config — a different decision from trusting the workspace, prompted at the same moment, which is exactly why teams merge them in their heads.
What the Friction Is Actually Worth
None of this makes Workspace Trust a bad feature. It makes it a correctly scoped one that is routinely oversold.
Before it existed, a workspace settings.json pointing an interpreter or linter path at an attacker-supplied binary was a live, exploited remote-code-execution vector; restrictedConfigurations closes that class by pinning path-type settings to the user value until trust is explicit. Debuggers no longer launch binaries from a folder you have not vouched for. Terminals do not open into shell init scripts you have not read. AI agents — the newest and largest content-triggered execution surface — are disabled outright in an untrusted workspace, which is the best reason the feature matters more in 2026 than it did in 2021.
That is a real reduction in automatic execution, achieved without breaking the ability to read code. Judge it as what it is: a default that fails safe, plus a decision point. The failure mode is calling it containment and then behaving as though something is still watching after the click.
A Pre-Flight for Code You Did Not Write
Practical, and adoptable by a team this week.
Before You Open It
- Read the repository in a browser first. GitHub’s web editor (press
.on any repo page) gives you a VS Code-like reading surface with no local shell to execute into. - Look at three paths specifically:
.vscode/tasks.jsonfor arunOn: folderOpenentry,.vscode/settings.jsonfor any key whose value is a path to an executable, and.vscode/extensions.jsonfor recommendations you would not have chosen. - Clone into a directory that is not under a trusted parent. If
~/srcis on your Trusted Folders list, an untrusted clone does not belong in it.
Settings to Standardise at the User or Policy Level
| Setting | Set it to | Why |
|---|---|---|
security.workspace.trust.enabled | true (default) | Turning it off removes the only gate there is |
security.workspace.trust.startupPrompt | once | Default is never — you get a dismissible banner instead of a decision |
task.allowAutomaticTasks | off (default) | Set it explicitly in user settings so no workspace default reaches you |
security.workspace.trust.emptyWindow | false, if your team can live with it | Empty windows are otherwise fully trusted |
extensions.allowed | An explicit allowlist | Publisher-, extension-, version- and platform-scoped; VS Code 1.96+ |
The One Control That Is Actually Enforced
extensions.allowed has a device-management counterpart, the AllowedExtensions policy, which overrides the user-configured setting on managed devices. That is the only control here actually enforced against a determined user, and it works by restricting what gets installed — the lever that matters, given that everything installed runs with your permissions. What the Marketplace’s signing, scanning and publisher badges attest to is a separate subject with its own article in this series; the one-line version is that they establish origin and identity, never behavior.
One habit worth building. Treat “verified publisher” as an identity signal and nothing else — the blue check mark, per Microsoft, “indicates that the publisher has proven domain-name ownership to the Marketplace” — and note that publisher trust is transitive: since VS Code 1.97, trusting an extension pack’s publisher means “you are also trusting the publishers of the dependent extensions.”
❓ Frequently Asked Questions
Is Workspace Trust a sandbox? No, and its own documentation does not use that word for it. The primary page states it “can’t prevent a malicious extension from executing code and ignoring Restricted Mode.” It gates automatic execution of specific feature categories; it does not contain code that runs. (“Sandbox” does appear on the extension-runtime-security page — describing the Marketplace’s pre-publish dynamic scanning in a clean-room VM, a control on Microsoft’s servers, not a property of your machine.)
Does Restricted Mode stop an installed extension from running? Only if the extension declared that it needs trust. capabilities.untrustedWorkspaces is set by the author, and VS Code does not verify that behavior matches the declaration. An installed, enabled extension runs in the extension host, which has the same permissions as VS Code itself.
What actually got sandboxed in 2022, then? The Electron renderer process, which draws the workbench UI. The extension host moved the opposite way in the same migration — into a utility process the team specified as needing “Full Node.js support” and the ability to spawn child processes, for which Microsoft contributed a new API to Electron.
Is the runOn: folderOpen auto-execution issue a vulnerability? Microsoft closed #309406 as By Design on 13 April 2026, because reproduction required confirming the Workspace Trust dialog; it was still closed when checked on 2026-09-04. Their line: execution without the dialog is reportable, execution after it is expected. Plan accordingly — set task.allowAutomaticTasks to off in user settings and read .vscode/tasks.json before you trust a folder.
Do dev containers or Remote-SSH give me isolation Workspace Trust doesn’t? They change which machine executes — a meaningful risk transfer for a hostile workspace — but they add a question rather than answering one. You now also have to trust the host and account for whatever credentials follow you into it: forwarded agents, mounted keys, injected tokens. Workspace Trust applies inside the remote or container exactly as it does locally.
What is the single highest-leverage control for a team? An extension allowlist deployed as policy — extensions.allowed scoped by publisher, extension, version and platform, pushed through the AllowedExtensions device-management policy so it overrides local settings. Everything else here reduces automatic execution; that one reduces what is installed, the only quantity a permission-free runtime leaves you.
Every VS Code quotation here was verified against the raw page text on code.visualstudio.com on 2026-09-04, and the GitHub issue state was read from api.github.com the same day. Behavior described reflects that date — VS Code has shipped weekly Stable releases since March 2026, so re-check any default before you build policy on it.
📦 Recommended Resources
Some links below are Amazon affiliate links — if you buy through them, this site earns a small commission at no extra cost to you.
Start with the free primary material, because on this subject it genuinely beats the books: the Workspace Trust documentation, the extension runtime security page, and the November 2022 Migrating VS Code to Process Sandboxing post are short, specific, and unusually honest about their own limits. Read them before anything else. The three books below are for the layer underneath — the vocabulary that lets you tell an advisory mechanism from an enforced one before someone sells you the wrong one.
- Security Engineering: A Guide to Building Dependable Distributed Systems by Ross Anderson — the reference text on what a security boundary actually is, and the one this article leans on hardest without naming. Anderson’s recurring subject is precisely the gap this piece is about: mechanisms that look protective, are described protectively, and turn out to be enforcing something adjacent to what everyone assumed. If you only take one book from this list, take this one.
- Threat Modeling: Designing for Security by Adam Shostack — the practical counterpart. The whole argument here is a threat-modelling argument dressed as an editor feature: what are we defending, against whom, and which component actually enforces it? Shostack gives you a repeatable way to ask that about your own systems instead of only recognising the answer when a vendor writes it down for you. Directly applicable to the pre-flight checklist in this article.
- Building Secure and Reliable Systems by Heather Adkins, Betsy Beyer, Paul Blankinship, Piotr Lewandowski, Ana Oprea and Adam Stubblefield — Google’s book on designing for least privilege and, more usefully here, on design for understandability: making it obvious what a control does so nobody has to guess. It is also the best available treatment of the organisational version of this problem, which is the level at which an extension allowlist actually gets deployed.
✅ Pro tip: Before you reach for any of these, spend ten minutes running the pre-flight above against a repository you already trust. Check whether ~/src is on your Trusted Folders list, whether security.workspace.trust.startupPrompt is still at its never default, and whether task.allowAutomaticTasks is set explicitly in your user settings rather than inherited. Most engineers find at least one of those is not what they assumed — which is the whole point.