GhostApproval: The AI Coding Agent Attack Hiding Behind an 'Approve' Button

TL;DR: GhostApproval is a newly disclosed attack pattern affecting AI coding assistants. A malicious repository disguises a symbolic link as an ordinary project file. The agent asks permission to edit that harmless-looking path, but the write can land in a sensitive file outside the workspace. The safest response is to update your tools, isolate untrusted repositories, inspect symlinks, and treat approval dialogs as context—not proof of safety.

The approval prompt that does not tell the whole truth

AI coding agents have become useful because they can do more than suggest a line of code. They read repositories, edit files, run terminal commands, install dependencies, and sometimes deploy the result.

That also means the security boundary has moved. The question is no longer only, “Is the generated code secure?” It is also, “Can the agent be tricked into acting outside the project I gave it?”

On July 8, 2026, Wiz publicly disclosed GhostApproval, a category-level weakness it found across six AI coding tools: Amazon Q Developer, Claude Code, Augment, Cursor, Google Antigravity, and Windsurf. The research combines two old ideas—malicious project instructions and symbolic links—with a very modern failure: an approval interface that shows the user one path while the operating system writes to another. Wiz’s GhostApproval research

There is no public evidence that the specific proof of concept has been exploited in the wild. But the design flaw matters now because coding agents increasingly operate with the same filesystem access as the developer using them.

GhostApproval in plain English

A symbolic link, or symlink, is a filesystem object that points to another file. It is useful for sharing configuration or connecting directories. But software must resolve the link’s real destination before deciding whether an operation is safe.

Imagine a cloned repository containing this file:

project_settings.json -> ~/.ssh/authorized_keys

Inside the repository, project_settings.json looks like a normal project configuration file. In reality, it points to the file that controls which SSH keys can log in to the developer’s machine.

The repository’s README then tells the coding agent to “finish setup” by adding one line to project_settings.json. If the agent follows the instruction and the tool validates only the visible project path, the write crosses the workspace boundary and reaches ~/.ssh/authorized_keys.

The same primitive can target shell startup files such as ~/.zshrc, tool configuration, cloud credentials, or other files the developer account can access. The agent does not need administrator privileges; it inherits the user’s existing permissions.

The attack chain

1. A developer clones or opens an untrusted repository.
2. A project file is actually a symlink to a sensitive location outside the workspace.
3. Repository instructions persuade the AI agent to edit the apparent local file.
4. The agent or its sandbox checks the displayed path instead of the resolved, canonical destination.
5. The user sees an innocent-looking approval—or, in some tools, the write happens before approval.
6. The sensitive target is modified under the developer’s permissions.

The dangerous part is not that symlinks exist. It is the mismatch between what the user believes they approved and what the system actually does.

Why “human in the loop” failed

Approval prompts are often treated as the final safety barrier for agentic tools. GhostApproval shows that a human can technically be in the loop while still lacking the information needed to make a safe decision.

Wiz reported cases where the agent’s reasoning recognized that the apparent project file pointed to a sensitive target, yet the confirmation shown to the developer named only the harmless path. In other products, changes were written to disk before the Accept or Reject interface appeared, turning “approval” into an undo button.

This creates three distinct failures:

• Path confusion: the interface displays the symlink rather than its canonical destination.
• Boundary failure: the sandbox allows a write that resolves outside the workspace.
• Timing failure: the product performs the action before the user authorizes it.

A meaningful approval must show the real destination, explain that the operation crosses a trust boundary, and block the write until consent is given. Anything less encourages approval fatigue without providing informed consent.

Which tools were affected?

The status was not identical across all six products when the research was published:

AWS assigned the issue CVE-2026-12958 with a CVSS 4.0 score of 8.5 and recommends upgrading Amazon Q Developer plugins to versions that include Language Server 1.69.0. AWS security advisory

Cursor’s related advisory, CVE-2026-50549, is rated critical, affects versions before 3.0, and describes arbitrary writes outside the workspace when path canonicalization fails. Cursor security advisory

Because product status can change quickly, the practical rule is simple: check the vendor’s current release notes and run the latest stable version before opening an unfamiliar repository with an agent.

What developers should do today

1. Update every AI coding tool

Do not update only the editor shell. Extensions, language servers, CLI agents, and companion processes may have separate versions. Restart the IDE after updating so the patched component is actually loaded.

2. Inspect symlinks before asking an agent to “set up” a repo

On macOS or Linux, review links inside an unfamiliar project before granting trust:

find . -type l -exec ls -la {} \;

For a specific file, inspect its resolved destination:

readlink project_settings.json

A link pointing outside the repository deserves investigation, especially when it targets shell files, SSH configuration, credentials, editor settings, or agent configuration.

3. Run untrusted repositories in an isolated environment

A container, disposable virtual machine, remote development environment, or tightly scoped sandbox reduces the value of the developer account that an agent can inherit. Isolation should cover filesystem writes, network access, credentials, and environment variables—not only terminal commands.

4. Keep secrets out of the agent’s reach

Use short-lived, least-privilege credentials. Avoid opening an untrusted project in the same environment that holds production cloud keys, signing credentials, or unrestricted SSH identities. If a suspicious agent session may have touched those files, rotate the credentials; deleting a changed file is not enough.

5. Treat project instructions as untrusted input

README files, issue descriptions, agent rules, MCP responses, generated error messages, and hidden configuration can all steer an agent. Review them before delegating broad tasks such as “follow all setup instructions” or “fix everything and run it.”

6. Review both code and agent behavior

Static code scanning remains essential for catching vulnerabilities introduced into the application. But GhostApproval happens at the agent-runtime layer, so code review alone cannot see the whole attack. Pair code scanning with sandbox boundaries, filesystem monitoring, command logs, and explicit approval for sensitive operations.

What AI coding tool makers need to change

The technical fixes are straightforward to describe, even if they are harder to implement consistently:

• Resolve and validate the canonical path immediately before every read or write.
• Block operations when canonicalization fails instead of falling back to the original path.
• Display both the requested path and the true destination.
• Make writes outside the workspace a distinct, high-risk approval class.
• Never write first and ask later.
• Test symlinks, mount points, case differences, and time-of-check/time-of-use races as part of the sandbox threat model.
• Preserve an audit trail linking user intent, agent reasoning, approvals, and filesystem effects.

OpenAI describes a similar defense-in-depth model for Codex: sandbox boundaries, approval policies, constrained network access, scoped identity and credentials, managed rules, and agent-aware telemetry are designed to work together rather than rely on a single dialog. Running Codex safely at OpenAI

The bigger lesson: an agent is a privileged software actor

GhostApproval fits the same category as prompt injection, poisoned repository instructions, unsafe MCP tools, and supply-chain attacks. The common mistake is treating the AI assistant as a smarter autocomplete feature when it is actually a software actor with access to files, commands, tokens, and networks.

That changes the threat model:

• A repository is both code and a source of instructions.
• An approval is safe only when the interface represents the real effect.
• A workspace boundary is real only when the operating system enforces it.
• A generated diff is only one part of the agent’s activity.

AI coding is not becoming less useful. It is becoming powerful enough that its control plane deserves the same scrutiny as CI/CD, cloud IAM, and production automation.

The uncomfortable lesson from GhostApproval is simple: “I clicked Approve” does not mean “I approved what actually happened.”

Vexlint helps developers inspect AI-generated application code for security issues. Runtime controls such as sandboxing, least-privilege credentials, and agent activity monitoring remain essential companions to code scanning.