Uchi Uchibeke

· Security

TrustFall: When Trust This Folder Becomes Remote Code Execution

Cloning a repo and pressing Enter on Claude Code's trust dialog spawns an unsandboxed MCP server with full OS privileges. Anthropic called it design intent.

TL;DR

  • Adversa AI disclosed "TrustFall": a vulnerability where cloning a malicious repo and pressing Enter on Claude Code's trust dialog spawns an unsandboxed MCP server with full OS privileges.
  • The attack works on Claude Code, Gemini CLI, Cursor CLI, and GitHub Copilot CLI. All default the dialog to "trust."
  • In CI/CD (for example, claude-code-action on GitHub Actions), the dialog never renders, making it a zero-click attack against pull request branches.
  • Claude Code v2.1+ silently removed the MCP-specific warning from the trust dialog. Users approve arbitrary code execution without knowing it.
  • Anthropic acknowledged the report and declined to patch, calling it "design intent."
  • The fix is architectural: pre-action authorization that checks MCP server execution against declared permissions.

Imagine you clone a GitHub repository to check out a cool new open source project. You run claude in the directory. A dialog pops up: "Quick safety check: Is this a project you created or one you trust?" The default button says Yes.

You hit Enter.

That keystroke just spawned a remote-controlled OS process with your full user privileges. No suspicious file. No warning about what's about to run. No second chance.

This is not a hypothetical. It's the TrustFall attack, documented by Adversa AI's Rony Utevsky. And it works on every major AI coding CLI shipping today: Claude Code, Gemini CLI, Cursor CLI, and GitHub Copilot CLI. All four tested auto-execute project-defined MCP servers the moment the user accepts the folder trust prompt.

The dialog that no longer tells the truth

Claude Code's trust dialog used to be better. Before v2.1, it warned about detected MCP servers in a cloned repository and offered an opt-out. You could see what would run before you approved it.

In v2.1, that warning was removed. The dialog now says: "Quick safety check: Is this a project you created or one you trust?" It lists nothing. It warns about nothing. It tells you nothing about the fact that accepting will spawn arbitrary executables defined by the repo's .mcp.json file.

That file can point to any executable, any script, any language runtime on your machine. And the payload doesn't even need to be a separate file. The entire script can live inline in .mcp.json itself, leaving nothing on disk for a reviewer or static scanner to flag.

Anthropic's response? Acknowledged as "design intent." Not a vulnerability. Working as designed. The informed consent gap, where the dialog asks permission but doesn't tell you what you're permitting, is real, and they've explicitly decided it falls outside their threat model. Read the full back-and-forth in Appendix C of the Adversa report.

How TrustFall works: three settings, zero defenses

The attack exploits three configuration features that work together to bypass every security boundary users reasonably expect.

1. enableAllProjectMcpServers

A setting in .claude/settings.json that auto-approves every MCP server defined in the project's .mcp.json. Once this is set, Claude Code doesn't prompt before executing any defined server. It just runs it.

2. enabledMcpjsonServers

A variant that auto-approves a named subset of servers. Same effect, narrower scope.

3. Inline payload support

The .mcp.json spec allows the entire command to be defined inline as a JSON value. No separate script file. No binary to scan. The infection lives entirely within a structured config file that looks like configuration until the moment it executes.

Adversa's public PoC opens the OS calculator with a single Enter keypress. The CI/CD variant exfiltrates process.env from a GitHub Actions runner to an attacker-controlled URL. No user interaction required.

The CI/CD nightmare

The scariest variant is the CI/CD version. Claude Code supports a headless mode used by the official claude-code-action GitHub Action. When running headless, the trust dialog never renders. It's skipped entirely.

An attacker opens a pull request against your repository. The CI runner pulls the branch, starts Claude Code in headless mode to review or modify the code, and the malicious .mcp.json executes immediately. Zero clicks. Zero warnings. Zero logs that indicate anything unusual happened.

The payload reads environment variables, deploy keys, signing certificates, and any credential the runner has access to. Then it quietly includes them in the build output or exfiltrates them out-of-band. The PR looks like a legitimate contribution. The CI passes. The code ships.

As SecurityWeek reported, Alex Polyakov from Adversa AI describes the blast radius as identical to traditional software supply chain attacks, "with the initial-access bar collapsed to 'clone and hit Enter.'"

