The filesystem MCP server gives agents file access. How does it stop them from reading everything on disk?

Flashcard·Easy·4.0 · 0·~30s·Asked atDeepseek Dify Reliance Jio·Relevant atAnthropic

Attempt it

It restricts access through a directory allowlist passed on the command line at launch (e.g., npx @modelcontextprotocol/server-filesystem /Users/me/Projects). Every file operation's path is resolved and checked against those allowed roots; anything outside is rejected. This check lives in the server's own code. The MCP protocol provides no isolation, and the server runs as the user's OS account, so the allowlist is the entire sandbox.

Your answer

The **filesystem MCP server** (`@modelcontextprotocol/server-filesystem`) stops agents from reading everything on disk through a directory allowlist you set at launch time. When you start the server, you pass one or more directories as command-line arguments: ``` npx @modelcontextprotocol/server-filesystem /Users/me/Projects /Users/me/Documents ``` Every tool call the model makes (read_file, write_file, edit_file, list_directory, search_files) goes through a path check inside the server. The server resolves the requested path (handling `..`, symlinks, and casing) and verifies it falls inside one of the allowed roots. If not, the operation is rejected with an error. The critical point is where the boundary lives. The MCP protocol itself carries no filesystem semantics and provides no isolation. The host (Claude Desktop, Cursor) launches the server but does not constrain its IO. The only thing standing between the agent and the rest of your disk is the server's own JavaScript path check plus the directories you chose. The server runs as your OS user with your file permissions. This means two things in practice: pick narrow roots, and never pass `/` or `~/` as an allowed directory unless you genuinely trust the agent with everything you own.

The **filesystem MCP server** uses a directory allowlist as its sole sandboxing mechanism. The allowlist is declared on the command line at launch: `npx @modelcontextprotocol/server-filesystem /Users/me/Projects`. Every incoming tool call's path argument is resolved (following symlinks, normalizing `..` and casing) and checked against the allowed roots before any IO happens. Operations outside the roots are rejected. The server exposes tools like `read_file`, `write_file`, `edit_file` (cheaper than full rewrites for partial edits), `list_directory`, `search_files` (recursive filename matching), `move_file`, `create_directory`, and `get_file_info`. All of them are subject to the same path check. The protocol provides no sandboxing. MCP is a JSON-RPC protocol for tool calls and responses; it carries no filesystem semantics and no isolation primitives. The host launches the server as a subprocess but does not constrain its IO. The server inherits the OS user's file permissions. Pass `/` as the root and the server can read and write anything you can. For personal use (Claude Desktop on a laptop), narrow roots and your OS user model are sufficient. For shared or production deployments, the standard hardening pattern is to run the server in a container with bind-mounted directories so the kernel enforces the boundary even if the server has a bug, and to require human confirmation for write tool calls.

TL;DR

The filesystem server restricts access via a directory allowlist on the command line; every path is resolved and checked against those roots, and the MCP protocol itself provides no isolation.

Memory aid

Easy to grasp

Imagine giving a helper access to a few specific drawers in a filing cabinet, but nothing else. When you start the filesystem MCP server, you hand it a list of folders it is allowed to touch. The server can read files, write files, list folders, and search, but only inside those approved folders. If the helper asks for something from a drawer you did not approve, the server says no. The important part is that only the server enforces this rule. The MCP protocol itself does not know anything about files or folders. And the server runs as you, using your permissions. If you accidentally said 'every drawer in the building is fine,' the helper could go anywhere you could go. So you keep the list narrow.

Key concepts

Filesystem MCP server Sandboxing Directory allowlist

Concept explanation~2 min read

Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.

The filesystem MCP server is the first server most people install when they connect MCP to Claude Desktop or Cursor. It is also the clearest illustration of where MCP's security boundaries do and do not live, because the answer to 'how does it stop agents from reading everything?' exposes the full trust model.

This deep dive covers the allowlist mechanism, the tool surface, why the MCP protocol itself provides no isolation, the symlink resolution subtlety, and the patterns for hardening a deployment beyond the default.

The directory allowlist: the entire sandbox

The sandboxing model is a path check inside the server's own code, and nothing else.

At launch, the server takes one or more directories as command-line arguments: npx @modelcontextprotocol/server-filesystem /path/one /path/two. These are the allowed roots. Inside the server, every incoming tool call's path argument is resolved. Resolution means turning .. into actual parent traversal, following symlinks to their real targets, and normalizing casing on case-insensitive platforms. The resolved path is then checked against each allowed root. If it falls inside one of the roots, the operation proceeds. If not, the server returns a structured error.

A few subtleties matter. Symlink escapes are blocked because the check uses the resolved path, not the symbolic source. A symlink inside the allowed directory that points to /etc/passwd is rejected because /etc/passwd is outside the roots. Relative paths are joined to the server's working directory before resolution. Empty paths or null bytes are rejected at the input layer.

There is no per-tool ACL. If a directory is in the allowlist, every tool (read, write, edit, delete, move) can act on every file inside it. Finer-grained restrictions require writing a custom server.

The tool surface

Why the protocol provides no isolation

Why the allowlist lives on the command line

Hardening beyond the default

Situations where this technique stops working.

2–4 min · Everything important, quickly.

Real products, models, and research that use this idea.

Claude Desktop users scope a filesystem server entry to `~/Documents/notes` so the agent can read and edit notes without touching anything else on disk.
Cursor users add a filesystem server scoped to a single project directory in `.cursor/mcp.json`, giving the agent file access beyond the editor's built-in tools.

What an interviewer would ask next. Try answering before peeking at the approach.

QHow does the filesystem server prevent symlink escapes?

Every path argument is resolved (following symlinks to their real targets) before the allowlist check. A symlink pointing outside the allowed roots is rejected based on the resolved target, not the symbolic source.

2 more follow-ups an interviewer would ask next. Sign in to reveal them.

Red flags & common mistakes

The phrases that signal junior thinking. Click to expand.

Most common mistake

Assuming the MCP protocol provides built-in sandboxing. It does not. The filesystem server's own path check plus the directories you allow on launch are the entire boundary.

60 second bullets to scan on the way to the call.

Name the package and repository where the filesystem server lives.
List the headline tools the server exposes (read, write, edit, list, search).

Primary sources. Browse if you want the original framing.