wsl-files

A small local MCP server that lets Claude Desktop’s Cowork, on Windows, read and write your files inside WSL.

It runs inside WSL over stdio, and Claude Desktop starts it with wsl.exe.

Why this exists

Cowork on Windows can’t attach a folder that lives in a WSL distro. Every way in fails:

• A \\wsl.localhost\\... subfolder is rejected up front: “Network (UNC) paths are not supported here.”
• The \\wsl.localhost folder itself, a mapped drive (net use), a subst drive, or a symlink in your Windows home folder: the picker accepts them, then the message fails with “Some folders couldn’t be added.”

That leaves WSL developers without Cowork for any of their code. Microsoft’s own advice is to keep projects on the Linux filesystem for speed (WSL docs).

The feature request is anthropics/claude-code#99303. It re-files #61003, which a bot closed as stale with no maintainer response. Claude Desktop’s Code tab does handle WSL folders; Cowork doesn’t.

Cowork can still use local MCP servers through Claude Desktop, and an MCP server can run inside WSL. This one does the file work there and hands Cowork the results.

Why not the official filesystem server

@modelcontextprotocol/server-filesystem works, but two things made it a poor fit here:

• No server-side deny list. Anything under an allowed folder is readable, .env files included; its excludePatterns is a per-call option for searches, chosen by the client. This server refuses secrets files outright and redacts key-shaped strings.
• The client can replace its folders. Per its README, roots sent by the client “completely replace any server-side Allowed directories”. Here the folders are fixed on the server side, whatever the client sends.

This one also accepts the Windows spellings Cowork tends to send (\\wsl.localhost\..., W:\..., C:\Users\\dev\...).

If Anthropic ships WSL folders in Cowork, you won’t need this.

What it can do

There is no delete and no move, on purpose. Text tools can’t handle binary files (docx, pdf, images); the two copy tools move those through the staging folder, and they’re off unless WSL_FILES_STAGING is set.

What it refuses

• Anything outside the roots. The default root is ~/dev. A symlink that points outside is refused too, and paths are checked after resolving symlinks.
• Secrets files (.env, token.json, *.creds.json, SSH keys, cookies and similar). It won’t read, write, or search them. The patterns are a copy of a Claude Code guard hook’s, so both refuse the same files.
• Key-shaped strings in output (API keys, tokens, private keys) come back as [redacted ].
• Writes inside .git.
• Edits to non-UTF-8 files, and binary files for any reading.

Every write and edit is logged as one JSON line in ~/.local/state/wsl-files/changes.log.

Paths it understands

All of these name the same file:

• ~/dev/proj/README.md
• /home//dev/proj/README.md
• proj/README.md (relative to the first root)
• \\wsl.localhost\\home\\dev\proj\README.md (also \\wsl$\...)
• W:\home\\dev\proj\README.md (a drive letter mapped to the WSL root; set it with WSL_FILES_WSL_DRIVE)
• C:\Users\\dev\proj\README.md (a Windows junction to ~/dev)

Setup

cd ~/dev/cowork-wsl-files
uv venv && uv pip install -e ".[dev]"
git config core.hooksPath .githooks
.venv/bin/pytest

In %APPDATA%\Claude\claude_desktop_config.json, under mcpServers:

"wsl-files": {
  "command": "wsl.exe",
  "args": ["-d", "", "--", "/home//dev/cowork-wsl-files/scripts/run-server.sh"]
}

Restart Claude Desktop afterwards.

Settings

Put them in config.local in the repo folder (copy config.example). scripts/run-server.sh reads it. Environment variables set in the Claude Desktop config don’t work here: they stay on the Windows side and wsl.exe doesn’t pass them in.