Extension host OOM-crashes within seconds to ~1 min of launching 2+ parallel background Agent subagents (Windows)

Summary

The VS Code extension host reliably OOM-crashes ("Extension host terminated unexpectedly" / auto-restart) within seconds to ~1 minute of launching just 2 parallel background Agent subagents from the Claude Code extension. Three independent mitigation attempts (raising the extension host's V8 heap via argv.json's js-flags, setting NODE_OPTIONS=--max-old-space-size=8192 as a persistent env var, and reducing configured MCP server count/weight) have all been tried and confirmed not to fix it.

Environment

• OS: Windows 11 Pro
• VS Code: 1.141.0 (commit 2a59476c9bfcb90b3ddc372c36762471b7dfad1c), update.mode: "none" set (ruled out the unrelated auto-updater-cycle crash cause separately)
• Claude Code extension: anthropic.claude-code@2.1.296
• Repro happens whether the Claude Code panel is docked in the sidebar or opened as an editor tab

Reproduction steps

1. Open a reasonably large repo (ours: ~a few hundred TS/TSX files across a server, client, and CDK infra package).
2. In a single Claude Code conversation, invoke the Agent tool twice in the same turn (2 parallel background subagents), each given a real, moderately heavy read-only research task (e.g. "audit this feature for consistency" / "survey the codebase for X pattern") - not a trivial one-liner.
3. Watch %APPDATA%\Code\logs\<session>\window1\renderer.log.

Expected

Both agents run to completion, or at minimum the extension host survives.

Actual

The extension host (LocalProcess, the process hosting Anthropic.claude-code and all other loaded extensions) terminates unexpectedly within seconds to ~1 minute of launch, every time. VS Code auto-restarts it, but any in-flight background Agent work is lost - on the next turn, those agents come back from ListAgents/task notifications as stopped with no completion record and are not resumable ("No reachable agents").

Two independent reproductions today, same signature both times:

Run 1 (3 configured MCP servers removed beforehand, but at the time of this run, claude.ai Microsoft 365 - 50 tool schemas - was still connected): agents launched 17:19:39; renderer.log:

2026-10-13 17:19:46.827 [error] Extension host (LocalProcess pid: 45560) terminated unexpectedly. The following extensions were running: vscode.github-authentication, ..., Anthropic.claude-code, ...
2026-10-13 17:19:46.827 [info] Automatically restarting the extension host.

~7 seconds from launch to crash - the fastest reproduction we've seen.

Run 2 (after disconnecting the claude.ai Microsoft 365 connector and removing two unused plugins, then a full VS Code quit+relaunch to confirm the removal synced): agents launched 17:35:16.505; renderer.log:

2026-10-13 17:35:59.051 [error] Extension host (LocalProcess pid: 25308) terminated unexpectedly. The following extensions were running: ..., Anthropic.claude-code, ...
2026-10-13 17:35:59.052 [info] Automatically restarting the extension host.

~42.5 seconds from launch to crash, with a much lighter MCP footprint.

An earlier incident the same day reproduced with only 3 parallel agents and a ~1-3 minute delay before crashing (same signature), and a separate incident that day crashed with zero Agent subagents running - only a long-running background Bash task (a Docker build / cdk deploy) - suggesting the trigger may be heavy background work in general, not Agent subagents specifically.

Mitigations tried, all confirmed NOT to fix it

1. argv.json's js-flags: "--max-old-space-size=8192", with a full VS Code quit+relaunch. Confirmed via process inspection (Get-CimInstance Win32_Process) that no running process - including the crashed extension host's own PID - ever carried a --max-old-space-size or js-flags argument. Root cause: modern VS Code spawns the extension host via Electron's "Utility Process" API (--type=utility --utility-sub-type=node.mojom.NodeService), which does not inherit argv.json's js-flags the way the older child-process-based extension host model did.
2. NODE_OPTIONS=--max-old-space-size=8192 set as a persistent user environment variable (setx, confirmed SUCCESS, confirmed present via [Environment]::GetEnvironmentVariable('NODE_OPTIONS','User') at crash time). Reproduced anyway (Run 1 above).
3. Reducing configured MCP server count/weight - disconnected the heaviest configured MCP connector (claude.ai Microsoft 365, 50 tool schemas) and removed two unused plugins, confirmed via claude mcp list/claude plugin list after a full restart that the removal synced. Reproduced anyway (Run 2 above), though slower (42.5s vs 7s) - inconclusive whether MCP weight affects time-to-crash without being the root cause.

Notes

• This is a different, confirmed-separate issue from VS Code's own auto-updater apply/rollback cycle (also observed on this machine the same day, fixed independently via "update.mode": "none") - the extension host OOM happens with the updater setting already correctly in place.
• Each crash is non-catastrophic only because we've adopted a workaround of having every background Agent subagent checkpoint findings to a scratch file after each investigation section rather than only in its final report - without that, the crash silently loses all in-progress work with no recovery path, since ListAgents shows the stopped agents as unreachable afterward.
• Happy to provide the full renderer.log files, or reproduce again with any specific diagnostic flags/instrumentation the team wants.