TrustFall finds AI-coding CLI flaw

AI coding CLIs just picked up a very old software problem in a very modern wrapper. A repository is supposed to be something you inspect before you run. But TrustFall shows that four popular command-line coding agents can blur that line badly enough that “open the folder” can become “start attacker code.” The bug pattern is not really about the model. It is about trust prompts, project config, and helper processes that get too much power too early. (adversa.ai) ### What actually gets abused? The object here is MCP — Model Context Protocol. MCP servers are little helper programs that give an AI coding tool extra capabilities, like reaching external services or running local tooling. Gemini CLI and Cursor both document MCP support, and Copilot CLI exposes MCP configuration too. That extension model is useful, but it also means a repo can carry instructions for programs the CLI may start locally. (google-gemini.github.io) ### Where does the trap live? Adversa’s proof of concept uses project files like `.mcp.json` and, in the Claude Code deep dive, `.claude/settings.json`. The basic move is simple — put MCP server definitions in the repo, make the project settings auto-approve them, then wait for the user to accept the folder trust prompt. After that, the helper process starts as a normal OS process on the developer machine. (adversa.ai) ### Why is one keypress enough? Because the trust dialog is doing more work than it looks like. In Adversa’s description, the user is not approving “run this specific executable now.” The user is approving the folder, and the tool treats that as consent for project-defined MCP startup. In Claude Code, the researchers say older dialogs explicitly warned a(adversa.ai)lished exchange, is that this behavior is inside its threat model — if you trust the folder, you trust the config. (adversa.ai) ### Why does that matter so much? Because these MCP servers are not tiny sandboxed toys. The TrustFall write-up says they run unsandboxed with the developer’s privileges. That means the process can potentially read local secrets, inspect source code outside the cloned repo, or keep a long-lived command-and-control channel open. The scary part is not “the(adversa.ai) approved.” (adversa.ai) ### Is this only a Claude Code problem? No — Claude Code is just the deepest case study in the report. Adversa says it confirmed the same core pattern in Gemini CLI, Cursor CLI, and GitHub Copilot CLI. Dark Reading and SecurityWeek both frame the issue the same way: malicious repositories can trigger code execution across multiple AI coding assistants with minimal interaction. (github.com) ### Why does CI make it worse? Because headless automation can skip the human checkpoint entirely. The TrustFall materials say Claude Code running in CI via the official action does not render the trust dialog, which turns the same idea into a zero-click path on pull-request branches. That is a different level of risk — now the target is not just a curious developer cloning a repo, but shared pipelines that touch secrets and deployment credentials. (adversa.ai) ### So what should teams change? Treat repo-scoped AI-agent config like executable content, not harmless metadata. Block or review `.mcp.json`, agent settings files, and any project-level MCP declarations in the same way you would review CI config or shell scripts. The quick mental model is this — if a repo can tell your coding agent which local helper to start, that repo already has a path to code execution. (adversa.ai) ### Bottom line TrustFall matters because it moves the supply-chain boundary. The risky moment is no longer just `npm install` or running a setup script. It can happen earlier — at the point where a developer or CI job decides a folder looks safe enough to trust. (adversa.ai)