GitHub Copilot Chat blocks the shared extension host for a full 5 seconds (single synchronous `consume` call) while signed in but idle, breaking other extensions' webviews

exthost-ba2e1f.cpuprofile exthost-c351c5.cpuprofile renderer-unresponsive-excerpt.log exthost-33fc07.cpuprofile exthost-450caa.cpuprofile

• Copilot Chat Extension Version: 0.66.0 (bundled with VS Code 1.138.0, publisher: GitHub, buildType: prod)
• VS Code Version: 1.138.0 (system installer, C:\Program Files\Microsoft VS Code)
• OS Version: Windows 11 Pro 25H2, build 26200.9457 (64-bit), 13th Gen Intel i7-13700HX (16C/24T), 31.6 GB RAM, NVMe SSD
• Feature (e.g. agent/edit/ask mode): Not using Copilot at all — no request in flight, chat view not open. Copilot Chat was signed in and running in the background only (Got Copilot token for <user>; sku free_limited_copilot). The stalls occur in background/startup processing of the shared extension host.
• Selected model (e.g. GPT 4.1, Claude 3.7 Sonnet): Not applicable — I never sent a request. Copilot Chat's own log shows BYOK: registered 9 provider(s) and no model was selected by me.
• Logs: See "Logs and profiles" below. Key line, repeated 4 times across 4 separate window launches: UNRESPONSIVE extension host: 'github.copilot-chat' took 99.88961883031027% of 5013.432ms, saved PROFILE here: 'file:///c%3A/Users/.../exthost-c351c5.cpuprofile' Renderer log: %APPDATA%\Code\logs\<session>\window1\renderer.log Copilot Chat log: %APPDATA%\Code\logs\<session>\window1\exthost\GitHub.copilot-chat\GitHub Copilot Chat.log

Steps to Reproduce:

1. Open VS Code 1.138.0 with Copilot Chat 0.66.0 enabled (default bundled state), signed in, in a workspace with large file trees — in my case two roots, one of them a WSL remote folder, plus a sibling tool's session store under the user profile holding ~11,000 files / 3.3 GB that is walked on a timer.
2. Use the editor normally and do NOT interact with Copilot — do not open Chat, do not send any request.
3. Wait. Within 1–3 minutes the extension host is reported unresponsive. VS Code's own profiler attributes the entire 5 s window to Copilot Chat.
4. Observed 4 times in 4 separate window launches over ~25 minutes (15:11, 15:18, 15:21, 15:35 local). Recorded twice again in a 2-minute-old session right after a reboot, so it is not session state.

Actual behavior: Copilot Chat holds the shared extension host for a full 5000 ms in a single synchronous call and never yields to the event loop for that entire window. VS Code's unresponsive check only fires at ~5 s, so 5000 ms is the observed floor, not necessarily a ceiling. During the stall every other extension in the same host is frozen: input into webview panels lags (the extension's own webviews report input_lag_sample of 424 ms and 912 ms), and other extensions' webviews fail to initialize at all — see "Consequence 1".

Expected behavior: Background Copilot Chat processing should be chunked or run off the shared extension host, so that a stall in one extension cannot freeze the whole workbench and take down unrelated third-party extensions with it. A bounded pending queue (or yielding between drains) would turn a workbench-wide freeze into a bounded slowdown.

This looks like the same defect as #335194

Filing this per the template, but the evidence points at the issue already reported by @StayWJ:

#335194 — "Copilot 0.64.1: bulk exclusion filtering stalls shared extension host in large workspaces (Limiter.consume / Array.shift)", still open today.

That report identifies the algorithmic cause (bulk file-exclusion filtering enqueueing the entire result array through a Limiter(20) whose pending queue uses Array.shift(), so the queue length is unbounded). My evidence is the complementary half — what that queue does to the workbench when it grows — and it also shows the defect still reproduces on 0.66.0, one minor version above the reported 0.64.1. Please dedupe as you see fit; I am attaching data rather than asking for a separate fix.

Profiles — the hot frame is literally consume

These are the profiles VS Code itself wrote when it caught the host unresponsive (attached). Self-time aggregated by call frame:

