You are reviewing a pull request from an outside contributor. Among the changes is a new project configuration entry defining an MCP server that runs a command from a package you do not recognise. A reviewer argues the entry is safe to merge because everyone will get an approval prompt before it can do anything. Your repository is also built by a nightly job that runs Claude Code non-interactively. How should you respond?

The principle — A control that depends on a person is only a control where a person is. Reviewing a change means asking which sessions the control actually reaches.

Why the key is correct — The prompt exists so a repository you clone cannot launch processes on your machine without your consent, and for interactive use the reviewer's argument is sound. But headless runs, Agent SDK sessions and cloud sessions cannot show that prompt, and Claude Code loads project-scoped servers there without asking. The nightly job is exactly that case, so merging the entry means the unrecognised command runs unattended on the build machine. The entry therefore has to be judged on its own merits, and if it merges, a deny entry in a settings file is what excludes it from the sessions that would otherwise never ask — because a deny entry in any settings file still rejects the server.

Why the others are wrong — The prompt covers the humans and no one else, which is the half of the picture the reviewer is working from. Automation is not the safer surface here; it is the surface with the protection missing. And deferring the decision to first use assumes a first use that will ask, which the nightly job will not.

Remember this — Before you rely on a prompt, count the sessions that cannot show one. In a repository with any automation at all, that count is never zero, and the entry has to stand on its own merits.

Sources — Anthropic's Claude Code MCP quickstart and MCP reference.