GhostApproval in coding agents is the warning that human approval is not enough when the diff shows one path and the system writes to another. The risk is not only bad agent judgment. It is the UI, the sandbox, and the canonical path the agent actually touches.

On July 8, 2026, Wiz published "GhostApproval: A Trust Boundary Gap in AI Coding Assistants." The research reported variations of the pattern in 6 assistants: Amazon Q Developer, Claude Code, Augment, Cursor, Google Antigravity, and Windsurf (Wiz, "GhostApproval: A Trust Boundary Gap in AI Coding Assistants", 2026). If you use Codex, Claude Code, or CI agents, resolve symlinks before trusting the prompt.

Practical summary

  • GhostApproval replaces "approve the diff" with "trust the canonical path."
  • A symlink inside the repo can point to a sensitive file outside the workspace.
  • Sandbox, permissions, and MCP must validate the real target, not only the apparent path.
  • CI should record suspicious symlinks before accepting an agentic PR.

Abstract diagram shows diverging paths between a workspace and a real target with no visible text.

What did GhostApproval actually break?

In 2026, Wiz reported GhostApproval in 6 coding assistants and said 3 vendors fixed the issue promptly: AWS, Cursor, and Google (Wiz, "GhostApproval: A Trust Boundary Gap in AI Coding Assistants", 2026). The pattern breaks trust between the path shown to the user and the file that receives the write.

The attack uses an old idea: a file inside the workspace is really a symlink outside it. The agent reads instructions, decides to edit the apparent file, and the execution layer follows the link to a sensitive target, such as a shell config or an access key.

The dangerous gap is between "the user approved" and "the user understood the real target." If the screen shows a harmless local file, but the write lands outside the workspace, approval becomes a ceremony. It exists formally, but it does not communicate risk.

This complements repository quarantine for coding agents. Quarantine decides when an unknown repo may execute. GhostApproval decides whether an already authorized write still respects the workspace boundary.

Citable capsule: GhostApproval is not just a symlink bug. It is a boundary failure in coding agents: the user approves an apparent path, while the runtime may write to the resolved target outside the workspace. The fix must combine UI, sandbox, and canonical resolution.

Why is human approval not enough when the path is false?

In 2026, MITRE describes CWE-451 as a UI that fails to represent critical information properly, allowing source or content to be obscured or spoofed (MITRE, "CWE-451", 2026). In GhostApproval, the approval prompt fails there: it does not show the real write target.

Wiz frames this as a failure of informed consent. The human stays in the loop, but the loop does not provide the information needed to decide. In cases described by the research, the agent internally recognized the risky target while the interface showed only the benign file name.

For engineering teams, that changes review. "The agent asked for approval" is no longer enough evidence. Useful evidence is different: apparent path, resolved path, intended operation, applied permission, and sandbox scope.

It also changes how teams should think about automatic modes. In March 2026, Anthropic wrote that Claude Code users approved 93% of permission prompts and that auto mode was designed to reduce approval fatigue (Anthropic, "How we built Claude Code auto mode", 2026). If almost everything is accepted, the prompt must become more trustworthy, not only more frequent.

Citable capsule: Human approval only protects coding agents when the prompt shows the true target. MITRE classifies obscured critical UI information as CWE-451; GhostApproval applies that weakness to agentic diffs, where an apparent path can hide the resolved file.

In 2026, MITRE defines CWE-61 as failure to account for a file resolving through a symlink outside the intended control sphere (MITRE, "CWE-61", 2026). The correct audit resolves the path before the write and blocks when the target leaves the authorized workspace.

Start with inventory. Before letting the agent edit, ask for or run a symbolic-link check in the repo. The goal is not to ban every symlink. It is to separate expected symlinks, such as cache or worktree links, from links that point to home, .ssh, agent configuration, credentials, or system directories.

On Linux and macOS, a minimal check compares the link path with the real target. For human review, the key is seeing the full resolution before the diff:

find . -type l -print0 | while IFS= read -r -d '' link; do
  printf '%s -> %s\n' "$link" "$(realpath "$link")"
done

Then apply policy. Links that resolve outside the repo enter quarantine. Links that resolve to ~/.ssh, shell files, IDE configuration, cloud keys, or agent settings should block automatic writes. If the case is legitimate, it needs an explicit justification.

