VS Code extension auto-update: delay, pause or pin versions

VS Code updates extensions automatically and waits 12 hours by default before installing an update. You can raise extensions.autoUpdateDelay, switch auto update off, or allow only exact versions with extensions.allowed. Each choice trades faster fixes against more time for bad releases to be caught.

What the settings do

From the VS Code documentation:

• extensions.autoUpdate controls automatic updates. You can turn it off with Disable Auto Update for Extensions, and toggle it per extension.
• Only enabled extensions auto-update. Disabled ones update the next time you enable them.
• extensions.autoUpdateDelay sets the wait in hours before an update installs. The default is 12. Setting it to 0 installs updates as soon as they are published.
• extensions.autoCheckUpdates set to false stops update checks entirely.
• Administrators can manage extensions.autoUpdate and extensions.autoUpdateDelay through enterprise policies.

Extensions installed from a VSIX file have auto update disabled by default.

Why delay at all

An update is new code running with your permissions. The Marketplace scans each update before publishing and keeps a block list for malicious extensions, but a delay gives time for reports to arrive and for blocked releases to be pulled. The platform's own scanning is described as part of the picture, not a promise.

A delay does not protect you from a compromise that nobody has noticed. It only buys time.

Three policies to pick from

1. Default. Auto update with the 12 hour delay. Fine for most personal machines.
2. Longer delay. Raise extensions.autoUpdateDelay, for example to a few days, so that updates land after the community has had a look. The right number is a judgement for your team. The documentation does not recommend one.
3. Pinned. Turn auto update off and use extensions.allowed with exact versions. This is the strictest option and needs an owner who reviews updates on a schedule.

The cost of pinning

If you never update, you miss fixes, including security fixes in the extension. Pinning needs a routine. Review changelogs, test the new version on one machine, then bump the allowed version.

For regulated or sensitive machines

Use the policy route so users cannot change it. Combine with an allowlist as described in the extensions.allowed guide.

How to decide for your team

Ask two questions. What is the worst thing a bad extension update could do on this machine, and how fast would you want a security fix for the extension? A laptop with access to production credentials justifies a stricter policy than a training machine. A widely used formatter that rarely changes is a good candidate for pinning. A security scanner extension that ships fixes often may deserve faster updates, because stale tooling is its own risk.

Auditing what changed

Whatever you choose, keep a record. After an update window, compare installed versions to the inventory, as described in auditing extensions across a team. If something behaves oddly after an update, you will know which version arrived and when.

Quick check

Sources

• Extension Marketplace, VS Code documentation
• Extension runtime security
• Manage extensions in your enterprise

Last reviewed: 19 October 2026.