If Copilot works in a local Windows folder but not in WSL, first establish whether the failure is in the WSL connection, extension activation, account access or network request. The difference does not prove that a token is stale or that Copilot must be installed twice.
Confirm the WSL Session and the Affected Feature
Open the intended Linux folder and check that VS Code identifies the correct WSL distribution. Test the terminal and normal file editing before Copilot. If those also fail, repair the WSL connection first.
In Extensions, inspect the Local and WSL groups. VS Code normally chooses the correct installation location for an extension. Install a missing component in the location offered by VS Code, but do not force every extension to run remotely or copy extension directories by hand. See Developing in WSL.
Record whether inline suggestions, chat or both fail. Hover over the Copilot status indicator and read its explanation: a crossed-out icon can indicate a content-exclusion policy, not just failed authentication. Check that your account has access and has not reached a usage limit.
Try Reversible Connection and Account Checks
- Save your work and update VS Code, the WSL extension and Copilot components to compatible supported versions.
- Run Developer: Reload Window and retry a small non-sensitive example in the same WSL workspace.
- Check the account shown in VS Code. If the error is specifically authentication-related, use the Accounts menu to sign out of the affected GitHub account, reload, and sign back in.
- Open View → Output and inspect the Copilot-related channel at the failure time. Keep the error text rather than repeatedly resetting the session.
GitHub documents the sign-out/reload/sign-in sequence. It is not mandatory for every WSL problem. Do not paste personal access tokens into a shell profile or copy VS Code credential storage between Windows and Linux.
Check the Actual Network Path and Proxy
Windows, WSL and a container opened from WSL can have different network configuration. From the environment that appears to be failing, GitHub’s documented connectivity checks are:
curl --verbose https://copilot-proxy.githubusercontent.com/_ping
curl --verbose https://api.githubcopilot.com/_pingUse curl.exe for a Windows-side comparison if PowerShell’s curl is an alias. HTTP 200 confirms reachability to that endpoint, not a valid Copilot plan or all required connections. A timeout, certificate error and authentication failure require different investigation. See GitHub’s network guide.
If a remote extension is inheriting a local proxy that is invalid in WSL, VS Code’s WSL guide documents the Remote setting Http: Use Local Proxy Configuration. Disable it only for that situation, then supply the approved remote proxy through Remote settings or the server’s launch environment. Merely exporting a variable in an already-open terminal does not update a running extension host. Restart the relevant server session after an environment change.
Work with IT on firewall or certificate failures. Do not allow all WSL traffic or disable TLS checks as a blanket workaround.
Recover Without Stopping Unrelated WSL Work
After sleep or VPN changes, first reconnect the affected VS Code window and retest. An expired token is one possibility, not a proven explanation for every post-sleep error.
wsl --shutdown is not a Copilot-only reset: Microsoft documents that it terminates all running distributions and the WSL 2 virtual machine. It can interrupt terminals, servers and other work. Do not use it casually; save and coordinate any necessary restart.
If the problem remains, search the Command Palette for Chat Diagnostics. Follow the VS Code troubleshooting guide and record the distribution, versions, local-versus-WSL test result and exact error. Redact tokens, proxy credentials and private code before sharing logs.
Official documentation checked: October 14, 2026.