Skip to main content

Agents run on the host with full trust, by explicit choice

Agent runtimes run as ordinary processes on the server's host, as the server's user, and nobody watches a run to answer its permission requests. Runs therefore approve every request. An agent can do anything that user can, including running any command; its worktree is where it works, not a sandbox. Every request and its answer is recorded on the run.

Considered Options​

  • An operator-chosen policy (MC_RUN_PERMISSIONS=approve or reject): what we had. Dropped; rejecting stops nearly every useful run, so the choice was approve in practice, and runs refused to start until someone found the variable. Finer control, per role, project or runtime, is to come as its own policy.
  • Rules that approve some actions and reject others: rejected for now; shell commands cannot be judged reliably from their text, so such rules would suggest a safety they do not give.
  • Asking a person for each request: rejected; nearly every step of a run would wait for one.
  • Isolating each agent (a container or a dedicated user that only sees its worktree): the right end state, and the only one under which approving everything is safe; deferred as its own work. The intended route is an ACP bridge: a runtime whose command relays ACP to an agent started in a sandbox (Docker, Kubernetes), with the worktree mounted and Mission Control reached at MC_PUBLIC_URL. Runs only ever spawn a runtime's command and speak ACP on its stdio, so this is one more runtime kind and needs no change to how runs work.

Consequences​

  • Only the server decides what may run: organizations set up agent runtimes, but each is one of the kinds built into the server, and commands never come from the API, since any organization owner could otherwise run programs on the host (ADR 0006).
  • Agents get a deliberately built environment rather than the server's, without its secrets, SSH agent or git configuration. What a runtime inherits (such as HOME) still exposes the server user's files to the agent.
  • Nor do they get the server user's own agent setup: Claude Code runs without its user-level settings, so that user's instructions, plugins, hooks and connected accounts (claude.ai connectors such as Slack or Linear) stay theirs, and without any CLAUDE.md above the data directory: Claude Code reads those of every directory up from where it works, which for a data directory in a home directory includes the user's own ~/.claude/CLAUDE.md. A run gets Mission Control's tools and the instructions and settings of the repository it works in. Runtimes that cannot leave these out still load them.
  • Agents do not get forge tokens; pushing and pull requests are to go through Mission Control.