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

[vishalnarayan2809]

Describe the bug

Environment

• VS Code: 1.122.1
• GitHub Copilot Chat: 0.50.1
• WSL: Ubuntu
• OS Host: Windows 11
• Copilot account: Educational quota
• Remote Development: WSL

Description

GitHub Copilot Chat takes approximately 40-80 seconds to become available when running inside WSL.

The delay is reproducible across VS Code restarts and occurs even after:

• Clearing Copilot state
• Clearing workspace storage
• Reinstalling Copilot Chat
• Disabling local indexing
• Reducing workspace index size
• Disabling memory features
• Disabling MCP features
• Optimizing Git settings
• Verifying filesystem permissions

The extension itself activates quickly, but startup appears blocked by CopilotCLIChatSessionContentProvider.listSessions.

Observed Logs

ConversationFeature: Waiting for copilot token

[CopilotCLIChatSessionContentProvider] listSessions took 40514ms

Logged in as <account>

Got Copilot token

Copilot Chat: 0.50.1

Failed to create database. Falling back to in-memory db: Error: unable to open database file

Subsequent calls are fast:

[CopilotCLIChatSessionContentProvider] listSessions took 14ms
[CopilotCLIChatSessionContentProvider] listSessions took 38ms
[CopilotCLIChatSessionContentProvider] listSessions took 5ms

The large delay occurs only once during startup.

What Has Been Verified

Extension activation is not the problem

VS Code reports:

GitHub Copilot Chat
Activation: 2348ms

Network is not the problem

time curl -I https://api.github.com

Result:

real 0m0.174s

Session database is tiny

session-store.db       4 KB
session-store.db-shm  32 KB
session-store.db-wal 149 KB

Session state is tiny

du -sh ~/.copilot/session-state

Result:

4.0K

Workspace indexing does not affect the issue

Tested:

"github.copilot.chat.localIndex.enabled": false
"github.copilot.chat.workspace.maxLocalIndexSize": 100

No measurable improvement.

Git is not the problem

Git operations complete in milliseconds and repository scanning is fast.

Additional Observation

Copilot reports:

Failed to create database. Falling back to in-memory db.

However, Copilot successfully creates:

~/.vscode-server/data/User/globalStorage/github.copilot-chat/session-store.db
~/.vscode-server/data/User/globalStorage/github.copilot-chat/session-store.db-wal
~/.vscode-server/data/User/globalStorage/github.copilot-chat/session-store.db-shm

which suggests the failing database may be a different internal store.

Expected

Copilot Chat should become available within a few seconds, similar to Codex and other AI extensions running in the same WSL environment.

Actual

Copilot Chat consistently requires 40-80 seconds before becoming usable due to an extended listSessions operation during startup.

Reproducibility

100% reproducible across restarts.

Affected version

No response

Steps to reproduce the behavior

No response

Expected behavior

No response

Additional context

No response

[OmerFI]

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.

[OmerFI]

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)

[OmerFI]

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)