exthost-c351c5.cpuprofile   (from the 15:18:35 event)   total 5497 ms
  5002.3 ms  91.0%  consume @ dist/extension.js:23
   482.6 ms   8.8%  (anon) @ dist/extension.js:1073
     5.8 ms   0.1%  (program)
     2.9 ms   0.1%  isCopilotIgnored @ dist/extension.js:6120
     1.7 ms   0.0%  syncEnablement @ dist/extension.js:6120

exthost-33fc07.cpuprofile   (from the 15:21:39 event)   total 5469 ms
  4995.4 ms  91.3%  consume @ dist/extension.js:23
   467.7 ms   8.6%  (anon) @ dist/extension.js:1073

exthost-ba2e1f.cpuprofile   (from the 15:35:11 event)   total 5457 ms
  4996.6 ms  91.6%  consume @ dist/extension.js:23
   450.1 ms   8.2%  (anon) @ dist/extension.js:1073

Same frame, same share (91.0 / 91.3 / 91.6 %), three independent captures in three different windows. The only Copilot functions sampled inside that window are consume, syncEnablement, isCopilotIgnored / isCopilotIgnoreEnabled and get copilotToken — all on the exclusion/ignore-filtering path. The caller of consume is an anonymous frame at dist/extension.js:1073.

For scale: other extensions in the same host appear in the same log at 35 % of 73 ms and 27 % of 13.8 ms. That is two orders of magnitude apart.

Consequence 1 — sibling webviews cannot initialize

Anthropic's Claude Code panel is a webview served by the same extension host. While the host was blocked it failed with:

Error loading webview: Error: Could not register service worker: InvalidStateError: Failed to register a ServiceWorker: The document is in an invalid state.

This is VS Code's known webview service-worker registration race (microsoft/vscode#125993), which a 5-second-blocked host loses reliably. Disabling Copilot Chat alone made that panel work again on this machine — same VS Code build, same other extensions, no other change. While Copilot Chat was enabled the panel was unusable.

Consequence 2 — host processes died with identical stack-overflow signatures

Three utility processes crashed within the same second (AppHangB1 at 15:11:31, Application Hang id 1002 at 15:11:32). Parsing the three Crashpad minidumps:

ExceptionCode    = 0xC0000005  (EXCEPTION_ACCESS_VIOLATION)
ExceptionAddress = 0x7FF85226FA7D   (identical in all three)
  -> C:\WINDOWS\SYSTEM32\ntdll.dll  base=0x7FF852260000  offset=0xFA7D  (stack overflow probe)

The dump with the largest module set was the extension host, and it had @github/copilot/sdk/prebuilds/win32-x64/runtime.node loaded. I am not claiming the overflow itself is Copilot's fault — only that the process that died was a host saturated in this path, with three threads reaching the stack limit at the same instruction in the same second. The Crashpad directory has accumulated 10 dumps / 357 MB, several in this same triple-crash pattern on earlier dates.

Not resource exhaustion

12.9 GB RAM free of 31.6 GB; commit charge 19.9 GiB against a 75.6 GiB limit; 44 GB page file; C: 54 % free; no Windows resource-exhaustion event recorded; no OOM in the WSL VM. Copilot Chat's own log shows a healthy, signed-in, correctly configured install — token acquired, BYOK providers registered, no 429s, no auth errors. This is a healthy activation blocking the host, not a misconfigured one.

What does not fix it

• Reloading the window / restarting VS Code — recurs in every new window (four separate launches, 15:11 → 15:35).
• code --uninstall-extension github.copilot-chat --force — refused: Extension 'github.copilot-chat' is a Built-in extension and cannot be uninstalled.
• Disabling Copilot Chat does stop the stalls and restores the sibling webview — but the extension is bundled, enabled by default, and cannot be removed, so users who never opted in absorb the cost.

Logs and profiles

Attached:

• exthost-c351c5.cpuprofile, exthost-33fc07.cpuprofile, exthost-ba2e1f.cpuprofile — the three profiles from the events quoted above
• renderer-unresponsive-excerpt.log — matching renderer.log excerpts from all affected sessions

On request I can also provide: the full renderer.log and GitHub Copilot Chat.log for each session, the three minidumps, the Windows Application/System event log export around the crash, or run any instrumented build / additional repro steps.