GitHub Copilot Chat in WSL experiences 40-80 second startup delays due to CopilotCLIChatSessionContentProvider.listSessions #3652

Activity

1. vishalnarayan2809

   added

   triage

   on Jun 3, 2026
2. vishalnarayan2809

   added the

   Bug

   issue type on Jun 3, 2026
3. examon

   added

   area:sessionsSession management, resume, history, session picker, and session stateSession management, resume, history, session picker, and session state

   area:platform-windowsWindows-specific: PowerShell, cmd, Git Bash, WSL, Windows TerminalWindows-specific: PowerShell, cmd, Git Bash, WSL, Windows Terminal

   on Jun 3, 2026
4. github-actions

   removed

   triage

   on Jun 3, 2026
5. OmerFI commented on Jun 6, 2026

   

   OmerFI

   on Jun 6, 2026

   Last edited by OmerFI

   More actions

   Edit: the settings block below turned out not to be a reliable workaround (the freeze recurred on later cold starts with the settings active). Full correction + refined root cause: microsoft/vscode#319710 (comment) — and as I note in the follow-up, the code lives in the VS Code built-in Copilot Chat extension, so the fix belongs in that repo.

   Same root cause here, but much worse — and it doesn't just delay Copilot Chat: it freezes the entire extension host, taking every other extension down with it (including Python/Pylance).

   Environment: Windows 11 + WSL2 (Ubuntu), VS Code 1.123.0, Copilot Chat 0.51.0 (built-in), Remote-WSL, educational quota (same as OP).

   Measurements — first listSessions per extension-host start, from 3 days of GitHub Copilot Chat logs:

   430,763 ms / 161,195 ms / 140,779 ms / 101,324 ms / 100,861 ms / 80,973 ms / 61,157 ms
   

   Subsequent calls: 1–59 ms. So it's always the first (cold) call per extension host.

   Evidence the whole extension host event loop is blocked during that window:

   • Every extension's log goes silent for the exact same time window (GitLens, Python, Claude Code, ruff — all of them), then they all resume at the same millisecond.
   • onLanguage:python activation events (Pylance, debugpy, Jupyter) are only processed after the freeze ends — Python files are unusable until then. In my case ExtensionService#_doActivateExtension ms-python.vscode-pylance was logged 158 s after window start.
   • vscode-python-environments' PET watchdog (Request 'refresh' timed out after 30000ms) fires after 157 s instead of 30 s — i.e. even setTimeout timers are delayed, which rules out a mere slow async operation.
   • The remote agent logs [ExtensionHostConnection] The client has reconnected every ~20 s during the freeze (exthost can't answer keepalives).
   • The freeze always ends at the exact moment [CopilotCLI] OpenTelemetry enabled: exporter=file + listSessions took NNN ms are logged, and activationBlocker from 'languageModelAccess' reports the same duration as the freeze.

   This is likely also the real cause behind microsoft/vscode-python-environments#1546 and microsoft/vscode-python-environments#1554 — identical signature there (Environment discovery took 130–150s, Setup appears hung during stage: managerRegistration, PET configure timeout). On my machine the Python side itself accounts for ~0.5 s (verified by running the bundled pet find standalone); everything else was this freeze.

   Settings I initially tried (later found unreliable — see edit note above):

   "github.copilot.chat.claudeAgent.enabled": false,
   "github.copilot.chat.cli.showExternalSessions": false,
   "chat.viewSessions.enabled": false

   Triage detail: CopilotCLIChatSessionContentProvider.listSessions goes through _loadSdk(), which loads the bundled dist/cli.js (~14 MB) and runs its first-time startup init. Loading that bundle standalone (node -e "require('.../dist/cli.js')") spends ~10 s wall with only ~1.4 s CPU before exiting — i.e. it blocks on I/O (not CPU) during init, which would explain why the freeze duration varies (61–430 s) independently of session data size (~/.copilot is 16 KB here, 0 sessions). The host-side concern is that this heavy bundled SDK is cold-loaded eagerly on the extension-host thread at startup.
6. OmerFI commented on Jun 6, 2026

   

   OmerFI

   on Jun 6, 2026

   More actions

   Follow-up: the code that triggers this (CopilotCLIChatSessionContentProvider / _loadSdk()) lives in the VS Code built-in Copilot Chat extension rather than the CLI itself, so the VS Code repo is probably where this gets fixed. It's tracked there as microsoft/vscode#319698 (same report) and microsoft/vscode#319710 (extension host blocked 60–135 s) — both assigned. I posted the detailed analysis + a verified settings-only workaround here: microsoft/vscode#319710 (comment)
7. OmerFI commented on Jun 8, 2026

   

   OmerFI

   on Jun 8, 2026

   More actions

   Correction: the three-setting workaround I posted earlier is not reliable — the freeze recurred on later cold starts with the settings active (the initial fast result was a warm hit). Refined root cause + why there's no clean completions-preserving workaround in 1.123: microsoft/vscode#319710 (comment)
8. patniko commented on Oct 26, 2026

   

   patniko

   on Oct 26, 2026

   Collaborator

   More actions

   Thanks for the detailed report and analysis. This startup delay comes from VS Code's built-in Copilot Chat extension (its Copilot CLI session provider loading at startup) rather than from Copilot CLI itself, so it's tracked in the VS Code repository: microsoft/vscode#319710 has been closed as fixed in the VS Code 1.125 milestone, and microsoft/vscode#319698 was closed as a duplicate. Please update to the latest VS Code, and if the delay persists, open an issue at https://github.com/microsoft/vscode/issues. Closing as answered — feel free to reopen if this doesn't cover your case.

   _{Triaged as part of a Copilot SDK backlog review, with help from GitHub Copilot.}
9. patniko

   closed this as completedon Oct 26, 2026