Copilot Chat activation delayed 80-120s in WSL remote due to `onDidChangeSessions` IPC proxy latency

Open
#320,600 1 comment 0 reactions 1 assignee View on GitHub

@chrmarti is already working on this.

Since Jun 9, 2026.

Assessment

This issue has not been assessed yet.

Description

Bug: Copilot Chat activation delayed 80-120s in WSL remote due to onDidChangeSessions IPC proxy latency

  • Copilot Chat Extension Version: 0.51.0
  • VS Code Version: 1.123.0 (6a44c352bd24569c417e530095901b649960f9f8)
  • OS Version: Windows 11 (10.0.26200) with WSL2 remote
  • Feature: Startup / extension activation
  • Selected model: N/A (issue occurs before any model is usable)
  • Logs: See below

Steps to Reproduce

  1. Open VS Code on Windows with a WSL2 remote workspace (via ms-vscode-remote.remote-wsl)
  2. Open the GitHub Copilot Chat output panel (View → Output → GitHub Copilot Chat)
  3. Reload the window (Developer: Reload Window) to trigger a cold extension host start
  4. Observe the timestamps in the output panel

Expected Behavior

Copilot Chat should activate within a few seconds of VS Code being ready, consistent with local (non-remote) workspace behaviour.

Actual Behavior

Copilot Chat activation is blocked for 80–120 seconds on every cold start. The output log shows:

15:34:41.035  ConversationFeature: Waiting for copilot token or BYOK model to activate conversation feature
              ... ~84 seconds of silence ...
15:36:05.697  Logged in as <user>
15:36:06.864  Got Copilot token for <user>       ← token fetch itself takes only ~1.2s
15:36:06.912  activationBlocker from 'languageModelAccess' took for 84285ms
15:36:07.809  activationBlocker from 'conversationFeature' took for 85187ms
15:36:07.751  AuthenticationService: firing onDidAuthenticationChange from handleAuthChangeEvent. Has token: true
15:36:07.751  ConversationFeature: Activating contributions

Root Cause (investigated via source code)

Two activationBlocker promises in extension.js are waiting on c.copilotToken:

1. conversationFeature (ConversationFeature class):

this.activationBlocker = h.p;  // resolves only when copilotToken becomes truthy
c.copilotToken
  ? this.logService.info("ConversationFeature: Copilot token already available")
  : (Uee(Oee.WillWaitForCopilotToken),
     this.logService.info("ConversationFeature: Waiting for copilot token..."));
this._disposables.add(c.onDidAuthenticationChange(() => { v(); }));

2. languageModelAccess (ure class):

this.activationBlocker = Promise.all([
  this._registerChatProvider(),   // calls _getToken() → getCopilotToken()
  this._registerEmbeddings()
]).then(() => {});

Both blockers resolve only after AuthenticationService.onDidAuthenticationChange fires, which is triggered by vscode.authentication.onDidChangeSessions.

The problem: vscode.github-authentication (which owns GitHub sessions) runs in the local Windows extension host. Copilot Chat runs in the remote WSL extension host. The onDidChangeSessions event must be proxied over the WSL IPC bridge (ExtHostAuthenticationMainThreadAuthentication). This bridge only becomes operational after WSL authority resolution completes (~525ms), and in corporate network environments the proxied event delivery appears to stall for 80–120 seconds before arriving in the remote host.

Once the event arrives, the actual copilot_internal/v2/token API call completes in ~1.2 seconds — confirming the delay is entirely in IPC event delivery, not network latency.

Verified: DNS resolution is fast (134ms), direct HTTPS to api.github.com and copilot-proxy.githubusercontent.com both connect in under 200ms from WSL. The delay is not network-related.

Not WSL-specific in theory, but only manifests with remote extension hosts because local workspaces have both vscode.github-authentication and Copilot Chat in the same extension host, making onDidChangeSessions delivery synchronous.

Startup Performance Marks (remoteExtHost)

code/extHost/ready                                    offset ~946ms
code/extHost/willActivateExtension/GitHub.copilot-chat  offset ~3342ms
code/chat/ext/willActivate                            offset ~3342ms
code/chat/ext/willWaitForCopilotToken                 offset ~4259ms
  ... no didWaitForCopilotToken for ~80,000ms ...
code/extHost/didActivateExtension/GitHub.copilot-chat   offset ~120,000ms+

Suggested Fix

In the ConversationFeature and languageModelAccess constructors, proactively call vscode.authentication.getSession('github', [...], { silent: true }) at activation time rather than waiting passively for onDidChangeSessions. This would trigger the session lookup immediately and avoid depending on the proxied event being delivered first.

Alternatively, the VS Code platform could eagerly forward any cached authentication sessions to remote extension hosts as part of the extension host initialisation handshake, before extensions begin activating.

Dominant language
TypeScript
Stars
193k
Forks
42.9k
PR merge metrics
PR metrics pending

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from microsoft/vscode

All issues in microsoft/vscode

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.