Pillar Security researchers disclosed on July 21, 2026, that AI coding agents from Cursor, OpenAI, Google, and Antigravity can be tricked into writing files that later trigger host-side code execution—without ever directly breaking the sandbox. Seven distinct attack chains exploit a universal architectural weakness: project files are treated as inert data, but modern IDEs and toolchains automatically act on them like trusted instructions.
The Invisible Handoff: How a Safe File Became a Malicious Command
The core of the attack isn't a traditional escape. The sandboxes function as advertised, blocking direct system calls, unauthorized network access, or writes outside the workspace. Instead, the researchers found that an agent can be manipulated—via hidden instructions in a README, a pull request description, a dependency's metadata, or even a web page fetched during troubleshooting—to create or modify a configuration file inside the allowed project directory. Minutes or hours later, a trusted host component like a Git hook, a Python extension, or a VS Code task runner reads that file and dutifully executes the embedded command, completely outside the sandbox's restrictions.
"The agent never needs permission to launch a host process," the Pillar Security report explains. "It only needs to alter a file that causes an already trusted host process to launch something later." The result is code execution under the developer's own credentials, often without any obvious alert.
Cursor absorbed three of the seven findings. The most critical, tracked as CVE-2026-48124, involved workspace hook configurations. Cursor supports Claude-style hooks for automating lifecycle events; if the AI writes a hook definition, the editor runs it unsandboxed. Another chain targeted Python virtual environment discovery: the agent could tamper with pyvenv.cfg or the interpreter path, and when Cursor's Python extension automatically detected the environment, it launched the attacker's binary. A third exploited a Git quirk: Git metadata need not reside in a literal .git folder; a .git file pointing elsewhere can redirect configuration, and a modified fsmonitor helper led to remote execution. These were fixed in Cursor 3.0.0, with a CVE still pending for the Git issue.
OpenAI Codex CLI was patched in version 0.95.0 after researchers showed its command allowlist approved git show because it was assumed to be read-only. In fact, crafted arguments could trigger external helpers and side effects. "The policy recognized a familiar command name rather than evaluating the complete invocation," the team noted.
Google Gemini CLI shared a Docker daemon access flaw with Cursor and Codex CLI: a sandboxed agent could reach a privileged Docker socket and request containers with host mounts, effectively escaping without breaking filesystem rules. Google also faced a .vscode task configuration bypass in its Antigravity tool. While Google acknowledged the findings, it assigned lower severity to some, citing the need for social engineering—a stance Pillar disputes because inspecting untrusted repositories is routine dev activity.
What It Means for You: From Individual Devs to Enterprise Orgs
For the individual developer, the risk is direct and personal. Your AI assistant can become an unwitting accomplice. Open a malicious repository, ask the agent to review a PR, or even research an error message, and it may silently plant a time bomb in your project's tasks.json, a Git hook, or a Python venv. Later, when you launch a build or debug session, your own editor executes the payload. Your source code, SSH keys, cloud tokens, and browser sessions are all reachable.
Windows users face a particularly broad attack surface. Beyond the Visual Studio Code and Git issues, Windows development environments bristle with automatic execution paths: MSBuild targets, NuGet package scripts, PowerShell profiles, Node .npmrc scripts, Dev Container definitions, and Docker Desktop integration. Windows also tends to search the current directory before system paths for executables—a project-local python.exe or git.exe could hijack trusted tool launches. Docker Desktop's API and named pipes offer further privileged conduits.
Enterprise security teams must treat AI coding tools as a supply-chain and endpoint-governance priority. A compromised dev machine can alter source code, approve changes, upload to artifact registries, and pivot to cloud infrastructure—all without local admin rights. Traditional endpoint detection struggles to flag these attacks because the execution chain looks normal: a Git helper spawns a process, or Python extension runs a venv interpreter. Without provenance showing that the agent authored the triggering file, it's invisible.
The Road to This Mess: Why Sandboxes Weren't Enough
Coding assistants evolved from autocomplete engines to autonomous agents that can run commands, edit files, and interact with external services. As a safety net, vendors bolted on sandboxes—containers, macOS Seatbelt profiles, command approvals—that limit what the agent's own process can do. This worked for direct attacks, but it missed a fundamental shift: the project directory is no longer just a bag of source code. It's a control surface.
For decades, developers have treated repos as executable configuration. package.json scripts, Makefile targets, .vscode/tasks.json, .git/hooks, docker-compose.yml, and countless others are instructions that the host toolchain executes without a second thought. Humans reviewed these files before they took effect. When an AI agent can produce them at machine speed in response to hidden prompts, the old trust model collapses.
The researchers call this a "trust handoff" failure. The sandbox trusts the workspace, and the host tools trust the workspace. The agent, though confined, can pollute that shared trust zone. "Isolation does not equal isolation of influence," the report states.
Adding to the blindness is the asynchronous nature of the attack. The malicious write might happen during a 2 a.m. batch task; the execution could occur days later when a teammate opens the project. This gap breaks the mental connection between the agent's action and the consequence, and it stymies incident response.
Patch Your Tools and Change Your Workflow: A Practical Checklist
The immediate patches are just the start. Here's how to protect yourself now:
- Update immediately: Cursor users must be on 3.0.0 or newer; Codex CLI users on 0.95.0 or newer. Check your version and apply the update before opening any unfamiliar project.
- Isolate untrusted repos: Use a disposable VM, not just a container. Containers often share the Docker socket, host volumes, or device access. In a VM, disable shared folders, clipboard integration, and credential forwarding.
- Scrutinize automation files: After an agent works on a repo, inspect every new or modified
.vscode/,.git,pyproject.toml,Makefile,Dockerfile,package.jsonscripts, and agent-specific configs. Don't trust the agent's own summary—look at the raw diff. - Disable Docker Desktop when you don't need it. If you must use it, run the agent in an environment that cannot reach the Docker API.
- Use short-lived credentials: Generate temporary tokens for cloud services and source control. Never let your primary keys touch a machine where an AI agent operates.
- Separate dev from production: Your daily workstation should not hold persistent admin access to critical infrastructure. Use just-in-time access and dedicated admin machines.
- Discard after use: For risky projects, delete the entire workspace and VM when finished. Delayed execution thrives on persistence.
- For enterprises: Catalog all AI coding tools in use, enforce approved versions, block agent access to privileged daemons (Docker, SSH agents, credential helpers), and centralize logs that include file provenance—not just process trees.
The Next Frontier: Agent-Aware Security
Fixing seven CVEs won't close the architectural gap. Every extension, interpreter, task runner, and build tool that blindly consumes project files is a potential stepping stone. The industry needs a new class of endpoint controls that monitor not just process launches, but the chain of trust: who created the file, what trusted component acted on it, and what context was lost in between.
Vendors should adopt deny-by-default sandbox policies, distinguish agent-generated files from human-authored ones with visible provenance, and trigger explicit approvals whenever an agent's output is about to cross into unsandboxed execution. "Version numbers matter, but transparent threat models matter more," the researchers conclude. "Buyers need to know what a product means by 'sandbox,' including every helper, extension, daemon, and automation system beyond the immediate agent process." Expect the coming months to bring architectural overhauls—not just patches—in how these tools manage trust.