Extension host pins one CPU core for hours, log-silent - measured as a native file-watcher busy-loop (~245k other-I/O ops/s, 0 reads/s) on Windows

Summary

VS Code extension hosts in windows with active Claude Code sessions recurrently pin one P-core (95-100% of a core) for hours. The extension's own log is silent during the burn (heartbeats only). On a thin laptop this presents as an overheating machine at "6-14% CPU" - a single pinned core boosting to ~5 GHz drives an i9-12900HK to TjMax while Task Manager looks idle. Three separate incidents in one day, in three different windows (two different Claude accounts/config dirs, both OneDrive-synced and purely local workspaces).

Environment

• VS Code 1.134.0 (110a328ea54), x64
• anthropic.claude-code 2.1.240
• Windows 11 Pro build 26200
• i9-12900HK (20 threads), 64 GB
• Two Claude config dirs: ~/.claude and a second account dir whose skills/agents/commands/hooks subdirs are NTFS junctions into ~/.claude
• Multiple VS Code windows open concurrently, each with the extension active

Measured evidence

Killing the spinning host restored the machine instantly both times it was tried (package power 36->16 W and 29->10 W within seconds), so the host process is conclusively the workload.

On the third incident I sampled the spinning host's Win32 I/O counters over 10 s while it sat at ~98% of one core:

reads/s = 0    writes/s = 0.9    other/s = 245,552

~245k "other" I/O operations per second with essentially zero reads/writes is the signature of a native directory-watch busy-loop (ReadDirectoryChangesW layer), not JS work, GC, or a rescan loop - a JS-level spin shows near-zero I/O. This matches the Windows watched-directory busy-loop documented in nodejs/node#61398 (libuv fix merged 2026-03-31). Question for the team: does the runtime bundled with current VS Code / the extension carry that libuv fix?

Additional context

• During the sustained burn the extension log emits only once-per-minute heartbeats - no errors, no activity - so the loop is below the extension's logging.
• Environment factor that may matter: the junctioned second config dir means the same physical ~/.claude/skills tree is watchable via two logical paths. Bulk rewrites of that tree (a config-deploy hook we have since fixed on our side) produced 300-600 Detected skill change events per rewrite in EVERY open window, each followed by multiple full Loaded N unique skills reload cycles - each file appearing 3-4x per storm suggests duplicate watch registrations across the junction paths.
• However, the third spin began ~35 minutes after the last rewrite, with zero fresh file changes (mtimes verified) - so the storm is at most a trigger/amplifier; the loop latches and persists on its own.
• Incidents occurred in both an OneDrive-synced workspace and a purely local git-repo workspace; the common factor is an active Claude Code session in the window.
• Possibly related open reports: #80767, #19393, #22509.

What I can provide

A hardware/process watchdog now auto-captures the I/O discriminator on every recurrence, and I can capture an extension-host CPU profile and/or ETW trace on the next incident if useful. Happy to run diagnostics builds or verbose logging.