How VS Code's two-hour delay will operate
Microsoft will introduce a two-hour delay before automatic extension updates take effect in Visual Studio Code, the company announced. The delay applies only when automatic updates are enabled; new extension versions that are published will be applied automatically two hours after publication rather than immediately. The feature is available starting in VS Code 1.123.
Users are not locked into the delay: any extension can still be updated immediately at any time by pressing the "Update" button. When updates are pending, the details view for an extension will show both a reason that it has not yet been updated and the timestamp for when the automatic update will occur.
Trusted publishers remain exempt: Microsoft, GitHub, OpenAI
Microsoft explicitly exempted extensions from trusted publishers from the delay. Extensions published by Microsoft, GitHub, and OpenAI will continue to update immediately and are not subject to the two-hour auto-update hold.
This change in context: similar controls in package managers and Bundler
The VS Code delay follows a broader trend: days earlier, RubyGems added an opt-in cooldown feature to Bundler 4.0.13 that delays installation of newly published gem versions. That Bundler feature allows developers to configure a time-based install delay to reduce potential exposure from newly published malicious versions.
Over the past year, other package managers have introduced comparable minimum-age controls. The exact controls and the versions named in the announcement are:
- Bun — minimumReleaseAge (Bun 1.3+)
- npm — min-release-age (npm v11.10.0+)
- pnpm — minimumReleaseAge (pnpm 10.16+)
- Yarn — npmMinimalAgeGate (Yarn Berry 4.10.0+)
The security logic: narrowing the window for supply chain abuse
Microsoft framed the change as an "extra layer of protection against problematic or potentially compromised releases." The broader rationale, reflected across the Bundler and package-manager controls, is to reduce the immediate spread of malicious or compromised code by enforcing a short, deliberate delay between publication and automatic consumption.
According to the material published with the announcement, these defensive controls aim to minimize the window during which a malicious release can spread before it is flagged as malicious and removed by registry maintainers. In other words, a minimum-age threshold shortens the period in which a newly published bad release can propagate automatically to downstream users.
What this means for developers, extension authors, and security teams
- Developers and end users: The two-hour hold is passive by default when automatic updates are enabled; anyone who needs a new version immediately can still trigger an update manually with the "Update" button. Users will also see a clear reason and scheduled update time in the extension details view when updates are pending.
- Extension authors and maintainers: Authors of extensions from non-exempt publishers should be aware that their updates may not reach users immediately via automatic updates. Trusted publishers named by Microsoft—Microsoft, GitHub, and OpenAI—are unaffected by the hold and will see immediate delivery.
- Security teams and operational responders: The measure adds a short buffer to detect and respond to problematic releases. It joins the set of registry-level and package-manager protections that create a modest but potentially meaningful delay between publication and automatic consumption, narrowing the early distribution window for harmful releases.
The VS Code change is modest in scope but aligned with a clear pattern: several package ecosystems have lately adopted time-based controls to slow the automatic adoption of freshly published code. Implemented in VS Code 1.123 with an opt-out via immediate manual update, the two-hour delay is a defensive nudge rather than a hard block—and it carries a named exception for a small set of trusted publishers.
Original story: https://thehackernews.com/2026/06/vs-code-adds-2-hour-extension-auto.html
