How to lock down VS Code extensions: update delay, allow list, publisher trust and version pinning

In short

An editor extension is code that runs on your computer with your permissions, and most editors update them automatically. You can reduce the risk with four settings in VS Code: delay automatic updates, turn them off for extensions you rely on, allow only the publishers and versions you have vetted, and keep Workspace Trust switched on. None of these makes a malicious extension safe; they limit how fast a bad update reaches you and who is allowed to supply one.

This matters now because of a real case. In October, attackers put tampered copies of Anthropic's Claude Code extension into Cursor's marketplace for about 11 hours, as we explain in our report on the Cursor marketplace incident. Everything below is taken from Microsoft's VS Code documentation. Cursor is a fork of VS Code, but we did not read Cursor's own documentation, so check that a given setting exists in your editor before relying on it.

Why extensions are a risk

Microsoft's documentation says it plainly: "Most extensions run code on your behalf and could potentially do harm." Extensions are not a sandboxed add-on. A malicious one can read files your user can read, run programs and open network connections, which is why the Cursor-hosted malicious build could try to write an SSH key into the user's authorized_keys file.

The built-in protections are real but partial:

• The Marketplace signs every extension when it is published, and VS Code checks that signature at install time to confirm the package's integrity and source.
• The Marketplace scans each new extension and each update with several antivirus engines, and an extension is not publicly available until the scan is clear. It also runs dynamic detection by testing extension behaviour in a sandboxed virtual machine.
• Since VS Code 1.97, installing an extension from a third-party publisher asks you to confirm that you trust that publisher.

These protections apply to the store you install from. They do not help if your editor pulls from a different mirror or cache, and they do not stop a trusted publisher's account from being abused. Treat them as one layer.

Step 1: Know what you have installed

List every extension with its version from a terminal:

code --list-extensions --show-versions

Keep that output somewhere. After an incident like the Cursor one, the first question is whether a specific version was ever on your machine. Remove extensions you no longer use, because every installed extension is a supplier you have to trust.

Step 2: Slow down automatic updates

Automatic updates are convenient, and they are also how a bad version reaches thousands of machines at once. VS Code gives you three controls, per its documentation:

• extensions.autoUpdateDelay sets how many hours VS Code waits before installing an update. The default is 12. Setting it to 0 installs updates as soon as they are published. The documentation notes that the delay only applies when auto update is on, and that selecting Update by hand skips it.
• Disable Auto Update for Extensions (a command, also available in the Extensions view) turns automatic updates off entirely. Enable Auto Update for Extensions brings them back.
• You can toggle Auto Update for a single extension by right-clicking it.

If you prefer to find out about updates but not install them, set extensions.autoCheckUpdates to false to stop checking altogether and run Check for Extension Updates when you choose.

Which is better? A delay of a day or two gives the community and the Marketplace's scanners time to catch a bad release, at the cost of getting fixes later. Note the trade-off: delaying updates also delays security fixes. For tools that handle secrets or source code, such as AI coding agents, many teams will accept that.

Extensions installed from a VSIX file have auto update off by default, according to the documentation, so a pinned manual install does not drift.

Step 3: Install a specific version

When you want to pin something, right-click the extension, choose Install Another Version and pick from the list. This is also the way back if an update misbehaves. From the command line, code --install-extension myextension.vsix installs a downloaded VSIX; you can repeat the flag for several.

Step 4: Allow only what you have vetted

VS Code 1.96 and later have an extensions.allowed setting. By default every extension is allowed. Once you add an allow list, anything that does not match a rule is blocked, and blocking an extension that is already installed disables it. The documented format:

• A key without a period is a publisher ID: "microsoft": true.
• A key with a period is a full extension ID, <publisher>.<extension>: "esbenp.prettier-vscode": true.
• A list of versions pins exact versions: ["3.0.0"]. Ranges are not supported. You can append a platform, such as "5.0.0@win32-x64".
• The value "stable" allows stable releases and blocks pre-releases.
• The more specific rule wins, duplicate keys are invalid, and the only wildcard is "*".

