Claude Desktop Commander: Tools, Permissions, and Shared Context

Desktop Commander is an open-source MCP server that gives Claude Desktop access to your file system and the ability to run terminal commands. With it connected, Claude can read and write files, run scripts, and execute shell commands — all from a conversation. That makes it a powerful tool for developers, but it also makes the permission decisions more important than with a read-only connection.

Tools like fenbs complement Desktop Commander by keeping the approved instructions and the decisions behind changes in a shared record. When the next session starts, Claude reads what was decided rather than guessing.

What Desktop Commander does

Desktop Commander implements MCP tools for file operations (read, write, list, search, move) and terminal execution (run a command in a shell, see the output). When you install it and add it to the Claude Desktop config, Claude can see those tools and call them during a conversation.

Common uses include asking Claude to read a file and explain it, refactor code across several files, run tests and interpret the output, or set up a project structure. Each of these involves Claude deciding which file operations or commands to run — you give the goal, Claude uses the tools to pursue it.

Assessing the permissions

Desktop Commander's tools have access to whatever the process running them has access to on your machine. That is typically your full home directory and the ability to run commands as your user. Before connecting it to Claude Desktop, consider:

• Which directories should Claude be able to read? If the answer is "everything I have access to", that includes credentials files, SSH keys, and other sensitive content.
• Which directories should Claude be able to write? A write to the wrong place can overwrite files that are not version-controlled.
• Which commands should Claude be allowed to run? Terminal execution includes any command your user can run, including ones that delete files or modify system state.
• Is there a way to restrict the scope? Some versions of Desktop Commander support configuration to limit the allowed paths or block certain commands. Check the current documentation.

The safest starting point is to use Desktop Commander in a project directory that is under version control. That way, any file change Claude makes can be reviewed and reverted. Avoid connecting it to directories containing credentials, secrets, or config files you cannot easily restore.

Reviewing before Claude acts

Claude Desktop shows you the tool calls Claude is about to make before executing them. For file writes and terminal commands, Claude Desktop will ask for confirmation by default for potentially risky actions. Do not disable that confirmation step — it is your opportunity to check what will change before it happens.

For a sequence of related operations, ask Claude to describe the plan before starting rather than running each step immediately. A written plan is easier to review than a sequence of rapid tool calls. If any step looks wrong, stop and correct the instruction before it runs.

If something unexpected happens, the Claude Desktop MCP not working guide covers troubleshooting connection and permission issues.

Installing Desktop Commander

Desktop Commander is an open-source project available on GitHub. Install it using npm or another package manager, then add an entry to your Claude Desktop MCP config file pointing to the installed server. The project's README has current installation steps — check it directly rather than relying on a guide that may be out of date, as the setup can change between versions.

The Claude Desktop app guide explains the broader Claude Desktop setup. The Claude Desktop MCP config guide covers how to add MCP servers in the config file.

Keeping a record of what changed

Desktop Commander can make a lot of changes quickly. Without a record, it is hard to answer "why was this file changed?" in a later session. Version control handles the what — you can see the diff — but not always the why: the decision that prompted the change, the context behind it, or whether it was intentional. Before you start a session that involves significant changes, write the plan in a task in fenbs. The changes and the reason behind them are then in the same place.

fenbs History records every change with who made it. Combined with good Decisions and rules, you can trace a file change back to the decision that justified it. That is more useful than a git log message when the reason matters.

How to do this with fenbs

1. Create a free account and add the project you are working on.
2. Write the rules for Claude's file and terminal access in Decisions and rules: allowed directories, commands that need confirmation, and any standing constraints.
3. Connect Claude Desktop to fenbs from Integrations. Claude reads the rules at the start of every session.
4. Add Desktop Commander to the Claude Desktop config following the project's README. Keep both connections active — fenbs for context, Desktop Commander for file and terminal access.
5. At the end of each session, ask Claude to save progress in fenbs: what was changed, what was checked, and what remains. The next session starts from the current state rather than guessing.