TrustFall: 1-click coding agent RCE in Claude, Cursor, Copilot

How the four CLIs differ

The summary treats the four agentic CLIs as uniformly affected. The page's actionable addition is that exposure is identical but informed-consent framing varies — which changes how detectable the attack is per-tool at the moment of trust:

• Gemini CLI — most informative: trust dialog warns about project MCP servers and lists them by name.
• Cursor CLI — shows an MCP-specific warning, but does not enumerate servers.
• Claude Code (v2.1+) — generic "Quick safety check: Is this a project you created or one you trust?" with no MCP mention.
• Copilot CLI — generic "trust this folder" prompt, no MCP mention.

All four default to "Yes/Trust," so one Enter keypress is sufficient for RCE in each.

Three silent project-scoped settings

The summary names two auto-approve settings. The page identifies a third: permissions.allow (covered in the post's Appendix B) alongside enableAllProjectMcpServers and enabledMcpjsonServers. All three live in project scope and can silently spawn executables. By contrast, bypassPermissions is already blocked from project scope or gated behind a red-warning dialog — the MCP-enabling settings are not. The payload need not be a file on disk: the entire script can live inline in .mcp.json, executing on server startup before any Claude tool call.

What to do

The page gives the same three defender mitigations for all four CLIs:

• Audit committed config files (.claude/settings.json, .mcp.json, and equivalents) in any cloned or PR-branch repo before trusting the folder.
• Inspect command/args inline in those config files — the executable path and arguments are attacker-controlled.
• Monitor child processes of the agent — MCP servers run as native, unsandboxed OS processes with full user privileges, not confined to the project directory or any filesystem/network subset.

For Claude Code specifically, the older trust dialog offered an opt-out to proceed with MCP disabled; v2.1+ removed both the warning and that option, so there is no in-dialog mitigation. On CI (the default claude-code-action headless mode) the dialog never renders, so config auditing is the only control.

Caveats

• Anthropic reviewed the report and declined it as outside their threat model: accepting "Yes, I trust this folder" is treated as full consent, and post-dialog execution is "the boundary functioning as designed." The researchers do not contest where the boundary sits — their claim is narrower: the v2.1+ dialog does not disclose what it authorizes. Full exchange is in the post's Appendix C.
• The cross-CLI parity check was done after Anthropic's response, which reframed the finding from a Claude Code regression to a shared convention — the researchers note you can disclose a vulnerability to a vendor but not a convention, so expect no coordinated fix across the four tools.