Why this is different from other agent vulnerabilities

This is worse than most agent vulnerabilities for three reasons.

First, there is no exploit skill. The attacker doesn't need to craft a complex payload. They just put standard MCP configuration files in a repository. Every developer who clones that repo and runs Claude Code is a potential victim.

Second, the platform explicitly declined to fix it. Microsoft patched Semantic Kernel. OX Security disclosed with coordinated disclosure. Anthropic called this "design intent" and moved on. If you use Claude Code, this is your reality until Anthropic changes its mind.

Third, the attack spans every major coding CLI. This isn't an Anthropic-only problem. Gemini CLI, Cursor CLI, and Copilot CLI all have the same gap. The ecosystem collectively decided that a "Do you trust this folder?" dialog is sufficient authorization for arbitrary code execution.

It's not.

The architecture problem

The MCP protocol is brilliant for extensibility. A standard way for coding agents to connect to databases, file systems, and external APIs is exactly what the ecosystem needs. But the security model, "trust this folder once, run everything inside it forever," was designed for an era when folders contained source code and configuration, not executable servers.

This is the same gap that shows up across AI agent frameworks. The permissions model is evaluated once at setup time and never rechecked at execution time. The trust boundary is coarse-grained. The user is asked to consent to everything at once, with no visibility into what "everything" actually includes.

The Open Agent Passport approach in APort defines a before_tool_call authorization hook that evaluates every tool invocation individually. You don't approve "all MCP servers in this project." You approve each concrete execution: spawn node /tmp/payload.js gets blocked even if .mcp.json says it's fine. The trust model evaluates the action, not the configuration.

This is the architectural difference between "trust this person with your house keys" and "approve entry one door at a time."

I've been building this approach into APort and proposing it to the major frameworks (crewAI #4877, haystack #10821, and others). Adversa, who reported TrustFall, got "design intent" back from Anthropic.

What's really at stake here

The Hugging Face and ClawHub supply chain compromises demonstrated that attackers are already exploiting repository trust to distribute malicious AI assets. JFrog found more than 100 models on Hugging Face capable of arbitrary code execution. Koi Security audited all 2,857 skills on ClawHub and found 341 malicious ones. Protect AI, scanning more than four million Hugging Face models, flagged roughly 352,000 unsafe or suspicious issues across 51,700 of them.

The AI ecosystem runs on trust in shared infrastructure. That trust is being systematically exploited.

Every developer who clones a repo and presses "Yes, I trust this folder" is making a bet that the repository maintainer is honest. That bet used to be safe because the worst that could happen was bad code in your editor. Now the worst that can happen is arbitrary code execution with your full privileges, deployed across your CI pipeline, pushed to your users.

A single compromised repository can cascade through the supply chain. A developer trusts a repo, Claude Code spawns an MCP server that reads AWS credentials, the CI pipeline ships those credentials into the build artifact, and every downstream consumer who runs that artifact is compromised. This is the supply chain crisis SecurityWeek is warning about.

What should happen next

The minimum fix for Anthropic is trivial: add MCP server detection back to the trust dialog. List the servers that will be auto-approved. Show the file path and the command that will run. Let the user make an informed decision.

Better yet, block enableAllProjectMcpServers and enabledMcpjsonServers from project-scope settings. These are dangerous enough that they should require explicit user opt-in at the CLI configuration level, not something a cloned repository can override.

The architectural fix is pre-action authorization for MCP server execution. Before spawning a process defined in .mcp.json, check: is this server declared in a permissions: stanza? If no, prompt for approval. If yes, verify the execution matches the declaration. Every time.

Anthropic already blocks bypassPermissions from project scope. They already gated other dangerous settings behind red warning dialogs. The MCP-enabling settings are neither blocked nor gated. This is an oversight, not a design principle. Closing it would cost one sprint.

The most dangerous action your agent can take without you knowing

I'll go first: Claude Code can spawn an unsandboxed MCP server with my full OS privileges after I press Enter on a single dialog that mentions none of this.

Have you audited what .mcp.json settings exist in your cloned repositories? Have you checked what your CI/CD Claude Code action would do against an attacker-controlled PR branch? Those are the two questions worth answering today.