GhostApproval: The AI Coding Agent Flaw That Turned 'Approve This Edit?' Into a Rubber Stamp

Augment's official response to a vulnerability that lets a malicious repository hijack its coding agent was not a patch. It was a sentence: "No patch can separate an agent's ability to edit and run code from its ability to access the file system, so we are not issuing one." That is a vendor telling you, in writing, that the safety control you were relying on cannot exist at the layer they built it.

The vulnerability is GhostApproval, disclosed by Wiz on July 8, 2026. It hits six of the most widely used AI coding assistants — Amazon Q Developer, Anthropic Claude Code, Augment, Cursor, Google Antigravity, and Windsurf — and it does it with a Unix primitive older than any of them: the symbolic link.

The four-step trick that breaks the approval dialog​

GhostApproval doesn't need a zero-day. It needs a symlink and a README.

1. Setup. An attacker publishes a repository containing a file that looks like ordinary project config — project_settings.json, say — except it's a symbolic link pointing at something outside the project, like ~/.ssh/authorized_keys or ~/.zshrc.
2. Instruction. A README or code comment asks the agent to do something routine: "set up the workspace," "update the local config," "run the setup script."
3. Following. The agent resolves the request against the symlink without checking that the real, canonical target still sits inside the project sandbox. It writes through the link.
4. Execution. The attacker's SSH public key lands in authorized_keys, or a malicious line lands in a shell startup file — outside the project, on the developer's actual machine, with no further action required.

The part that turns this from a bug into a trust crisis is what the user sees while step 3 happens. Wiz found that at least one affected agent's internal reasoning explicitly identified the target — "I can see that project_settings.json is actually a [system] configuration file" — while the approval dialog shown to the human asked only: "Make this edit to project_settings.json?" The agent knew. The user didn't. The human-in-the-loop control, the one every enterprise security review leans on to justify letting an agent touch a filesystem at all, became a rubber stamp for a write it had no way to evaluate.

Wiz classifies this UI-level piece separately — CWE-451, "user interface misrepresentation of critical information" — because it's a distinct failure from the symlink-following bug underneath it. You could fix the path resolution and still leave a dialog that describes the wrong file; you could fix the dialog and still let the write through if nobody's watching. GhostApproval is what you get when both gaps exist in the same product at once, across six of them, on tools whose combined install base runs into the hundreds of thousands of developer seats and includes agents wired into CI pipelines with standing cloud credentials — which is what turns "wrote a stray file" into "attacker has a foothold with whatever access that pipeline had."

The vendor scoreboard: three patches, two refusals, one non-fix​

Wiz's disclosure didn't land the same way everywhere, and the split is more informative than the bug itself.

Two failure modes are stacked on top of each other here, and only one of them is a fixable bug. The universal one — following a symlink without validating that its canonical target resolves inside the workspace boundary — is exactly what Google, AWS, and Cursor shipped fixes for. That's a path-resolution bug, and it has a path-resolution fix.

The second failure mode is Windsurf's, and it isn't a bug so much as an architecture choice: the agent wrote the file before showing the confirmation dialog. Wiz's own framing of this is the sharpest line in the report: "the confirmation dialog isn't an authorization — it's an undo mechanism." An undo button that fires after your SSH keys are already replaced is not a security control, and no patch to the symlink-following logic changes that ordering problem.

Augment's refusal is the most honest answer in the table, and the most damning. Their position — that separating "can edit files" from "can access the filesystem" isn't something a patch can fix — is a correct description of what happens when isolation is a policy the agent's own code is trusted to enforce. If the enforcement point lives inside the same process that's also being steered by attacker-controlled repository content, there is no version of that code that closes every path, because the thing deciding what counts as "inside the sandbox" is the thing under attack.

Why "the agent checks the path" was always going to fail​

Every one of these agents implemented workspace isolation the same way: application-level logic that inspects a path, decides whether it's inside the project directory, and allows or denies the operation accordingly. That check runs in the same process as the LLM-driven agent loop, using the same filesystem APIs an attacker's instructions can influence. Symlink-following is one way to defeat a check like that. It will not be the last — TOCTOU races between the check and the write, path traversal via encoding tricks, or simply a model persuaded to call a different tool are all the same category of problem: a boundary enforced by code that trusts its own inputs.

This is the same conclusion the broader agent-sandboxing field has been converging on independent of GhostApproval. The current operating consensus for running untrusted, LLM-driven code execution is that only a hypervisor- or kernel-enforced boundary — Firecracker microVMs, Kata Containers, or gVisor's syscall interception — is production-safe; plain containers share a kernel with the host and don't qualify, and an in-process "does this path look right" check doesn't either. GhostApproval is that consensus showing up as six real disclosures instead of a threat model on a whiteboard: the boundary these six tools shipped was software the agent could talk into misbehaving, not a wall the agent's own reasoning sits outside of.

The primitive a self-hosted PaaS actually needs​

This is exactly the problem we're building against as we roadmap agent-facing sandboxes for bex. A git-push PaaS that treats an AI agent as a first-class deploy operator — not a human typing commands through a chat window, but a caller hitting the same API a CI pipeline would — cannot make the isolation boundary something the agent's own tool-calling logic is trusted to respect. It has to be a property of the execution environment the agent is handed, enforced by something the agent's instructions can't reach.

Concretely, that means an agent-triggered build or preview environment runs inside its own microVM or Kata-class container, with its filesystem mounts, network namespace, and credentials scoped by the platform before the agent's first command executes — not validated by application code checking paths after the fact. A symlink inside an agent's workspace pointing outside the project directory should be an operation the underlying mount namespace has no way to satisfy, not a check that a well-intentioned but attacker-influenced code path forgot to run. If the agent asks for ~/.ssh/authorized_keys, the answer isn't "the sandbox logic said no" — it's that there is no ~/.ssh/authorized_keys reachable from that sandbox at all, because the host's filesystem was never mounted there in the first place. That's the difference between a policy and a boundary, and GhostApproval is what happens when a platform ships the former and calls it the latter.

What to do with this if you're running agents today​

You don't need to wait for a platform redesign to act on GhostApproval. A few concrete steps apply right now, whichever of the six tools (or others) you run:

• Patch immediately if you're on Google Antigravity, AWS Q Developer/language server, or Cursor — versions above the fixed builds in the table close the symlink-following path.
• Stop treating Augment and Windsurf's approval dialogs as authorization for filesystem writes until they ship a fix. Augment has told you directly they won't; Windsurf hasn't said anything, which given the pre-write-then-prompt ordering Wiz documented, you should read as the same answer.
• Vet third-party repositories before pointing an agent at them, especially ones you didn't author — a symlink disguised as config is invisible in a normal git diff review unless you're specifically checking file types.
• Run agents that touch untrusted repositories inside real isolation — a Firecracker or Kata boundary you control, not the agent vendor's in-app sandbox — if the agent's own tooling is your only layer of defense.

The tools that patched did the right thing quickly. The ones that didn't are telling you, correctly, that there's a limit to what can be fixed inside an agent's own process. Believe them, and put the boundary somewhere they can't reach.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with agent-triggered deploys running in platform-owned isolation instead of a chat window's promise to behave. Star the repo on GitHub or deploy your first app today.