A researcher at Wiz spent part of this month breaking AI coding assistants with a trick that predates most of the developers using them. On July 8, Wiz disclosed GhostApproval, a flaw affecting six of the most widely used AI coding tools: Amazon Q Developer, Anthropic’s Claude Code, Augment, Cursor, Google Antigravity, and Windsurf. The proof of concept is almost embarrassingly simple. Drop a symlink into a repository, name it something boring like project_settings.json, and point it at the developer’s SSH keys. Ask the assistant to set up the workspace or follow the README. The agent resolves the symlink, writes to the real target, and the approval dialog the whole safety model depends on shows the harmless filename the entire time.
A Unix trick older than the tools it’s breaking
Symlinks have been a Unix attack surface since before most of us were born. A symlink is just a file that says “actually, go look over there instead.” Programs that don’t check where “there” is before acting on it have been getting burned by this for decades, in cron jobs, in setuid binaries, in tar extraction. What’s new is who’s getting burned now. These coding agents run with real filesystem access on a developer’s machine, they follow instructions embedded in repository content (a README, a config file, a comment), and they ask for one thing in return for that trust: a visible, honest approval step before they touch anything sensitive. GhostApproval breaks the honest part. Wiz found that in several of the affected tools, the agent correctly resolves the symlink internally, meaning it knows it’s about to write to ~/.ssh/authorized_keys, but the confirmation prompt still shows project_settings.json. The developer isn’t approving a shortcut. They’re approving a lie they can’t see.
The point of an approval dialog is that you can trust it
We’ve written before about how AI tools are changing what it costs to build software, and we use these tools ourselves. That’s exactly why this bug matters to us. The entire pitch of “human in the loop” agentic coding is that the human step is real: the agent proposes, you look, you decide. GhostApproval shows that proposal and decision can be decoupled without anyone noticing, because the UI is trusted more than the filesystem underneath it. A malicious open source dependency, a compromised contractor’s fork, even a coworker’s cloned repo with a bad symlink sitting in it from an unrelated tool: any of these can turn a routine “set up my workspace” into remote code execution. Exploiting it doesn’t take a sophisticated attacker, just one bad symlink and a developer who trusts the dialog box. That trust is the whole point of the dialog box, and most developers have it.
Vendors don’t agree on whether this is a bug
The response split in a way worth paying attention to. Amazon, Google, and Cursor treated it as a real vulnerability and shipped fixes, and Cursor’s fix carries a CVSS score of 9.8 under CVE-2026-50549. Augment and Windsurf acknowledged Wiz’s report and then went quiet, with no fix out as of this writing. Anthropic took a different position entirely: it disputed that Claude Code’s behavior is a vulnerability at all, arguing that a developer who trusts a directory and clicks approve owns that decision, and that this scenario sits outside its threat model.
There’s a coherent argument buried in that response, but we think it’s the wrong one for how these tools actually get used. “Trusting a directory” is a reasonable model when you wrote every file in it. It stops being reasonable the moment you clone a repository, pull in a dependency, or let an agent operate on anything you didn’t personally audit, which is most of what these tools exist to speed up. If the tool can’t tell you which file it’s actually about to write to, you were never given the chance to trust or distrust anything. You were given a filename and asked to believe it.
What we’d actually do differently
We don’t think this is a reason to stop using AI coding tools. It’s a reason to stop treating their approval prompts as a security boundary and start treating them as a convenience feature, which is what they are. In practice that means running agents in a sandbox with filesystem access scoped to the project directory only, never a home directory with SSH keys, cloud credentials, or shell history sitting a few folders up. It means treating repository content, including READMEs and config files, as untrusted input the same way you’d treat a form submission: an agent following instructions embedded in a file doesn’t know the difference between your documentation and an attacker’s. And it means checking, not assuming, that a written path matches what the tool showed you before you approved it. None of this is exotic. It’s the same discipline that CI systems learned to apply to untrusted pull requests years ago, now applied to a tool that has more autonomy and less scrutiny than most CI jobs ever got.
This is the kind of judgment call we build into AI-assisted engineering work: which parts of a build genuinely benefit from an agent operating with real permissions, and which parts need a sandbox, a review gate, or a human doing it directly because the failure mode isn’t worth the time saved. Until that’s fixed, a tool that can’t account for what it touched isn’t a productivity feature, it’s a liability. If you’re weighing how to bring AI tooling into a build without inheriting bugs like this one, get in touch.