Abstract flow shows validation between apparent path and real path with no visible text.

Practical experience: I treat symlinks as input data, not filesystem trivia. In an unknown repo, the agent may suggest that it is "just adjusting configuration." Before the edit, I want the resolved target and the reason that link exists.

Citable capsule: Defense against GhostApproval starts with canonical path resolution. CWE-61 describes the risk of operating on a file that resolves outside the intended sphere; in coding agents, the diff should show both the link and the real target before approval.

How should Codex, Claude Code, and MCP be adjusted?

In 2026, Codex documentation says the agent runs with network access off by default and local writes limited to the workspace (OpenAI Developers, "Agent approvals & security", 2026). In modes such as workspace-write with on-request, that boundary must include the resolved path, not only the text prefix.

In Codex, avoid danger-full-access in a repo that has not passed a symlink inventory. If a task needs a write outside the workspace, use a narrow and reviewable exception. Codex documentation distinguishes full access from workspace-write with on-request approval (OpenAI Developers, "Sandbox", 2026).

In Claude Code, use permissions and sandboxing together. The permissions documentation says symlink rules check two paths: the link and the resolved target (Claude Code Docs, "Configure permissions", 2026). Allow rules pass only when both match. Deny rules block if either matches.

For long runs, I use RemoteCode to save context in agentic Codex and Claude Code sessions. It helps when triage needs to cross inventory, logs, permissions, and history without repeating everything in the main prompt. It is my own tool, so this is an editorial mention tied to real context cost in security loops.

For MCP, the rule is stricter: deny by default until the repo passes triage. Claude Code documentation allows denying every MCP tool with mcp__* and releasing a specific server later (Claude Code Docs, "Configure permissions", 2026). That keeps a local write from becoming a side effect in GitHub, a browser, cloud, or a ticket system.

Citable capsule: After GhostApproval, an agent sandbox must validate the canonical path. Codex documents network off and workspace-limited writes by default; Claude Code documents symlink checks across both link and target. MCP should start denied and be released per server.

Where should CI enter this defense?

In May 2026, GitHub said Copilot code review had processed more than 60 million reviews (GitHub Blog, "Agent pull requests are everywhere", 2026). The same source says more than one in five reviews on GitHub involved an agent. At that volume, symlink review needs to be automated.

CI does not replace local sandboxing. It arrives too late to protect the developer machine. Still, it protects the shared repository and creates evidence for PR review. The check should fail when a PR adds a symlink to a target outside allowed directories.

A simple rule works: list every new or changed symlink, resolve its target, and publish the result as a review artifact. If any target leaves the repo, the PR needs security approval. If it touches home, secrets, agent configuration, or startup files, block it.

This control pairs with PR evals for agents in CI and hooks that stop coding agents. The difference is that symlink checking does not measure code quality. It measures whether the diff represents the real write.

Citable capsule: CI should treat a symlink as a boundary change, not file trivia. GitHub reports tens of millions of agent reviews; at that volume, every agentic PR needs to expose symbolic link, resolved target, and blocking decision before merge.

What checklist should you use on the next repo?

In 2025, the Stack Overflow Developer Survey said 84% of respondents were using or planning to use AI tools in development (Stack Overflow, "2025 Developer Survey: AI", 2025). The same survey showed 51% of professionals using them daily. In 2026, Stack Overflow reported daily AI use at work at 58% (Stack Overflow Blog, "Domain expertise still wanted", 2026). That scale needs a repeatable checklist.

Use this flow before accepting an agent edit in an unknown repo or agent-generated PR:

  • List symlinks and record each resolved target.
  • Block automatic writes if the target leaves the workspace.
  • Deny any target in home, .ssh, shell, credentials, IDE, .git, .claude, or MCP.
  • Show the apparent path and canonical path in the approval prompt.
  • Run the agent with network off until triage finishes.
  • Keep MCP denied until each server has a reason to exist.
  • Fail CI when a new symlink points outside the repo.
  • Require specific human review for documented exceptions.
PR signal Practical decision
Symlink points inside the repo and has a clear reason Allow it with normal diff review.
Symlink points outside the workspace Block automatic writes and require security approval.
Symlink touches shell, SSH, credential, .git, .claude, or IDE files Block the PR until the target is removed or justified.
Agent requests MCP before triage Deny the tool and record the real need.

