Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@wsl-files find all .py files under ~/dev/proj"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
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.
Cowork on Windows can't attach a folder that lives in a WSL distro. Every way in fails:
A \\wsl.localhost\<distro>\... 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.
Scheduled tasks hit the same wall: the "New scheduled task" form rejects a WSL folder as "a protected location". The Code tab's WSL sessions would be the way around that, but as of 2026-10-17 (Desktop 2.42304.0.0) they fail to start with "Couldn't upload to the remote (server binary) ... [ENOENT]" (#101998).
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.
@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\<user>\dev\...).
If Anthropic ships WSL folders in Cowork, you won't need this.
Related MCP server: @modelcontextprotocol/server-wsl
Tool | What it does |
| Shows the folders it may use |
| Reads a text file with line numbers, in pages ( |
| Creates or replaces a file, creating parent folders |
| Replaces exact text: one match, or every match with |
| Lists a folder, up to 5 levels deep |
| Finds files by glob ( |
| Regex search through file contents |
| Copies any file, binary too, into one Windows staging folder so the client's own tools can open it |
| Copies a file from that staging folder back into WSL |
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.
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 <kind>].
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.
All of these name the same file:
~/dev/proj/README.md
/home/<user>/dev/proj/README.md
proj/README.md (relative to the first root)
\\wsl.localhost\<distro>\home\<user>\dev\proj\README.md (also \\wsl$\...)
W:\home\<user>\dev\proj\README.md (a drive letter mapped to the WSL root; set it with WSL_FILES_WSL_DRIVE)
C:\Users\<user>\dev\proj\README.md (a Windows junction to ~/dev)
cd ~/dev/cowork-wsl-files
uv venv && uv pip install -e ".[dev]"
git config core.hooksPath .githooks
.venv/bin/pytestIn %APPDATA%\Claude\claude_desktop_config.json, under mcpServers:
"wsl-files": {
"command": "wsl.exe",
"args": ["-d", "<distro>", "--", "/home/<user>/dev/cowork-wsl-files/scripts/run-server.sh"]
}Restart Claude Desktop afterwards.
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.
Variable | Default | Meaning |
|
| Allowed folders, separated by |
|
| Windows drive letter mapped to the WSL root |
|
| User in |
|
| Where |
| unset (copy tools off) | Windows folder for the copy tools; a Windows spelling works |
Copy a file you made in the Windows staging folder (binary too) to a path in WSL.
name: the file inside the staging folder (a name, a sub/path, or its full Windows path). path: where it goes in WSL (same rules as write_file).
Inputs: name (required), path (required). Returns: result
Copy any file (binary too: docx, pdf, png, .skill) from WSL into the Windows staging folder, where your own file tools can open it. Off unless the server has a staging folder set.
path: the file in WSL. name: file name (or sub/path) inside the staging folder; empty keeps the file's own name.
Inputs: path (required), name. Returns: result
Replace exact text in a file. old_string must appear exactly once unless replace_all is true.
path: the file to change. old_string: the exact text to find (copied from read_file output, without line numbers). new_string: the text to put in its place. replace_all: replace every occurrence instead of requiring a single one.
Inputs: path (required), new_string (required), old_string (required), replace_all. Returns: result
Find files by name with a glob such as '.md', 'NOW.md' or 'docs/**/.py'.
pattern: the glob, matched against the path relative to path (a pattern without / also matches bare file names).
path: the folder to look in; empty means the first root.
max_results: stop after this many.
Inputs: pattern (required), path, max_results. Returns: result
List a folder: subfolders first (ending in /), then files with their sizes.
path: the folder; empty means the first root (~/dev). depth: how many levels to show (1-5). .git, node_modules, .venv and caches are not entered.
Inputs: path, depth. Returns: result
The folders this server may read and write. Every other path is refused.
Inputs: no named parameters. Returns: result
Read a text file. Each line comes back as ''.
path: the file (~/dev/..., an absolute WSL path, a Windows spelling of one, or relative to the first root). offset: first line to return, counting from 1. limit: how many lines to return.
Inputs: path (required), limit, offset. Returns: result
Search file contents with a regular expression. Returns 'file:line: text' for each match.
pattern: a Python regular expression. path: a folder or a single file; empty means the first root. Narrow it: ~/dev is large. glob: only search files whose relative path matches this glob, e.g. '*.md'. ignore_case: match regardless of case. max_results: stop after this many matching lines.
Inputs: pattern (required), glob, path, ignore_case, +1 more. Returns: result
Create a file or replace it whole. Missing parent folders are created.
path: the file to write. content: the complete new contents.
Inputs: path (required), content (required). Returns: result
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Scored across 9 tools
Tools are clearly separated by action and resource: reading, writing, editing, listing, finding, searching, and Windows staging copies each have a distinct purpose. No two tools overlap ambiguously.
Most names follow a verb_noun pattern (read_file, write_file, list_dir, find_files) or verb_prep_noun (copy_to_windows). The lone 'search' is just a verb, a minor deviation from the otherwise consistent convention.
9 tools is well within the ideal 3–15 range for a file-access server. Each tool covers a distinct capability without redundancy.
Core read, write, edit, list, find, search, and cross-boundary copy operations are present. Delete and move/rename are missing, limiting full lifecycle coverage, but the main file workflows are supported.
Work on your own computers from Claude or ChatGPT: run commands, edit and search files.
Use your Mac, Windows or Linux computer from ChatGPT, Claude or Codex: files, commands, documents.
Connect ChatGPT, Claude, Cursor or VS Code to your Windows PC: files, terminal, browser, apps.
Safe folder access for ChatGPT and Claude: read, write and search files, risky tools opt-in.
