TrustFall: the one-click RCE hiding in your coding agent's trust dialog
The same researchers who broke six AI coding agents with a disguised file copy came back with a second technique, and this one is quieter. It is called TrustFall, and it lives inside the one piece of UI everyone insists is the safety net: the trust dialog. The disclosure names Claude Code, Cursor, Gemini CLI, and GitHub Copilot. A cloned repository gets to run unsandboxed code on your machine after a single keystroke. On a CI runner, it needs no keystroke at all.
If SymJack was about the filesystem doing something different from what the prompt showed, TrustFall is about the trust decision itself being weaker than you think. The prompt is honest about what it is asking. The problem is that saying yes once, in the wrong scope, grants far more than you intended, and a regression made saying yes far too easy.
Two small bugs that combine into a big one
TrustFall is not one flaw. It is two ordinary-looking ones stacked, and the stack is what makes it dangerous.
The trust-dialog regression. The workspace-trust prompt is meant to be a deliberate, high-friction decision: do you trust this folder enough to let the agent execute code from it? A regression collapsed that friction. Instead of a considered choice, trusting a freshly cloned workspace became a one-keystroke action, the kind of confirmation muscle memory clears without reading. The gate is still there; it no longer slows anyone down.
The settings-scope inconsistency. These agents read configuration from more than one place: a user-level config that applies everywhere, and a project-level config that ships inside the repo. The bug is a mismatch in how trust and scope interact: a setting that should only take effect for a trusted, user-blessed scope gets honored from the project scope instead. So a file the attacker placed in the cloned repo gets treated as if you had configured it yourself, system-wide. The repo brings its own settings, and the agent applies them with your authority.
Put them together and the path is short. You clone a repo. The project-scoped settings the attacker shipped are honored. The one weakened keystroke trusts the workspace. The agent now executes code the way the planted config tells it to, unsandboxed, as you.
The keystroke you have already trained yourself to ignore
The uncomfortable part of TrustFall is how much it relies on a habit the tools built into you. These coding agents throw confirmation prompts constantly: trust this folder, allow this command, approve this edit. The volume is the point of failure. When the hundredth prompt of the day looks exactly like the first ninety-nine, "yes" stops being a decision and becomes a reflex.
A trust dialog only protects you if the moment of friction is real. A regression that turns it into a single keystroke does not only save a click; it removes the pause where a human might notice something is off. The dialog still appears, so everyone reports the feature as present and working. The protection it was supposed to provide quietly left the building.
CI is where it stops needing you
The interactive version of TrustFall costs an attacker one careless keystroke from you. The CI version costs nothing, because CI removes the human entirely.
Teams now run these agents inside continuous integration: triaging issues, opening PRs, fixing failing tests, reviewing contributions. Those runners almost always auto-trust their own checkout and run the agent in a non-interactive mode that approves prompts by default. That is exactly the configuration TrustFall wants. The project-scoped settings ride in on a pull request, the runner trusts its own workspace without asking anyone, and the code executes on a machine that holds your deploy keys and registry tokens. No keystroke, no operator, no dialog for anyone to misread, because the dialog was answered by policy before the job even started.
This is the same lesson the npm supply-chain wave keeps teaching, arriving through a different door. The malicious input is a contribution to your own repository, and the thing that runs it is your own automation.
Why trust-dialog bugs keep coming back
TrustFall is the second trust-prompt failure in this category in a matter of weeks, and that pattern is the real story. Workspace trust is genuinely hard to get right. The dialog has to be frequent enough to cover each risky action, rare enough that people still read it, accurate about scope, and consistent across user and project configuration. Miss any one of those and the prompt becomes theater: present in the UI, absent in effect.
The deeper problem is that "trust" in these tools is a single yes/no standing in for a pile of distinct permissions: run shell commands, write config, load tool servers, reach the network. Collapsing all of that into one keystroke means any regression in that keystroke leaks all of them at once. The dialog is doing too much work for how little friction it carries.
What to change today
You cannot fix the regression yourself, but you can stop trusting the trust prompt as your only line of defense.
Update your agents now. Vendors named in the disclosure have been shipping patches. The trust-dialog regression is the kind of thing a point release fixes, so check the changelog for your tool and pull the latest build before anything else.
Stop running agents against untrusted repos on machines that matter. If you clone strangers' code or review external PRs with an agent attached, that host should not also hold production credentials, long-lived tokens, or SSH keys. Treat it as expendable.
Do not let project-scoped config inherit your authority. Where your tool lets you, pin trusted settings to the user scope and refuse to honor agent or execution settings that arrive inside a repo. A repository should not get to reconfigure the tool that is reading it.
Kill blanket auto-trust in CI. This is the highest-impact change. A runner that auto-trusts its own checkout and auto-approves tool calls is the zero-keystroke version of this attack waiting to happen. Scope what the agent may execute, run it against untrusted contributions in a throwaway sandbox with no ambient credentials, and never let a pull request's own files decide what the agent is allowed to do.
Slow your own keystroke down. The regression works because trust confirmations are reflexive. Until you have updated, treat any workspace-trust prompt on a fresh clone as the one prompt of the day worth reading closely.
What the vendors have to fix
The burden cannot sit on a developer remembering to read one dialog out of a hundred. The durable fixes live in the tools:
- Restore real friction to workspace trust on untrusted clones, and never let a one-keystroke confirmation grant code execution.
- Make scope precedence explicit and safe by default: user-blessed settings win, and execution-relevant settings shipped inside a repo are ignored unless deliberately promoted.
- Split "trust" into separable permissions so a regression in the confirmation flow cannot hand over shell, config, and tool-loading all at once.
- Refuse to auto-trust in non-interactive mode without an explicit, narrowly scoped policy; defaulting CI to "trust everything" is the unsafe choice.
The bigger pattern
TrustFall belongs to the same family as the disguised file copies, poisoned MCP servers, and backdoored instruction files filling this category's disclosure feed. The common thread is that AI coding agents accept a lot of their marching orders from local files and brief human confirmations, and both of those inputs are easier to subvert than a memory-corruption bug. The trust dialog was supposed to be the human checkpoint that made the rest of it safe. When the checkpoint regresses to a reflex, everything downstream of it inherits the weakness. As you hand more autonomy to these tools, the cheapest thing for an attacker to attack is not the model; it is the one keystroke standing between a cloned repo and your shell.