VS Code 1.108.2 release notes: the recovery build you install when 1.108 acts weird

I’ve watched “minor” VS Code updates take down a whole morning. 1.108.2 exists for that exact kind of day, it’s a recovery build that targets stability regressions from the 1.108 cycle, not a feature drop.

My take: upgrade fast if you hit the regression

Do not treat “recovery build” as a marketing label. In most teams it means “we shipped a bad interaction somewhere, now we’re patching it quickly.” If VS Code started crashing, freezing, or rendering garbage after you moved to 1.108, you probably want 1.108.2.

• Upgrade now: You see crashes, UI glitches, or “this feels broken” behavior that started right after the December 2025 (1.108) update.
• Stage it: Your editor works fine and you manage a fleet, canary 5 to 10 developers for 48 hours, then roll wider.
• Wait a bit: You pin VS Code versions for compliance, or you run a fragile extension stack, test first, then deploy.

What actually changed (with upstream links)

This bit me once on macOS. The app resumes from sleep and the editor looks like a scrambled TV channel, then somebody says “VS Code is broken” and everyone starts rebooting laptops like it’s 2009.

• macOS rendering regression workaround: Upstream tracked “broken rendering on macOS after app resumed from idle state” and related reports, and the recovery update includes the fix/backport work tied to the December 2025 Recovery 2 milestone. See issue #284162 and the related fix PRs #288141 (main) and #289308 (release backport) in the official repo.
• Everything else: Other closed items live under the upstream milestone for December 2025 Recovery 2. I don’t trust “stability improvements” bullets without issue links, so use the milestone list as the source of truth.

Ignore the GitHub commit count. It’s a vanity metric. Read the issues fixed and decide if you have that problem.

How to upgrade (fast path, then the “admin” path)

Keep it simple. If you just need the patch on your own machine, use the built-in updater and move on.

• In-app update (quickest): Open VS Code. On Windows/Linux, go to Help > Check for Updates. On macOS, go to Code > Check for Updates, then restart when prompted.
• Manual install: If your updater fails or you manage installs centrally, download the installer from the official VS Code site, install over the top, then restart.
• Enterprise note: If you block auto-updates, roll this out like any other desktop app patch. Canary first. Push the installer with your normal tooling. Do not flip the switch for everyone at 4 p.m.

Verify the fix in 60 seconds

Check the version. Then try to break it the same way it broke before.

• Confirm the version: Open Help > About and confirm you see 1.108.2.
• Smoke test your real workflow: Open your biggest workspace, run one test, and open the command palette. If you use Remote SSH or dev containers, connect once and watch for extension host errors.
• If the bug was visual: Put the machine to sleep, wake it, and watch the editor render. Boring is the goal.

Known issues (and why “none” is almost never true)

I don’t believe “known issues: none” from any project. Check the upstream milestone anyway, because people file bugs before release notes catch up.

• Upstream tracker: Use the official December 2025 Recovery 2 milestone/issues list to see what got fixed and what users still report.
• If you hit something new: Grab logs, file an issue, and include your OS version, GPU, and repro steps. “It broke” wastes everyone’s time.

Official links

Start here. Then fall down the rabbit hole if you need to.

• GitHub release: https://github.com/microsoft/vscode/releases/tag/1.108.2
• Recovery milestone/issues list: https://github.com/Microsoft/vscode/issues?q=is%3Aissue+milestone%3A%22December+2025+Recovery+2%22+is%3Aclosed+

There’s probably a cleaner way to validate this across every OS image in a company, but this checklist catches the obvious failures quickly.