Abstract checklist shows validation steps for coding agents with no visible text.

The common mistake is thinking "we do not use Windsurf" or "we do not use Amazon Q" solves it. GhostApproval is a design class. The right question is: does your tool show the real target before writing, and does your environment block when that target crosses the boundary?

Citable capsule: The minimum GhostApproval checklist combines symlink inventory, canonical resolution, out-of-workspace blocking, MCP denied by default, and explicit CI failure. Daily AI adoption among developers makes this an operational control, not an optional hardening idea.

Frequently asked questions

Does GhostApproval affect only Claude Code?

No. In 2026, Wiz reported variations in 6 coding assistants: Amazon Q Developer, Claude Code, Augment, Cursor, Google Antigravity, and Windsurf (Wiz, "GhostApproval: A Trust Boundary Gap in AI Coding Assistants"). The practical point is to audit your current tool, because the flaw sits between UI, symlink, and runtime.

Does updating the tool solve everything?

Not by itself. In 2026, AWS published CVE-2026-12958 and fixed the issue in Language Servers for AWS 1.69.0 (AWS Security Bulletin 2026-047-AWS). Updating reduces product risk, but your workflow still needs symlink resolution, workspace limits, MCP review, and CI blocking.

Which file is most dangerous in this attack?

There is no single file. In 2026, NVD described CVE-2026-12958 as arbitrary write outside the workspace boundary through a malicious symlink (NVD, "CVE-2026-12958"). In practice, treat shell files, SSH keys, credentials, agent settings, Git hooks, and IDE files as sensitive.

Yes, with policy. In 2026, Claude Code documentation says allow rules for symlinks require both the link and target to match, while deny blocks if either matches (Claude Code Docs, "Configure permissions"). A monorepo can use legitimate symlinks, but it needs canonical target and reason.

Sources

  • Wiz, "GhostApproval: A Trust Boundary Gap in AI Coding Assistants", retrieved 2026-07-11, https://www.wiz.io/blog/ghostapproval-a-trust-boundary-gap-in-ai-coding-assistants
  • AWS, "CVE-2026-12957 and CVE-2026-12958 - Issues in Language Servers for AWS and Amazon Q Developer Plugins", retrieved 2026-07-11, https://aws.amazon.com/security/security-bulletins/2026-047-aws/
  • GitHub Advisory Database, "Arbitrary file write in Language Servers for AWS", retrieved 2026-07-11, https://github.com/aws/language-servers/security/advisories/GHSA-6v3r-4p5c-mrp5
  • NVD, "CVE-2026-12958", retrieved 2026-07-11, https://nvd.nist.gov/vuln/detail/CVE-2026-12958
  • MITRE, "CWE-61: UNIX Symbolic Link (Symlink) Following", retrieved 2026-07-11, https://cwe.mitre.org/data/definitions/61.html
  • MITRE, "CWE-451: User Interface (UI) Misrepresentation of Critical Information", retrieved 2026-07-11, https://cwe.mitre.org/data/definitions/451.html
  • OpenAI Developers, "Agent approvals & security", retrieved 2026-07-11, https://developers.openai.com/codex/agent-approvals-security
  • OpenAI Developers, "Sandbox", retrieved 2026-07-11, https://developers.openai.com/codex/concepts/sandboxing
  • Claude Code Docs, "Configure permissions", retrieved 2026-07-11, https://code.claude.com/docs/en/permissions
  • Anthropic, "How we built Claude Code auto mode", retrieved 2026-07-11, https://www.anthropic.com/engineering/claude-code-auto-mode
  • GitHub Blog, "Agent pull requests are everywhere. Here's how to review them", retrieved 2026-07-11, https://github.blog/ai-and-ml/generative-ai/agent-pull-requests-are-everywhere-heres-how-to-review-them/
  • Stack Overflow, "2025 Developer Survey: AI", retrieved 2026-07-11, https://survey.stackoverflow.co/2025/ai
  • Stack Overflow Blog, "Domain expertise still wanted: the latest trends in AI-assisted knowledge for developers", retrieved 2026-07-11, https://stackoverflow.blog/2026/03/16/domain-expertise-still-wanted-the-latest-trends-in-ai/