# How do you sandbox the Filesystem MCP server?

Source: https://forum.codelifter.com/posts/how-do-you-sandbox-the-filesystem-mcp-server/
Site: CodeLifter Forum, category MCP and tools
Published: 2026-10-16. Updated: 2026-10-16. Replies: 0.

## Question by CodeLifter editors (staff), 2026-10-16

Give it one project folder and nothing more. Pass that folder as the only allowed directory, or run the Docker image with the folder bind-mounted under /projects, read-only where reads are enough, and with networking switched off. Keep secrets out of that folder, and confirm what the server can see before you let an assistant write.

## What the server can reach by default

The reference Filesystem server restricts every operation to its allowed directories. Its [README](https://github.com/modelcontextprotocol/servers/tree/main/src/filesystem) says "All filesystem operations are restricted to allowed directories" and that the server "requires at least ONE allowed directory to operate." Inside those directories it can read any file, write new files, overwrite existing ones with `write_file`, edit with `edit_file`, and move or rename with `move_file`, which the README's annotation table marks as destructive ("Deletes source file"). The README documents no undo or trash.

There are two ways the allowed list gets set, and the difference matters for sandboxing:

1. **Command-line arguments.** The paths after the package name in your config.
2. **MCP Roots.** If your client supports Roots, the README says roots sent by the client "completely replace any server-side Allowed directories". The README recommends this method because the list can change at runtime without a restart.

So if your client sends roots, the folders you typed in the config are not the ones in force. Check which applies before you rely on either.

## Step 1: narrow the allowed directories

Point the server at the project you are working on, not your home folder or Desktop. With npx, the config in `claude_desktop_config.json` (or your client's equivalent) looks like this:

```json
{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/you/code/my-app"]
    }
  }
}
```

In VS Code, the README's example uses `${workspaceFolder}` as the path, which limits the server to the open workspace. On Windows the README says to launch npx through `cmd /c`, so the command becomes `cmd` and the arguments start with `"/c", "npx"`.

## Step 2: run it in a container with read-only mounts

The npx route runs the server as you, with your user's file permissions. A container adds a second boundary: the server can only see what you mount. The README's Docker example mounts host folders under `/projects` and notes that "Adding the `ro` flag will make the directory readonly by the server." Docker's own [bind mount documentation](https://docs.docker.com/engine/storage/bind-mounts/) says bind mounts "have write access to files on the host by default" and that you can use the `readonly` or `ro` option to prevent writes.

```json
{
  "mcpServers": {
    "filesystem": {
      "command": "docker",
      "args": [
        "run", "-i", "--rm", "--network", "none",
        "--mount", "type=bind,src=/Users/you/code/my-app,dst=/projects/my-app",
        "--mount", "type=bind,src=/Users/you/code/shared-docs,dst=/projects/docs,ro",
        "mcp/filesystem",
        "/projects"
      ]
    }
  }
}
```

The `--network none` flag is our addition, not part of the README's example. Docker's [none network driver page](https://docs.docker.com/engine/network/drivers/none/) says it will "completely isolate the networking stack of a container" so that "only the loopback device is created." The README states that every tool sets `openWorldHint: false` and that the server "only accesses the local filesystem," and stdio needs no network, so the flag should not change how it works. Test it with your client before you depend on it.

## Step 3: keep secrets out of the allowed folders

The server's `read_text_file` tool "Always treats the file as UTF-8 text regardless of extension", so an `.env` file, an SSH key or a cloud credentials file inside an allowed folder can be read like any other file. Before you start:

1. Move secrets out of the project folder, or mount only the subfolders the assistant needs (for example `src/` and `docs/`, not the repository root).
2. Do not allow your home directory. It usually contains `~/.ssh`, shell history and tool configs.
3. If a token has to sit in the project, assume the assistant can read it, and scope that token tightly. The thread on [GitHub MCP token scopes](/posts/which-token-scopes-does-the-github-mcp-server-need/) covers that for GitHub.

## Step 4: keep a human on the write tools

Sandboxing limits where damage can happen. It does not stop damage inside the folder. Turn on your client's per-call approval for `write_file`, `edit_file` and `move_file`. The README advises using `edit_file` with `dryRun` first, which returns a diff without applying it. The [MCP tools specification](https://modelcontextprotocol.io/specification/latest/server/tools) also says clients "MUST consider tool annotations to be untrusted unless they come from trusted servers", so treat a read-only hint as a label, not a lock. A read-only mount is the lock. Commit your work to git before a session so a bad overwrite can be reverted.

## Which control limits what

| Control | Limits | Does not limit |
| --- | --- | --- |
| One allowed directory (args) | Paths the server will touch | Anything inside that folder; replaced if the client sends Roots |
| Roots from the client | Paths, and they can change at runtime | Same as above; you rely on the client's choice of roots |
| Docker bind mounts | What the process can see at all | Writes to mounts without `ro` |
| `ro` on a mount | Writes to that folder | Reads, including secrets in it |
| `--network none` | Network access from the container | File access inside the mounts |
| Client approval prompts | Which calls run | Calls you approve without reading |

## Check the sandbox before you work

1. Ask the assistant to call `list_allowed_directories` and read the result yourself. With Docker it should show only paths under `/projects`.
2. Ask it to read a file outside those paths. The call should fail.
3. Ask it to create a file in a folder you mounted with `ro`. The call should fail.
4. Repeat after any client update, because Roots behaviour depends on the client.

The CodeLifter page on the [Filesystem MCP server](https://codelifter.com/mcp/filesystem/) lists every tool and its annotation. If you are choosing between local and hosted servers more generally, see [remote or local GitHub MCP server](/posts/remote-or-local-github-mcp-server-which-should-you-run/), which walks through the same trade-off for GitHub.

---
Cite as: CodeLifter Forum, "How do you sandbox the Filesystem MCP server?", https://forum.codelifter.com/posts/how-do-you-sandbox-the-filesystem-mcp-server/, accessed 2026-10-16.