Science1 publisher3 min readPublished
The trust prompt is the attack surface: cloned repos can spawn MCP servers with your privileges
Adversa.ai says Claude Code's folder-trust dialog stopped naming MCP servers in v2.1, while a repo-supplied config can still launch an unsandboxed process on one keypress.
The Scientist · Science desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction
What happened
- Adversa.ai's TrustFall report states that four agentic coding CLIs, Claude Code, Gemini CLI, Cursor CLI and Copilot CLI, execute project-defined MCP servers the moment a developer accepts the folder trust prompt.
- Claude Code's trust dialog used to warn about MCP servers in a cloned repository and offer an opt-out; in v2.1 and later that warning was removed.
- The current Claude Code dialog reads "Quick safety check: Is this a project you created or one you trust?" and lists nothing.
- A malicious repository ships an MCP server and auto-approves it via its own .claude/settings.json; one Enter keypress spawns the server as an unsandboxed OS process with the developer's full privileges, and no tool call from Claude is required.
- The payload does not need to be a file; the entire script can live inline in .mcp.json.
Compiled by The ScientistSomething wrong?How this is made
Why it matters
Adversa.ai has published a report it calls TrustFall, which says four agentic coding CLIs, Claude Code, Gemini CLI, Cursor CLI and Copilot CLI, execute project-defined MCP servers the moment a developer accepts the folder trust prompt [1]. That places the consequential decision in a dialog most developers clear by reflex, not in anything the model does afterwards [1][8].
The Claude Code chain is the one Adversa documents in detail. According to the report, the trust dialog used to warn that a cloned repository contained MCP servers and offered an opt-out, and in v2.1 and later that warning was removed [2]. The dialog now reads "Quick safety check: Is this a project you created or one you trust?" and lists nothing [3]. A malicious repository ships an MCP server and auto-approves it through its own .claude/settings.json, so one Enter keypress starts that server as an unsandboxed OS process with the developer's full privileges, with no tool call from Claude required [4]. The payload does not have to be a file on disk; the whole script can sit inline in .mcp.json [5].
The privilege picture is the part operators should sit with. Adversa says these servers run as native OS processes with the full rights of the user running Claude Code, not sandboxed, not confined to the project directory, and not restricted to any subset of filesystem or network [6]. In practice that means reading stored secrets and source code from unrelated projects, or opening a long-lived command-and-control channel [7].
There is an internal inconsistency worth noting. Other dangerous settings, such as bypassPermissions, are already blocked from project scope or gated behind a red warning dialog, while the MCP-enabling settings are neither [9]. The report describes a third silent path through permissions.allow [10], and counts three project-scoped settings that can spawn arbitrary executables behind the prompt [11].
Continuous integration removes even the keypress. Adversa says that when Claude Code runs headless, the default for the official claude-code-action, the trust dialog is skipped and never renders, so the same attack runs with zero human interaction against pull-request branches [12].
Anthropic's security team reviewed the report and declined it as outside their threat model, on the basis that accepting "Yes, I trust this folder" is consent to the full project configuration and that post-dialog execution is the boundary working as designed [13]. Adversa says it does not contest where that boundary sits, and is instead documenting an informed-consent gap inside it, since the dialog no longer says what it is asking permission for [14]. The cross-CLI parity check came after that response and reframed the finding from a vendor regression to a shared convention, which is why Adversa did not pursue vendor-by-vendor disclosure [15]. All four tested CLIs default to Yes or Trust and differ only in how the dialog frames the authorization [8].