Claude Desktop and WSL: Connect Tools Across Windows and Linux

Claude Desktop runs as a Windows application. WSL (Windows Subsystem for Linux) runs a Linux environment alongside it. Connecting a tool from inside WSL to the Windows Claude Desktop client is possible, but the two environments use different paths and process spaces, which creates specific things to get right.

Tools like fenbs keep project context and setup decisions available across both environments, so the configuration choices you make are recorded and any assistant you connect can read them.

The environment boundary between Windows and WSL

Claude Desktop's MCP config file lives at %APPDATA%\Claude\claude_desktop_config.json on Windows. The server commands in that file are executed as Windows processes. If your MCP server is a Node.js or Python script inside WSL, you need to call it through the wsl binary, which bridges the two environments.

WSL 2 and WSL 1 behave differently. WSL 2 runs a full Linux kernel in a lightweight virtual machine, which means it has its own IP address. WSL 1 shares the Windows networking stack more directly. For most MCP stdio connections, the transport difference does not matter, but if your server makes outbound network calls, verify it can reach its endpoints from the WSL 2 environment.

A command entry like "command": "wsl" with "-e", "node", "/home/user/my-server.js" as arguments tells Claude Desktop to launch the WSL process. The server then runs in the Linux environment while communicating back to the Windows client over stdio.

Path differences to watch for

Windows paths and WSL Linux paths are not interchangeable. The MCP server command in the Windows config must use the path the wsl binary understands. Scripts inside WSL use Linux paths; Windows drives are mounted at /mnt/c/ inside WSL by default.

If your server reads files from both environments, decide which side owns each file. Keeping project source code in the WSL filesystem avoids case-sensitivity issues and path translation. Keeping config files that Claude Desktop also reads in the Windows filesystem avoids having to cross the boundary twice.

Test the path resolution early. A server that starts correctly but cannot find its data files at runtime fails silently from the desktop client's perspective. Check the server's startup logs in a WSL terminal before connecting it to Claude Desktop.

MCP config for a WSL-hosted server

Here is the general shape of a config entry that launches a Node.js MCP server inside WSL:

{
  "mcpServers": {
    "my-wsl-server": {
      "command": "wsl",
      "args": ["-e", "node", "/home/youruser/mcp-servers/my-server.js"]
    }
  }
}

Adjust the path to match your WSL home directory and the Node.js binary location in your distribution. If you use Python, replace node with python3 and update the script path. The MCP config guide explains the full JSON structure.

If the server does not appear in Claude Desktop after a restart, open a WSL terminal and run the server command manually. Any startup error will appear there directly. The MCP not working guide covers connection errors once you confirm the server itself starts.

Testing the connection before you rely on it

Before connecting the WSL server to your main work, run a simple test. Add a minimal tool to the server, restart Claude Desktop and ask the assistant to call that tool. If the call succeeds, the path and process boundary are working correctly.

Then test a realistic operation: reading a file, calling an API, running a command your actual work needs. Catching a permission error or a missing dependency at this stage is much easier than debugging it mid-session with real work at stake.

Decisions worth recording

Several choices in a WSL setup are easy to forget between sessions. Which WSL distribution are you using? Which version of Node.js or Python is active inside it? Do you use a distro-specific path or a mounted Windows path for the server scripts? Does the WSL 2 virtual machine need any port forwarding for your server?

Recording these as decisions rather than comments in the config file means they are available to anyone working on the project, not just whoever set up that machine. It also makes it straightforward to reproduce the setup on another Windows machine running WSL.

It is also worth noting whether your WSL setup uses the default /mnt/c/ mount point or a custom configuration. If your team uses a custom wsl.conf with a different drive mount root, scripts and configs that assume the standard path will break for anyone who set their machine up differently.

How to do this with fenbs

1. Create a free account and add your project in fenbs.
2. Connect Claude Desktop from Integrations. Follow the Windows setup guide.
3. Set up your WSL-hosted MCP server. Test it in a WSL terminal before adding it to the Claude Desktop config.
4. Add the WSL server entry to the config file using the wsl command pattern above. Restart Claude Desktop and verify the connection.
5. Record the WSL distribution, the Node.js or Python version, the chosen paths and any non-obvious choices as Decisions in fenbs. Link them to the project so any future session can find them.

fenbs does not manage WSL distributions or Windows configuration. It keeps the project context and decisions that the setup depends on.