mcpField
M
Mac Shell MCP Server

Mac Shell MCP Server

Local
onvex.aiDeveloper Tools27Updated 4w ago

About Mac Shell MCP Server

Mac Shell MCP Server is an MCP server that lets an AI client run a fixed set of read-only ZSH commands on macOS, confined to directories the user designates. The agent cannot change its own policy, which is edited only through a config file. It suits users who want tight control over AI access to the command line.

Key features

  1. 01Fixed allowlist of read-only commands
  2. 02Execution confined to user-defined roots
  3. 03No shell interpretation of arguments
  4. 04Per-call authorization by effect and scope
  5. 05Append-only audit log of every request

Use cases

  1. 01Let an AI search code and logs inside a project
  2. 02Inspect files and count lines within set directories
  3. 03Require human approval for commands run outside configured roots

MCP support

This project is an MCP server that exposes policy-constrained command tools to MCP clients, including in-root execution, out-of-root execution requiring elicitation support, and pipelines.

Configuration

Local server config is the same for every client. Copy it into your client’s MCP config file.

No install method listed yet

We haven’t collected a package or remote endpoint for this server. Follow the instructions in the project README.

Repository

Tools

No tool list yet

Local servers expose tools only once running on your machine, and the maintainer has not provided a tool list.

Details

From the project README

Mac Shell MCP Server

CI Security Scans

An MCP server that lets an AI client run a small, fixed set of read-only shell commands, confined to directories you nominate.

It is built around one idea: the agent cannot widen its own authority. There is no tool that edits the policy, no approval queue the agent can drain, and no shell to interpret its arguments.

Upgrading from 1.x? 2.0.0 is a breaking change. Seven tools were removed and the authorization model was replaced. See Migrating from 1.x. 1.x contained two vulnerabilities reported by four independent researchers; see the security advisories.

What it does

ToolWhat it is for
execute_commandRun a permitted command inside your configured directories
execute_external_commandRun one outside them — requires a client that can ask a human
execute_pipelineChain read-only commands, stdout to stdin, without a shell
get_policyAsk what is permitted, rather than guessing and being refused
suggest_policy_configTurn observed usage into config you apply

Default commands

ls pwd echo cat head tail wc grep

Each is restricted to an allowlist of flags. None of them can write a file, execute another program, or read configuration from the environment.

find, git, rm and every interpreter are absent by default. You can add any of them, and should know why they are not there:

  • find -fprintf writes attacker-chosen content to an attacker-chosen path, while find is naturally classified read-only
  • git executes commands from a repository's own .git/config, and no environment variable disables that
  • interpreters (python, perl, awk, node, osascript, …) take inline code as an argument

Install

npm install -g @the_cfdude/mac-shell-mcp

Then create a policy:

mkdir -p ~/.mac-shell-mcp
cp .mac-shell-mcp.sample.json ~/.mac-shell-mcp/config.json
$EDITOR ~/.mac-shell-mcp/config.json    # set allowedRoots to your project
chmod 444 ~/.mac-shell-mcp/config.json  # defence in depth; see Security

Add to your MCP client:

{
  "mcpServers": {
    "mac-shell": { "command": "npx", "args": ["-y", "@the_cfdude/mac-shell-mcp"] }
  }
}

A fresh install with no roots configured refuses everything — deliberately. Each refusal names the permitted commands and where configuration lives, so the first failure tells you what to do.

Configuration

Policy is found in this order, first match wins, never merged:

  1. $MAC_SHELL_MCP_CONFIG — an explicit path
  2. ~/.mac-shell-mcp/config.json
  3. Host environment (MAC_SHELL_ROOTS, MAC_SHELL_COMMANDS)
  4. Built-in defaults

Policy is never read from the working directory. A cloned repository must not be able to supply the policy governing the agent that opens it.

{
  "allowedRoots": ["/Users/you/Projects/my-project"],
  "programDirectories": ["/usr/bin", "/bin", "/usr/sbin", "/sbin"],
  "commands": {
    "grep": {
      "program": "/usr/bin/grep",
      "effect": "read",
      "allowedArgs": ["-i", "-n", "-r", "-l", "-E", "-F"],
      "permission": "allow",
    },
  },
}

permission is allow, ask, or deny. ask requires a client offering MCP elicitation — the only capability that means a human can be asked. Where it is absent, ask becomes deny, never allow.

How it decides

Authorization is effect × scope, computed per call. grep inside your project is free; the same grep against ~/.aws is not. The command name alone never decides.

  • No shell. execFile is never given a shell option, so arguments reach the OS uninterpreted. Nothing evaluates ;, $(), or backticks — which is also why filenames with spaces, parentheses and brackets work normally.
  • The program is authorized, not just the arguments. Commands resolve to an absolute path from your program directories, are matched by that resolved path rather than by basename, and are refused if they resolve inside one of your roots. Roots hold data, never code.
  • The environment is constructed, not inherited, so a variable like RIPGREP_CONFIG_PATH cannot smuggle in a helper program that never appears in the argument list.
  • Allowlists, never denylists. A denylist is a list of the flags somebody thought of.
  • Scope includes the working directory, so a command with no path argument is judged by where it runs rather than passing because it named nothing.

Security

The policy file, its parent directories, your program directories, and the whole audit log directory are protected locations. The default command set contains nothing that writes, so none of them is reachable out of the box. If you add a command that writes (cp, mv, rm, tee, ln, chmod, and a few others, by name), the server refuses any call whose path arguments land on a protected location, matched by filesystem identity as well as by path. That check is keyed on the command's name, not on what an arbitrary program might do: a writing command outside that list is not covered, so add one only if you trust what it can write.

chmod 444 on your config is worth doing as a second, independent layer. It is not the mechanism: replacing a file needs write permission on its directory, not the file.

Every request, permitted or refused, is recorded to an append-only audit log.

Known limits, stated rather than implied — see SECURITY.md:

  • Path detection is heuristic, and fails closed
  • Everything inside a root is freely readable by one recursive search
  • ask is only as strong as the host's approval prompt
  • Flag meanings vary between implementations of the same command name

Report vulnerabilities via private advisory or [email protected].

Migrating from 1.x

Removed: add_to_whitelist, update_security_level, remove_from_whitelist, approve_command, deny_command, get_pending_commands, get_whitelist.

The first three let any client promote a forbidden command to safe. The next three formed an approval workflow the requesting agent could drain by itself. get_whitelist is replaced by get_policy.

Runtime whitelist edits become a config file you edit and the server reads at startup. rm was FORBIDDEN in 1.x and remains unavailable, so nothing that worked before stops working.

Development

npm install && npm run build
npm test          # run it twice; a suite that only passes once is not passing
npm run lint && npm run format:check

Design and specifications: openspec/changes/mac-shell-mcp-2-security-redesign/.

License

MIT — see LICENSE.

Comments

Markdown supported

New to MCP?

From what the protocol is to installing your first server, these answers cover most first questions.

An open protocol that defines how AI applications connect to external tools and data in a uniform way. Clients talk to the model; MCP servers provide tools, resources and prompt templates. They exchange standard messages, so one server can be reused by many clients.