What GhostApproval Reveals About Approval Screens in AI Coding Agents

Many AI coding agents are designed to pause before certain file edits or command executions, show the proposed operation, and ask the user to approve or reject it.

But a confirmation screen is useful only if it functions as a real authorization gate.

On July 8, 2026, Wiz Research disclosed GhostApproval, a systematic vulnerability pattern affecting six AI coding tools. A malicious repository could use symbolic links to cause an agent to access files outside the intended workspace.

The failure appeared in different forms. Some products displayed the apparent in-workspace path rather than the resolved target. Others wrote before approval, or showed no confirmation screen at all.

The broader lesson is that human-in-the-loop approval works as a safeguard only when execution is paused pending approval and the approver is shown accurate information about the real target and impact.

What GhostApproval Actually Is: Symlink Following—and, in Some Cases, a Misleading Approval UI

GhostApproval is a family of vulnerabilities in which a symbolic link inside a malicious repository lets an AI coding assistant read or write files outside the workspace.

At the technical level, the flaw is insufficient validation of a symlink’s resolved target before the agent follows it.

A file with an innocuous name such as project_settings.json can in fact be a symlink pointing to something sensitive, such as ~/.ssh/authorized_keys. When a developer asks the agent to set up the workspace for a downloaded repository, the agent follows the link and writes to that target.

Wiz Research describes this base mechanism as a known vulnerability class, CWE-61 (symlink following).

The vulnerability manifested differently across products. In some tools, writes occurred before the user approved anything. In others, no confirmation screen appeared at all. And in several tools, the confirmation screen showed only the apparent in-workspace path rather than the resolved target the agent actually accessed.

Wiz frames this last group of cases as CWE-451—a failure to communicate critical information through the user interface—layered on top of the underlying symlink issue. This UI failure was found in several of the tested products, not in all of them.

The Claude Code case Wiz documented illustrates the pattern. The reasoning shown in Wiz’s test indicated that the agent had identified the resolved target as a zsh configuration file, while the confirmation screen presented to the user read simply, “Make this edit to project_settings.json?”—with no indication of the real target.

The approver was being asked to decide without knowing what would actually be modified.

As Wiz Research puts it, informed consent is meaningful only when the dialog accurately reflects what will happen.

Six Tools, One Shared Weakness, and a Mixed Response

Wiz Research tested six tools: Amazon Q Developer, Anthropic’s Claude Code, Augment, Cursor, Google Antigravity, and Windsurf.

The significance of the finding is that Wiz identified variants of the same underlying trust-boundary failure across products from six independent vendors, rather than a single implementation bug.

The table below shows the status reported by Wiz on July 8, together with additional public information reviewed as of August 11, 2026. Vendor documentation is used where available; otherwise, the status remains attributed to Wiz Research.

Vendor / Product	Severity (per Wiz)	Status reported by Wiz on July 8	Additional public information reviewed as of August 11
AWS / Amazon Q Developer	High	Fixed in Language Server 1.69.0 (CVE-2026-12958)	AWS’s security bulletin states that the missing symlink-validation issue affected versions below 1.69.0 and was remediated in 1.69.0
Google / Antigravity	Critical	Fixed; Wiz’s disclosure timeline says Google deployed a fix on May 22, 2026	No fixed version number was identified in the sources reviewed. Version 1.19.6 is listed by Wiz as an affected version, not as the fixed version. No CVE had been assigned at publication
Cursor	Critical	Fixed in 3.0 (CVE-2026-50549)	The vendor advisory states that versions before 3.0 were affected and that the issue was fixed in 3.0
Augment	Critical	Acknowledged. At the time of testing, writes followed symlinks silently—no Allow/Deny dialog and no Undo button—and no further update was reported by Wiz at publication	Auggie CLI 0.34.0 added approval requirements for saving files to sensitive paths. The release note does not establish remediation of the symlink-based read and write paths Wiz tested
Windsurf / Devin Desktop	Critical	Acknowledged; no further update reported by Wiz at publication	Devin Local 3.6.27 changed its local edit and write tools to refuse writes through symbolic links
Anthropic / Claude Code	Disputed	Initially treated as outside the threat model	According to Wiz, a symlink warning shipped in 2.1.32 before the report was filed, and versions 2.1.173 and later resolve symlinks and warn before sensitive writes

Two of these entries deserve a note on scope.

For Augment, the release note for Auggie CLI 0.34.0 describes added approval requirements for saving files to sensitive paths. It does not mention GhostApproval, symbolic links, or reads from outside the workspace. This is best described as related hardening rather than confirmed full remediation. Public sources also do not establish that the build Wiz tested and the later CLI release cover exactly the same execution paths.

For Windsurf, now offered as Devin Desktop, the changelog for Devin Local 3.6.27 states that its edit, write, apply_patch, and notebook_edit tools now refuse to write through a symlink. That addresses the symlink-based write path described in the changelog, but does not by itself establish remediation of every read path or approval-flow variant.

Anthropic’s case was more nuanced than a simple rejection.

Wiz Research reports that Anthropic’s initial response characterized the issue as outside its threat model, on the grounds that users already confirm whether they trust a directory when launching Claude Code there, and separately give explicit approval at the edit-confirmation prompt.

At the same time, Wiz notes that a symlink-warning feature had already shipped in version 2.1.32, nine days before the report was filed, and that versions 2.1.173 and later resolve symlinks and warn before writing to a sensitive target.

That sequence suggests a vendor’s classification of something as “not a vulnerability” and its decision to harden a product defensively are not necessarily the same judgment.

