VSCode extension 2.1.247: Claude Code panels freeze on any git commit; extension-side process grows +600MB in 5s

Environment

• Claude Code VSCode extension 2.1.247 (cc_version=2.1.247.5e0), auto-updated from 2.1.246 on 2026-08-27; freezes began immediately after the update
• VSCode on Windows 11 Pro (10.0.26200)
• Two VSCode windows open on the same workspace, each with a long-running Claude Code session (large transcripts: one session ~940 messages)
• Workspace: mid-size Python repo, 854 tracked files, 14 MB git pack, git status completes in 62 ms

Symptom

Any git commit in the workspace (even git commit --allow-empty, 307 ms wall time, nothing staged) freezes the Claude Code panels in every open window within ~2 seconds:

• Typing into the panel's text box still renders, and messages can be posted, but nothing loads or moves and posted messages never reach the agent.
• The rest of VSCode keeps working (editor, other panels).
• The agent process itself keeps running through the freeze (its background work completes normally).
• Only a full VSCode restart recovers the panels.

Measured profile

A 300 ms process sampler ran across a reproduction (empty commit at 13:08:50):

| time | observation |
|---|---|
| 13:08:50 | git commit --allow-empty completes in 307 ms |
| 13:08:52.6 | one Code.exe process starts consuming a full core |
| 13:08:52.6 → 13:08:57.8 | its working set grows 689 MB → 1296 MB (+600 MB in 5 s), still climbing when sampling stopped |

Windows Defender never crossed the sampler's 50 ms/300 ms CPU threshold, so AV scanning is excluded. The repo is excluded as a cause by the 62 ms git status and the empty-commit repro (no hook work, no staged files, no tree change).

Reproduced 3+ times across the day; correlation is 1:1 with commits. Under additional memory load (a parallel 6-process agent workload), the same trigger coincided with one hard machine crash, consistent with the runaway allocation exhausting RAM.

Hypothesis (unverified)

The freeze scope (only Claude Code panels; posts accepted but never processed) suggests the extension's git-change handler recomputes panel/diff state on HEAD change at a cost that scales with session transcript size; both affected sessions had very large transcripts. A fresh, small session may not reproduce.

What would help

A cap or debounce on git-change reprocessing, or moving it off the panel message path. Happy to provide the sampler script, the raw sample TSV, or to run an instrumented build.