When Windows host connects to WSL remote, getEnvPathFromUserShell() was
returning undefined because it checked only process.platform === "win32".
Add remoteName parameter to getEnvPathFromUserShell() and use the
isWindowsHostWithWslRemote pattern (consistent with resolveCommandForPlatform)
to allow shell PATH detection for WSL remotes.
Fixes#9737
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
Fixes#6242, #7810
When Windows VS Code connects to WSL, workspace files are accessed via
vscode-remote:// URIs. Previously, getAllDotContinueDefinitionFiles()
correctly read content via ide.readFile(), but loadYaml.ts discarded
the content and passed only the URI path to RegistryClient, which then
tried to re-read using fs.readFileSync() - failing for remote URIs.
Changes:
- Add optional content field to FileIdentifier (non-breaking)
- RegistryClient.getContent() returns pre-read content when present
- loadYaml.ts passes content along with file identifiers
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
When Windows host connects to WSL remote, getEnvPathFromUserShell() was
returning undefined because it checked only process.platform === "win32".
Add remoteName parameter to getEnvPathFromUserShell() and use the
isWindowsHostWithWslRemote pattern (consistent with resolveCommandForPlatform)
to allow shell PATH detection for WSL remotes.
Fixes#9737
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Add type check in safeParseToolCallArgs to handle cases where
toolCall.function.arguments is already an object instead of a JSON string.
This prevents parameter loss and 'argument is required' errors in tool calls.
Fixes#9151
When Windows VS Code connects to WSL, MCP servers failed to start with
"cmd.exe not found" because resolveCommandForPlatform() wrapped batch
commands (npx, uvx, etc.) with cmd.exe even when the remote is WSL.
Changes:
- Make resolveCommandForPlatform() async to fetch IDE info
- Add isWindowsHostWithWslRemote check (same pattern as PR #9679)
- Skip cmd.exe wrapping when remoteName === "wsl"
- Add tests for WSL, local Windows, Linux, and non-batch scenarios
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
When the VS Code extension runs on Windows but connects to WSL,
direct shell spawning fails because process.platform is "win32"
but commands should execute in the Linux WSL environment.
This caused: spawn powershell.exe ENOENT
The fix detects this scenario and falls back to ide.runCommand(),
letting VS Code handle the remote terminal execution properly.
Fixes#9661
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
During config loading in core, if any non-YAML files are in .continue/agents
or .continue/assistants directories, it tries to load them as configs. This
change filters out .md files by explicitly setting fileExtType to 'yaml' when
loading agent and assistant config profiles.
The getAllDotContinueDefinitionFiles function already supports filtering by
file extension type, but it wasn't being used in ConfigHandler. This ensures
only .yaml and .yml files are loaded as config profiles, preventing errors
when markdown documentation files exist in the agents/assistants directories.
Co-authored-by: dallin <dallin@continue.dev>
Generated with [Continue](https://continue.dev)
Co-Authored-By: Continue <noreply@continue.dev>