It also shows that vendors draw the line differently between what the product itself should prevent and what falls to the responsibility of a user who opened a trusted workspace.

Because tool versions and behavior continue to change, the current state of any tool in use is worth checking individually before making an adoption decision.

What It Takes for Approval to Function as a Security Control

The central lesson is that putting a human into an approval flow does not, by itself, create an effective safety control.

In some products, approvers were asked to sign off without knowing the real target of an operation. In others, processing happened before the approval screen appeared, or no screen appeared at all. The forms differed, but each involved a gap between a design that treats human judgment as a safety boundary and what the system actually did.

The issue is not that approvers were insufficiently careful. It is that the information needed to judge carefully was never delivered to the confirmation screen.

An approval step should not be treated as an end in itself. The basis for the decision—the real target, scope, and expected effect of the operation—must be visible and understandable to the approver.

This principle is not limited to file operations. In our own production work, when a person reviews output, we aim to give them not just the result but its sources, what changed, and what remains unverified.

The level of control appropriate for reviewing a draft and the level required at a filesystem security boundary are, of course, very different. The common principle is this: unless the approver is given the information needed to judge, adding a human to the process does not by itself make that step a meaningful check.

Four Questions to Audit Your Approval Flow

Wiz’s own recommendations point in a clear direction: resolve symlinks before displaying the confirmation prompt, explicitly warn when a resolved path falls outside the workspace, and never write to disk before explicit user approval.

Translated into questions an organization can put to whatever AI coding agent it uses:

1. Does the confirmation screen show the resolved target? The approver needs to see the real path after symlink resolution—not the apparent in-workspace name—and whether it falls outside the workspace.
2. Are operations outside the workspace, or on sensitive paths, distinguished from ordinary edits? These should be flagged or blocked distinctly rather than folded into a generic “editing a file” message.
3. Does any operation presented as approval-gated occur only after approval? An Accept/Reject or Undo button does not make a screen an authorization gate if the protected write already happened before that screen appeared.
4. If the user rejects the action, does the system leave the target unchanged and record that the operation was not executed? Relatedly, does the audit trail record the resolved target that was actually accessed, rather than the path that was displayed?

The first three follow directly from Wiz’s recommendations. The audit-trail point in the fourth extends the same principle into operational practice, and is our addition rather than part of Wiz’s guidance.

This is not a definitive standard, only a starting point. How far to take it, and how often to revisit it, depends on the sensitivity of the code involved and an organization’s security posture.

A reasonable first step is simply to check the tool version in use against the vendor’s latest security documentation. Testing a tool’s behavior directly is better done under security-team oversight, in an isolated environment with dummy targets, rather than against real sensitive files.

It is also worth not relying solely on a tool’s built-in warnings. Internal rules for handling external repositories—such as reviewing anything pulled in from outside in an isolated environment first—add a layer of protection that does not depend on any single vendor’s design decisions.

Conclusion

GhostApproval points to something broader than one vendor’s implementation mistake: a trust-boundary weakness that can recur across AI coding assistants.

The six products did not all fail in the same way. Some showed only a symlink’s apparent path on the confirmation screen. Others allowed writes before approval, or skipped the confirmation screen entirely.

The lesson is not that human-in-the-loop approval is fundamentally misguided. It is that human approval functions as a security control only when execution pauses before approval, the approver is shown the real target and impact of the operation, and the system carries out exactly what was authorized.

Human-in-the-loop is not simply about adding a person to a workflow. It is about giving that person the information and the authority to make a meaningful judgment.

As AI agents are given more autonomy and broader file-access permissions, the trust boundaries between the user, the agent, and the filesystem need to become more explicit, not less.

Sources and Verification

This article draws primarily on Wiz Research’s “GhostApproval: A Trust Boundary Gap in AI Coding Assistants,” published July 8, 2026. The information was reviewed as of August 11, 2026.

For Amazon Q Developer, we also reviewed AWS’s security bulletin covering language server vulnerabilities, dated June 23, 2026. The GhostApproval symlink-validation issue is CVE-2026-12958. The same bulletin also covers CVE-2026-12957, a separate trust-boundary enforcement issue involving project configuration files, which is not the vulnerability discussed here.

For Cursor, we reviewed the vendor advisory for CVE-2026-50549, which states that versions before 3.0 were affected and that the issue was fixed in version 3.0.

For Google Antigravity, Wiz Research reports that Google deployed a fix on May 22, 2026. Neither Wiz’s article nor the Google changelog reviewed for this article identifies a specific fixed version. Version 1.19.6 is listed by Wiz as an affected version. No CVE had been assigned at the time of publication.

For Augment, Wiz reports that writes followed symbolic links silently at the time of testing, with no Allow/Deny dialog and no Undo button. Augment’s release notes state that Auggie CLI 0.34.0, published July 30, 2026, added approval requirements for saving files to sensitive paths. The release note does not establish that all symlink-based read and write paths described by Wiz were remediated.

Devin’s official changelog states that Devin Local 3.6.27, published August 1, 2026, changed its local editing tools to refuse writes through symbolic links.

According to Wiz, Anthropic initially treated the report as outside its threat model. Wiz also reports that a symlink warning had shipped in version 2.1.32 before the report was filed, and that versions 2.1.173 and later resolve symlinks and warn before writing to sensitive targets.

MIF did not conduct independent penetration testing of these products, reproduce the reported vulnerabilities, or assess their impact in any specific deployment.

Severity ratings and the status reported on July 8 reflect Wiz Research’s assessments. Product behavior, available fixes, and vendor guidance may have changed since. Organizations should review the latest vendor security documentation for the exact product and version they use.