MCP Gives Your Coding Agent Root on Your Laptop

Install an MCP server locally and every tool call it executes runs as you — your OS user, your file permissions, your SSH keys sitting in ~/.ssh, your cloud CLI credentials cached in your home directory. That's not a flaw in a specific server. It's what "local MCP server" means by default.

The trust model nobody explicitly agreed to

When you add an MCP server to Claude Desktop, Claude Code, Codex, or Cursor's config, you're not sandboxing anything by default — you're handing a local process the same permissions your terminal already has. A bash-capable MCP server that can run shell commands can run anyshell command your user account can run. That's the correct, expected behavior of a local process — the issue is that most people reasoning about "is this MCP server safe" are evaluating the server's code quality, not the blast radius of the permission model it's handed by default.

What actually changes the model, versus what just feels safer

A confirmation prompt before every tool call feels safer and helps against obviously-bad single actions, but it doesn't change the underlying permission boundary — an approved command still runs with your full user permissions. What actually changes the boundary is moving execution somewhere that was never handed your machine's permissions to begin with.

boxkite-mcp is still a local process — it speaks MCP over stdio to your editor like any other server. The difference is what it does with a tool call: instead of running execagainst your own shell, it makes an HTTP request to a control-plane, which runs the command inside a Kubernetes pod that was never going to have a route to your laptop's filesystem, SSH keys, or credentials in the first place — self-hosted on your own cluster, or the free hosted beta.

{
  "mcpServers": {
    "boxkite": {
      "command": "boxkite-mcp",
      "env": {
        "BOXKITE_BASE_URL": "https://your-control-plane.example.com",
        "BOXKITE_API_KEY": "bxk_live_..."
      }
    }
  }
}

The honest tradeoff

This isn't free. A tool call now costs a network round-trip instead of a local syscall, and the agent loses direct access to files that are genuinely supposed to be local (your actual working directory, unless you explicitly sync it in). For a coding agent whose job is exploring and modifying an actual local checkout, that's a real workflow change, not a pure win. The trade is worth making specifically when the agent is running code you don't fully trust yet — generated snippets, dependencies it just installed, anything from an untrusted source — not for every single tool call an agent ever makes.