AgentArmorHQ
Sign in
Configuration

Run Continue MCP servers from WSL with a bash wrapper config

AgentArmorHQ team2 min read

You will add a Continue MCP server entry that launches through WSL bash instead of a Windows executable, then test each server on its own. This matters because the default launch path failed for WSL workspaces in the thread.

  1. Check versionCompare your installed Continue version with the issue thread.
  2. Add bash wrapperSet command to bash, cwd to C:/Windows/System32/, and pass -lc with the WSL command.
  3. Check for errorsNote any cmd.exe, wsl.exe, or ENOENT errors and which server produced them.
  4. Test each serverConfirm each MCP server starts on its own.

Why it matters

A user on Continue 1.2.11 with Windows 11 and a WSL Ubuntu workspace saw every MCP server fail with Error: command "cmd.exe" not found, while the same config worked in a non-WSL Windows workspace. One user in the Continue issue thread (opens external site) got past it by launching the server through WSL bash. The thread only shows this for one PHP stdio server, so I would test each server separately.

Steps

  1. Check your installed Continue version against the thread. A release bot marked the bug resolved in @continuedev/config-yaml v1.40.0, but a later comment on Continue 1.2.17 still reported the same error.
  2. Open the config file you actually use and add a stdio server entry. The thread's working example sets command to bash, sets cwd to a Windows system folder, and passes -lc with the full WSL command as an argument:
yaml
name: Laravel Boost MCP
version: 0.0.1
schema: v1
mcpServers:
  - name: laravel-boost
    type: stdio
    cwd: "C:/Windows/System32/"
    command: "bash"
    args:
      - "-lc"
      - "php /home/projects/ai-artisan_test/artisan boost:mcp"
  1. Replace the sample command with the launch command for your own server, written with the Linux path inside WSL.
  2. Save the file and check whether Continue reports the server starting. If you still see cmd.exe, wsl.exe, or ENOENT errors, note the exact message and the server it came from. The thread does not say why those errors persist for some setups, so treat them as unresolved rather than as proof of a particular cause.
  3. Test each other server separately. The thread does not show npx or uvx commands working this way.
  4. If you use project-level files under .continue/mcpServers/, test them on their own. One user still got ENOENT errors on a vscode-remote://wsl+ubuntu/ path with that setup.
  5. Keep a copy of the working config so you can go back to it if behavior changes after an update.

Common mistakes

  • Assuming one working server means every MCP server works through the same wrapper.
  • Dropping the cwd or command lines. Without them, the thread reports errors that mention wsl.exe or cmd.exe paths.
  • Editing the WSL ~/.continue file without checking which config Continue loads. A separate thread reports that Continue on WSL can read the Windows-side C:\Users\<user>\.continue config instead.
  • Trusting a bug report marked resolved without checking the version you have installed.

Checklist

0 of 8 done

Sources

  1. Continue MCP servers in WSL fail with 'cmd.exe' not found - how to fix?
  2. Why does Continue.dev read Windows ~/.continue config when VS Code runs in WSL?
  3. How do I add hooks to VS Code agent mode (Claude Code-style lifecycle hooks)?
Was this guide useful?