A popular quick-install list for MCP servers ends with a one-line warning: the filesystem server "can read your entire disk if you configure it that way" (source). Then the post moves on. That leaves the real question: how do you give Claude Desktop access to one project and nothing else, and how do you know the limit holds?
This guide covers that single task. You will add the filesystem server with one allowed folder, run two test prompts, and learn what to check when something breaks.
Status of the code below: every config snippet, prompt and expected result in this article is unexecuted. None of it has been run against a specific Node.js or Claude Desktop build, so no versions are claimed. Record your own in step 1, and treat the expected outputs as targets, not guarantees.
What you need before you start
You need Claude Desktop, Node.js with npx on your path, and a project folder you are comfortable exposing. The dev.to post names the package @modelcontextprotocol/server-filesystem and says it lets Claude read project files instead of you pasting code. It gives no Node.js requirement, so check the official MCP server documentation for the current one.
The post also starts with mcp-hub install @modelcontextprotocol/server-filesystem. It never explains what mcp-hub does beyond calling it a CLI for discovering servers, and it still tells you to edit claude_desktop_config.json by hand afterward. My inference is that the config entry is the part that matters. The standard documented approach uses npx inside that file, so mcp-hub is not a prerequisite. Skip it unless you have verified it yourself.
Step-by-step setup
-
Record your versions. Run
node --versionandnpx --versionin a terminal, and note the version on Claude Desktop's About screen. If something fails later, these are the first facts anyone will ask for. -
Choose one folder and note its absolute path. Pick the project root, not your home directory and not a drive root. Use a full path such as
/Users/you/projects/my-appon macOS or Linux. Commit or back up the project first, because the server may expose write operations as well as reads. Confirm the tool list in the official documentation before assuming it is read-only. -
Open the config file. Claude Desktop's settings have a developer section with an option to edit the config. To open the file directly, the commonly documented locations are
~/Library/Application Support/Claude/claude_desktop_config.jsonon macOS and%APPDATA%\Claude\claude_desktop_config.jsonon Windows. Verify both against the official documentation, since paths can change between releases. -
Add the server with one allowed directory. The path goes at the end of the
argsarray. That path is the entire access boundary. -
Save, fully quit Claude Desktop, and reopen it. Closing the window is not enough on many setups. The app reads the config at launch, so a half-closed app keeps the old settings.
-
Look for the server in the app. After the restart, Claude Desktop should show the filesystem server's tools in the chat interface. If nothing appears, jump to the failure table below.
The minimal config (unexecuted)
Check the package name and command against the official MCP documentation before saving this. If your file already has other servers, add the filesystem entry inside the existing mcpServers object instead of replacing the file.
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-filesystem",
"/Users/you/projects/my-app"
]
}
}
}
On Windows, JSON needs escaped backslashes, so the last argument becomes "C:\\Users\\you\\projects\\my-app". A single backslash breaks the file or produces a wrong path. This pairs well with go http server graceful shutdown: fix the common bugs.
The -y flag tells npx to install the package without prompting. That is convenient, but it also means npx downloads and runs code from npm on your machine. Look up the package on npm and confirm the publisher before the first run.
Environment recorded for this example: Node.js version not checked, Claude Desktop version not checked, config not executed.
Prove the limit works
A working server proves little. You need to watch it refuse. First, create two harmless marker files.
Inside the allowed folder, create canary-inside.txt containing the single line inside-ok. Outside it, for example in your home directory, create canary-outside.txt containing outside-should-be-blocked.
Start a new chat and send these prompts one at a time, using your real paths.
Prompt A, inside the folder:
Read /Users/you/projects/my-app/canary-inside.txt and tell me exactly what it contains.
Expected result (unexecuted): Claude asks permission to use a filesystem tool, you approve, and it reports inside-ok.
Prompt B, outside the folder:
Read /Users/you/canary-outside.txt and tell me exactly what it contains.
Expected result (unexecuted): the tool call returns an error saying the path is outside the allowed directories, and Claude reports that it cannot read the file. It should never print outside-should-be-blocked.
If Prompt B succeeds, stop. Either your allowed path is broader than intended, or a second config entry grants more access. Fix the path before doing any real work.
Two more probes take about a minute. Ask Claude to list your home directory, and ask it to read a path that climbs out of the project with ../. Both should be refused. The dev.to post does not say whether symlinks inside the project can point outside it, so check the official documentation before linking anything sensitive into the folder.
Fixing common failures
The dev.to post offers no troubleshooting, so this table is based on how the setup works. Treat the causes as likely, not certain.
| Symptom | Likely cause | Fix |
|---|---|---|
| No filesystem tools appear after restart | Invalid JSON, such as a trailing comma, missing quote or unescaped backslash | Paste the file into a JSON validator, correct it, then fully quit and reopen the app |
| Config edits have no effect | Wrong file location, or an edited copy that Claude Desktop does not read | Open the file through the app's own settings and compare the path with the official documentation |
| Server fails to start and mentions npx not found | Node.js is missing or not on the PATH that desktop apps see | Install Node.js, run node --version in a terminal, then restart the app. On some systems, using the full path to npx as the command helps |
| Changes seem ignored | You closed the app without quitting, so it kept the old config | Quit from the menu or system tray, then relaunch |
| Prompt A fails with a "not allowed" error | The allowed path is misspelled, relative, or points to a folder that does not exist | Use an absolute path, confirm it exists, and match the case exactly |
| Prompt B succeeds | The path is too broad, such as /, a drive root, or your whole home directory | Replace it with the single project root and rerun both prompts |
| Windows path errors | Single backslashes in JSON | Double every backslash, or follow the documentation's recommended path format |
When a server fails, the app's log files usually show the real error. The documentation lists where the logs live. The first line of a failed npx launch is often the most useful.
Also read: a closer look at migrate vpc peering to transit gateway: when it pays off
Keep the scope narrow over time
The dev.to post's example prompt is a good model: "Read the auth module and explain how the token validation works." That prompt needs one project, not a disk.
If you work on several repos, resist the urge to allow a parent directory such as ~/projects. Every sibling folder inside it becomes readable, including old ones holding .env files. Adding a separate entry per project, or editing one path when you switch, takes seconds and keeps the boundary meaningful.
Keep secrets out of the allowed folder where you can. A .env file inside the project sits inside the boundary, and Claude can read it if asked.
What to expect next
Once Prompts A and B behave as expected, daily use is mostly approving tool calls and asking questions about your code. Revisit the config whenever you change projects or update Claude Desktop, and rerun the two canary prompts after each change.
The dev.to post also mentions GitHub and PostgreSQL servers. Each adds its own credentials and risks, so give each its own scoping check before you connect it.
