Starting with VS Code 1.123, Microsoft is introducing a two-hour delay for automatic extension updates — a simple but effective mechanism to protect against software supply chain attacks. The delay gives the community and security systems time to detect malicious or compromised extension versions before they are widely distributed to millions of IDE users. The change fits into a broader industry trend: similar minimum package age mechanisms have already been implemented in npm, pnpm, Yarn, and Bun.
How the delay works in VS Code
When automatic extension updates are enabled, new versions are now installed not instantly, but two hours after publication. In the VS Code interface, the user can see why the update has not yet been applied and the exact time when it will be installed automatically. Manual updates via the “Update” button are still available at any time — the delay applies only to the automatic process.
An important detail: the two-hour delay does not apply to extensions from trusted publishers — Microsoft, GitHub, and OpenAI. Extensions from these companies continue to update instantly. This is a compromise: on the one hand, large vendors have their own code review and release-signing processes; on the other hand, compromising a trusted publisher would pose the greatest threat, and in that scenario the delay would not help.
Industry context: minimum package age
Microsoft’s decision is part of a broader movement in the development ecosystem. Over the past year, delay mechanisms for installing new package versions have appeared in several dependency managers:
- npm v11.10.0+ — the
min-release-ageparameter (documentation) - Yarn Berry 4.10.0+ — the
npmMinimalAgeGateparameter (GitHub release) - pnpm 10.16+ — the
minimumReleaseAgeparameter (release notes) - Bun 1.3+ — the
minimumReleaseAgeparameter (project blog)
The logic is the same in all cases: most malicious packages are detected and removed from registries in the first few hours after publication. An installation delay reduces the window during which a compromised version can spread before it is flagged as malicious and removed. This is not a silver bullet, but an additional layer of protection that specifically addresses the most common scenario — the rapid publication of a malicious update that relies on automatic propagation.
Effectiveness and limitations
A two-hour window is a reasonable balance between security and convenience. For attacks such as “developer account takeover followed by publication of a malicious update,” this is often enough time for automated monitoring systems or vigilant users to notice an anomaly. However, the limitations should be taken into account:
- The delay does not protect against targeted attacks where malicious code is carefully concealed and can remain unnoticed for weeks
- The exception for trusted publishers creates a privileged channel that can itself become a target of attack
- Two hours is a fixed value; unlike package managers, VS Code does not yet allow users to configure the duration of the delay
Recommendations
For development teams using VS Code, upgrading to version 1.123 will enable the delay automatically without additional configuration. For JavaScript and TypeScript projects, you should also enable minimum package age settings in your dependency manager — min-release-age in npm or equivalent options in pnpm, Yarn, and Bun. These settings typically require explicit activation and are not enabled by default.
The introduction of update delays in VS Code and leading package managers is forming a new standard of supply chain protection at the developer tooling level. A concrete action: review the configuration of each dependency manager in your projects and set the minimum package age to at least a few hours — a minimal effort that significantly reduces the risk of automatically installing freshly published malicious code.