A small example, written from those rules:

{
  "extensions.allowed": {
    "microsoft": true,
    "ms-python.python": "stable",
    "esbenp.prettier-vscode": ["3.0.0"]
  }
}

The version number is the documentation's own example, not a recommendation. Check which version you actually trust before pinning, and remember that a pin also blocks future fixes until you edit the list.

On managed devices, an organisation can deploy the AllowedExtensions policy through device management, which overrides the user setting. If the policy has a syntax error, the setting is not applied, and the documentation says to check the Window log for errors.

Larger organisations have one more option. VS Code's documentation describes a private marketplace that hosts internal extensions and can include public ones, or rehost them for air-gapped environments. It is available to GitHub Enterprise customers.

Step 5: Keep Workspace Trust on

Workspace Trust is a different layer. It protects you from projects, not from extensions you chose. In Restricted Mode, extensions that have not opted in to Workspace Trust are disabled by default, and tasks in a repository's .vscode folder prompt you before they run. The documentation is blunt about the limit: Workspace Trust "can't prevent a malicious extension from executing code and ignoring Restricted Mode." It advises installing only extensions from well-known publishers you trust. Users can override an extension's trust support with extensions.supportUntrustedWorkspaces, which the page says to use carefully.

Step 6: Manage publisher trust

Since VS Code 1.97, the first install from a third-party publisher prompts you to trust it, and trusting an extension pack or an extension with dependencies also trusts the publishers of its dependencies. Publishers of extensions you already had were added to the trusted list automatically. Review it with the Extensions: Manage Trusted Extensions Publishers command. Extensions installed through the command line do not automatically trust their publisher.

Read the prompt each time. In the Cursor incident the publisher shown was the genuine one, which is exactly why publisher trust alone is not enough.

A short routine

1. Run code --list-extensions --show-versions monthly and remove what you do not use.
2. Set an update delay, or turn auto update off for extensions that touch secrets or code.
3. Use extensions.allowed on shared or managed machines.
4. Keep long-lived credentials out of the environment variables your editor inherits. The malicious Cursor-hosted build reported the names of up to 40 environment variables containing words such as KEY, TOKEN or SECRET, according to The Hacker News.
5. When a vendor reports an incident, check your installed versions against the affected ones before anything else.

Common questions

Does turning off auto update leave me exposed to known bugs? Yes, for as long as you stay on an old version. The documentation's answer is a middle path: keep the update check on, use the delay, and install updates yourself after reading what changed.

Can I check updates without installing them? Yes. Set extensions.autoCheckUpdates to false to stop automatic checks, or leave checks on and disable auto update, then run Check for Extension Updates when you want to look.

What if an update breaks my setup? Use Install Another Version on the extension and pick the earlier release.

Does the allow list stop a bad update from a publisher I allowed? Only if you pin versions. A publisher-level rule such as "microsoft": true accepts whatever that publisher ships, which is the trade-off between safety and convenience.

Who should do this? Anyone who keeps credentials, cloud keys or private source on the machine that runs the editor, which is most developers. Shared and managed machines benefit most, because the AllowedExtensions policy can enforce the list.

What these steps cannot do

• They cannot detect a malicious extension. The documentation's malware scanning is the Marketplace's job, not yours.
• They cannot protect against an extension you chose to allow and keep updated that later turns hostile in a version you pinned.
• They do not cover forks' own marketplaces. If your editor is a VS Code fork, find out which store it pulls from and who runs its cache, and read that vendor's documentation.
• Settings like extensions.allowed need VS Code 1.96 or later, and the publisher prompt needs 1.97 or later.

Sources

• VS Code docs: Extension runtime security
• VS Code docs: Extension Marketplace (auto update, versions, VSIX)
• VS Code docs: Enterprise extension management (extensions.allowed)
• VS Code docs: Workspace Trust
• Cursor: security incident update
• The Hacker News: trojanized Claude Code extension