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](https://github.com/user-attachments/files/32339770/exthost-ba2e1f.cpuprofile)
[exthost-c351c5.cpuprofile](https://github.com/user-attachments/files/32339771/exthost-c351c5.cpuprofile)
[renderer-unresponsive-excerpt.log](https://github.com/user-attachments/files/32339769/renderer-unresponsive-excerpt.log)
[exthost-33fc07.cpuprofile](https://github.com/user-attachments/files/32339772/exthost-33fc07.cpuprofile)
[exthost-450caa.cpuprofile](https://github.com/user-attachments/files/32339768/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 `; 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\\window1\renderer.log`
Copilot Chat log: `%APPDATA%\Code\logs\\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.