Continue.dev activates Windows extension host even when VS Code is running in WSL

[rdcoe]

Before submitting your bug report

• I've tried using the "Ask AI" feature on the Continue docs site to see if the docs have an answer
• I'm not able to find a related conversation on GitHub discussions that reports the same bug
• I'm not able to find an open issue that reports the same bug
• I've seen the troubleshooting guide on the Continue Docs

Relevant environment info

• Windows 11
• WSL: Ubuntu 22.04.5 LTS
• Continue.dev: latest version from Marketplace
• Ollama: installed and running inside WSL
• Workspace: located in WSL filesystem
• VS Code host: WSL (confirmed by UI)

Description

When VS Code is running in a WSL session, Continue.dev installs its extension files into the WSL extension host (~/.vscode-server/extensions), but the extension does not activate in WSL. Instead, Continue.dev activates in the Windows extension host, even though VS Code itself is fully running in WSL.

This results in Continue.dev reading and writing configuration files from the Windows filesystem (C:\Users<user>.continue\config.yaml) instead of the WSL filesystem (~/.continue/config.yaml), and the WSL copy of the extension remains dormant.

This behaviour is unique to Continue.dev — other extensions installed in WSL activate correctly.

To reproduce

1. Launch VS Code from a Windows shortcut
2. VS Code automatically reopens in WSL (because that was the last used host)
3. Install Continue.dev while VS Code is running in WSL
4. Observe:
   • Extension files are installed into ~/.vscode-server/extensions
   • Continue.dev does not activate in WSL
   • Continue.dev activates in the Windows extension host instead
5. Continue.dev reads/writes:
   • Windows config: C:\Users<user>.continue\config.yaml
   • NOT the WSL config: ~/.continue/config.yaml
6. Adding models via the Continue UI updates the Windows config file
7. The WSL config file remains empty and unused
8. Only when launching VS Code via '$ code .' from a WSL shell does Continue.dev finally activate in WSL and use the correct config.

Note that I actually uninstalled continue.dev from vscode, using the extension manager, before re-launching code from the command line in a WSL terminal (step 8); vscode only uninstalled the extension from the Windows filesystem, leaving the WSL filesystem with the extension still installed.

Expected Behaviour

• When VS Code is running in a WSL session, Continue.dev should:
• Activate in the WSL extension host
• Read/write config from ~/.continue/config.yaml
• Ignore the Windows extension host unless explicitly installed there
  This is how other WSL‑compatible extensions behave.

Impact

• Incorrect config resolution
• Incorrect model discovery
• Workspace indexing fails or uses wrong paths
• Embedding models not found
• Model dropdown shows only Windows‑side models
• Users cannot reliably configure Continue.dev in WSL
• Behaviour differs from all other WSL‑aware extensions

Hypothesis
Continue.dev may be declaring itself as:
"extensionKind": ["ui"]

or otherwise binding activation to the UI host instead of the workspace host.
This would cause:

• UI activation on Windows
• Workspace activation never firing in WSL
• Config resolution happening on the Windows side
• WSL extension files being installed but unused

Workaround
Launching VS Code via:
$ code .

from a WSL shell forces the WSL extension host to become primary, and Continue.dev activates correctly.

Request
Please review Continue.dev’s:

• extensionKind declaration
• activation events
• remote/WSL host detection
• config path resolution logic
  The current behaviour suggests Continue.dev is not correctly activating in WSL even when VS Code is running entirely inside a WSL session.

Log output

[shanevcantwell]

I've been in the wsl stuff and should have this addressed. Here's a good description with associated links:

This is a known architectural constraint. Continue declares extensionKind: ["ui", "workspace"] because it needs UI host access for webviews, clipboard, and platform-matched native modules (ripgrep, SQLite). Flipping to ["workspace", "ui"] breaks those features.

The tradeoff is that when VS Code connects to WSL, the extension process runs on Windows while the workspace is in WSL — causing cross-filesystem path resolution failures throughout the codebase.

A series of fixes have been merged to handle this, with the detection pattern:

process.platform === "win32" && !["", "local"].includes(ideInfo.remoteName)
Merged fixes:

#9679 — Terminal commands spawn powershell.exe instead of using WSL shell
#9739 — Config YAML loading fails on vscode-remote:// URIs
#9740 — MCP server spawn wraps commands in cmd.exe unnecessarily
#9934 — getEnvPathFromUserShell() returns undefined for WSL
#10391 — Generalizes terminal fix to all remote types (Dev Container, SSH, Codespaces)
Open:

#10451 — Agent config loading falls back to config.json on Windows path

The code . workaround you found changes which host VS Code treats as primary, but the fixes above address the root path resolution issues so the extension works correctly regardless of how VS Code is launched.

[rdcoe]

That's terrific that the root cause will be fixed. Would you like me to close this issue per your comment, or leave it open until the commits have been verified?

[shanevcantwell]

Let the PR close it so there is clear cross referencing. And I'm glad to be getting these fixed for my own sake too!