What VS Code’s 2-Hour Extension Delay Actually Does
The new Visual Studio Code two-hour extension auto-update delay is a security control that postpones automatic installation of fresh extension versions to narrow the window for supply chain attacks, giving maintainers and security teams time to detect and remove malicious extensions before they reach most developers. In VS Code 1.123, when you have extension auto-update enabled, the editor now waits two hours after a new version is published before pulling it in automatically. This delay applies to the vast majority of extensions in the marketplace, while updates from trusted publishers like Microsoft, GitHub, and OpenAI still install immediately. During the delay, you keep working with your current, known-good version. If you want the new release right away, you can use the Update button manually, but by default you benefit from a built-in cooling-off period.
Why Supply Chain Attacks Through Malicious Extensions Matter
Software supply chain attacks target the tools and dependencies developers rely on every day, and malicious extensions are a high-impact path into development environments. Compromised or hijacked publishers can push a new extension version that quietly steals credentials, exfiltrates code, or plants malware on developer machines. According to The Hacker News, Microsoft’s change comes amid “a surge in software supply chain incidents targeting various ecosystems to breach developer systems and propagate malware to downstream users.” These attacks are dangerous because they piggyback on trust: developers expect familiar extensions and package names to be safe, and auto-update can distribute a bad release faster than defenders can respond. By slowing down extension auto-update, VS Code security now treats fresh versions as potentially risky until they have been visible long enough for suspicious behavior or reports to surface.
How the Auto-Update Grace Period Works in Daily Use
For developers, the new two-hour delay introduces a predictable grace period between an extension release and its automatic rollout to your editor. When an extension publishes a new version, VS Code 1.123 schedules the update for two hours later instead of applying it immediately in the background. In the Extensions view, any item with a pending update will show why it has not updated yet, plus the time when the automatic update is expected to occur. You can override the delay at any moment by clicking the Update button for that extension, which triggers an immediate install. Trusted publishers such as Microsoft, GitHub, and OpenAI bypass this mechanism and still auto-update without delay, so critical first-party tooling and language support keep flowing without extra friction.
Adapting Your Workflow and Expectations Around Extensions
This change nudges teams to think of extension auto-update as a controlled process rather than an instant pipeline. If your workflow depends on new extension releases the moment they drop, you may need to plan around the two-hour window or opt into manual updates for specific tools. Teams concerned with VS Code security can treat the waiting period as time to skim release notes, watch for community reports, or test updates on a small subset of machines before wider rollout. The delay also aligns VS Code with other ecosystems that now use minimum-age gates for packages, where installation is blocked until a version has been public for a set time. Treat new extension versions as you would new npm or Ruby gems: useful, but better after brief observation instead of blind, immediate adoption.
A Shift Toward Proactive Defense Against Supply Chain Attacks
The two-hour extension delay signals a broader shift in VS Code’s security posture from reactive patching toward proactive risk reduction. Rather than assuming every fresh extension version is safe until proven otherwise, the IDE now bakes in the idea that new releases can be attack vectors. This follows similar controls across popular package managers such as npm, Yarn, pnpm, Bun, and RubyGems, which have added minimumReleaseAge-style settings to slow down exposure to brand-new versions. The goal is not to stop updates, but to make their spread more measured so that community scrutiny and registry takedowns can work before an attack scales. For developers, the takeaway is clear: extension auto-update is still convenient, but it now respects a small buffer in favor of security, and that buffer should be part of your planning.
