A Decades-Old Bash Trick Just Beat the Safety Filter in 10 of 11 AI Coding Agents. If You Run opencode, Goose, Cline, or Aider, Your Allowlist Is Theater.
A Decades-Old Bash Trick Just Beat the Safety Filter in 10 of 11 AI Coding Agents. If You Run opencode, Goose, Cline, or Aider, Your Allowlist Is Theater.
Adversa AI published research it calls GuardFall on June 30, and the one-line version is uncomfortable: the command approval filter inside almost every popular open-source coding agent can be walked straight through. The researchers tested eleven agents and bypassed the safety checks in ten of them. The trick isn't a novel exploit or a clever prompt. It's a decades-old fact about how shells parse text, the kind of thing that was old when I started scripting.
Here's the mechanism, because it matters. These agents let a model propose a shell command, then run it against an allowlist to decide whether it's safe. The problem is that the allowlist inspects the command as plain text, while bash rewrites that text before it executes. The shell strips quotes, expands shortcuts, and resolves substitutions. So the filter looks at one command, approves it, and the shell then runs a different one. A hidden instruction (say, buried in a file the agent reads, or in a dependency's README) can smuggle a command that quietly wipes files or exfiltrates whatever your account can reach: SSH keys, cloud credentials, anything sitting in your home folder.
Why this hits solo operators harder than anyone
Big companies run these agents inside sandboxed CI, on ephemeral boxes with scoped service accounts and no standing secrets. That's not how a one-person shop works, and I know it because it's not how I work. My coding agent runs on the same laptop that holds my production database URL, my deploy tokens, and a .aws/credentials file I set up two years ago and haven't thought about since. The blast radius of a hijacked command on that machine is my entire business.
The agents involved aren't fringe. Adversa's list includes opencode, Goose, Cline, Roo Code, Continue's peers in the category, Aider, Plandex, Open Interpreter, OpenHands, and SWE-agent, collectively somewhere around 548,000 GitHub stars. If you do agentic coding at all, you almost certainly run one of these. The comfort of "it asks me before running dangerous commands" is exactly the feature that just failed, because the thing deciding what's dangerous was reading a different command than the one that ran.
The one that held up, and why
Continue was the single agent that survived the test, and the reason is instructive. Instead of pattern-matching the command as a string, Continue reads it the way bash will: it breaks the command into the same tokens the shell would produce, checks what actually runs after expansion, and keeps a hard list of destructive verbs that are blocked outright regardless of how they're dressed up. In other words, it closes the gap between what the filter sees and what the shell does.
That's the correct engineering fix, and if you're choosing an agent, it's a real differentiator. But I want to be careful not to oversell it. "Continue passed this specific test" is not "Continue is unbreakable." It means one team thought about the parser mismatch and the others didn't. The deeper lesson isn't which tool to trust: it's that a text-matching allowlist is not a security boundary, and you shouldn't treat any agent's command filter as one.
The Saturday fix
You don't need to wait for eleven upstream patches. You need to change your assumption that the agent's approval prompt protects you, and put a real boundary underneath it.
Run the agent in a container or a dedicated VM, not on your primary machine. The whole point is that if a command escapes the filter, it lands somewhere that doesn't hold your keys. Give that environment only the credentials the current task actually needs: a scoped token for one repo, not your full cloud profile. Rotate the secrets that have been sitting in your home directory next to a tool that runs model-generated shell commands; if an agent has had ambient access to your .aws or .ssh folder, treat those as exposed and cycle them. Turn off any "auto-approve safe commands" setting and leave it off. That toggle is the exact door GuardFall walked through. And keep your agent's write access scoped to the project directory rather than the whole filesystem.
None of that is exotic. It's the boring isolation work that the convenience of "just let it run" quietly talked us out of. The research is a good excuse to put it back.
The honest counter-take
Let me argue against my own alarm for a second. This is proof-of-concept research, not a wave of in-the-wild compromises, and the attack still needs a delivery path (a malicious file, a poisoned dependency, a prompt-injected web page) to plant the hidden command in the first place. If you only ever point your agent at code you wrote, on tasks you fully specify, your practical exposure is lower than the headline suggests.
But that's a thin reed to lean a business on. The whole value of a coding agent is that it reads things you didn't write: dependencies, issues, docs, scraped context. The delivery paths are the normal way these tools are used. And the cost of the fix is a weekend of isolation setup versus the cost of being wrong, which is every credential on your development machine. That asymmetry isn't close. Sandbox the agent, scope the keys, and stop trusting a filter that reads a different command than the one that runs.
Author
Lukas
@lukcombinator