Restrict VS Code extensions with the extensions.allowed setting

To limit which extensions a team can install, set extensions.allowed in VS Code 1.96 or later. Once the setting exists, only listed extensions are allowed. You can allow by publisher, by full extension ID or by exact version, and administrators can enforce it with the AllowedExtensions policy.

Default behaviour

By default every extension is allowed. The moment you configure extensions.allowed, that flips: only what you list can be installed. If you block an extension that is already installed, it is disabled.

Allow by publisher

A key without a period is a publisher ID.

"extensions.allowed": { "microsoft": true, "github": true }

This is the broadest option, and it is a reasonable start for a team that wants vendor extensions only.

Allow by extension

A key with a period is a full extension ID in the form publisher.extension.

"extensions.allowed": {
  "esbenp.prettier-vscode": true,
  "ms-azuretools.vscode-containers": false
}

The more specific selector wins, so you can allow a whole publisher and block one extension from it.

Pin versions and platforms

You can list exact versions. Ranges are not supported. You can append a platform.

"extensions.allowed": {
  "rust-lang.rust-analyzer": ["5.0.0@win32-x64", "5.0.0@darwin-x64"]
}

Use "stable" to block pre-release versions from a publisher.

Rules that trip people up

• Duplicate keys are invalid.
• Wildcards are not supported, except "*", which allows or blocks everything.
• If you deploy the AllowedExtensions policy and its value has a syntax error, the setting is not applied. Run Show Window Log from the Command Palette to check.

Policy versus setting

The AllowedExtensions policy is deployed through device management tools and overrides any extensions.allowed value users set. Use the setting for personal hygiene and shared workspace defaults. Use the policy when you need it to hold.

A rollout plan

1. List what is installed today. See auditing extensions across a team.
2. Decide which publishers you accept as a class.
3. Add specific extension IDs for the rest.
4. Test on a few machines. Watch for developers whose tools get disabled.
5. Publish a request path so people can ask for additions without working around the list.

The documentation also describes a private marketplace for enterprises, which requires GitHub Enterprise or Copilot Enterprise or Business sign in and does not support VS Code Server or VS Code for the Web.

Examples that work in practice

A small web team might allow the microsoft and github publishers, then add a handful of specific IDs for a formatter, a linter and a language server. A security conscious team might list only exact extension IDs with exact versions, and review updates in a monthly change. Either shape works. Start broad by publisher if you are building momentum, then tighten as you learn what people actually use.

Common mistakes

Allowing everything with "*" defeats the purpose, though it is a useful way to reset. Blocking a publisher without telling people produces confused developers whose tools silently stop working. Writing a version range fails because only exact versions are supported. And forgetting that an installed but now blocked extension is disabled can look like a bug until you check the setting. Communicate changes before you push them.

Quick check

Sources

• Manage extensions in your enterprise, VS Code documentation

Last reviewed: 19 October 2026.