VS Code 1.123 Adds Two-Hour Extension Update Delay to Limit Supply Chain Attacks

Microsoft's VS Code 1.123, released June 3, introduces a two-hour delay before newly published extension versions auto-update, aiming to mitigate supply chain attacks by providing a window to catch malicious updates. The delay does not apply to trusted publishers like Microsoft, GitHub, and OpenAI, a carve-out criticized given their high-value target status. The move follows similar cooldown mechanisms in package ecosystems like pip, npm, and RubyGems, though the two-hour window is shorter than those typically used.

Starting with VS Code 1.123 https://code.visualstudio.com/updates/v1 123 , shipped June 3, newly published extension versions sit for two hours before auto-update kicks in. The idea is straightforward: if someone compromises an extension maintainer's account and pushes a malicious update, there's a window to catch it and pull the release before it rolls out to millions of developers. You can still click Update manually at any time. Microsoft puts it plainly https://code.visualstudio.com/updates/v1 123 : When automatic updates are enabled, new versions are auto-updated two hours after they are published, adding an extra layer of protection against problematic or potentially compromised releases. One catch: the delay does not apply to extensions from " trusted publishers " like Microsoft, GitHub, and OpenAI. Those keep updating instantly. That's a strange carve-out given that trusted publishers with massive install bases are exactly the highest-value targets for account compromise. The move follows a wave of similar controls across package ecosystems. Pip 26.1 recently shipped configurable dependency cooldowns https://www.infoq.com/news/2026/05/pip-261-dependency-cooldowns/ , where teams can block packages younger than seven days. Research found that a seven-day cooldown would have stopped 8 out of 10 analyzed supply chain attacks. RubyGems added opt-in cooldowns to Bundler. npm, pnpm, Yarn, and Bun have all introduced minimum release age settings over the past year. VS Code now joins at the IDE extension layer, though its two-hour window is dramatically shorter than what other ecosystems offer. The Reddit thread https://www.reddit.com/r/programming/comments/1u089ai/vs code adds 2hour extension autoupdate delay to/ was not kind about the duration. The top comment, with over 650 upvotes, set the tone: 2 hours is not nearly enough given a lot of supply chain compromises have only been found days or even weeks after. Would be better to default to longer IMO, and also add an option to allow the user to choose. A security practitioner pushed back harder on the entire " update immediately " orthodoxy: The biggest myth in cybersecurity I've ever heard is "Make sure you download every update as it becomes available." I've worked in very high security environments. We have never been current on updates. There was always a delay of a week up to even a month, barring patches for very specific vulnerabilities. Not everyone dismissed the two-hour window outright. One commenter pointed out that most malicious packages are caught by automated scanners, not humans: By far the most malicious npm packages are found not by users, but by automated security scanners. The same applies to VS Code extensions. When a new package is released, security scanners immediately look for suspicious code. But 2 hours is indeed quite short for this. After all, when a security scanner flags a package, someone still needs to look at it to verify that the threat is real. Several commenters argued that cooldowns miss the point entirely. One proposed that VS Code should sandbox extensions with explicit permissions instead, the same model mobile operating systems use for apps. Another suggested staged rollouts: 5% of users get the update immediately, another 10% a couple of hours later, scaling up over days until everyone has it. That way compromised updates hit a small population first, giving scanners and the community time to react before broad distribution. The practical validation came from developers already using longer cooldowns elsewhere. One commenter reported setting npm libraries to a two-week delay and said " it has avoided more problems than it has caused ." Another shared that their workplace enforces a six-day policy on their internal npm registry. A pnpm user credited the minimumAgeRelease config with saving them from two supply chain attacks in the past few months. The ecosystem that still lacks any cooldown mechanism is WordPress. As InfoQ recently reported https://www.infoq.com/news/2026/05/wordpress-plugins-supply-chain/ , an attacker bought 30+ plugins on Flippa, planted a backdoor in the first commit, and waited eight months before activation. No publication delay, no change-of-control review, no mandatory code signing. The VS Code change, modest as it is, makes that absence harder to ignore. For teams managing VS Code deployments, the two-hour delay is on by default with no configuration needed. Those who want longer windows can disable auto-updates entirely and manage extension versions through policy-based allowlists or a curated internal marketplace. VS Code 1.123 is available now https://code.visualstudio.com/updates/v1 123 for Windows, macOS, and Linux.