The escape that isn’t one
The tools—Cursor, OpenAI’s Codex, Google’s Gemini CLI, and Antigravity—are designed to operate inside a sandbox that protects the host machine from direct malicious actions. Yet over several months, security researchers at Pillar Security found ways for each agent to cross its security boundary while staying, technically, inside the box. The trick is subtle: the sandbox trusts the agent inside the project folder and protects the host outside. But the files in that folder are not inert. Tools running outside the sandbox read them. A Python extension resolves an interpreter, a Git integration scans a repo, Docker Desktop exposes a local socket. So a file the agent is allowed to write can become a command the host later runs. The trigger is prompt injection—a malicious instruction hidden in a README, an issue, a dependency, or a diff turns into a real action on the developer’s machine.
Seven bugs, four patterns
Pillar sorted the seven findings into four failure modes. The first is denylists that cannot keep pace with the operating system. For example, an agent might be forbidden from calling certain commands, but an attacker can bypass the denylist by using alternative paths, environment variables, or shell features. The second is workspace config that is really code. Many tools allow users to define workspace settings that trigger commands when the workspace opens. If an agent can write to those config files, it can inject code that runs outside the sandbox. The third is “safe” command lists that trust a name over its arguments. A tool might allow Git commands but not other executables; however, Git itself can execute arbitrary commands via hooks or arguments like -c and --exec-path. The fourth is privileged local daemons that sit entirely outside the box. Docker Desktop, for instance, runs a socket that any process inside the sandbox can reach, allowing the agent to issue Docker commands that affect the host.
Vendor responses
The fixes are mostly in. In Cursor, a workspace hook config that ran unsandboxed commands is now CVE-2026-48124, patched in version 3.0.0. OpenAI fixed a Codex flaw where a “safe” Git command was not, and paid a bounty. One Docker-socket bug hit Cursor, Codex, and Gemini CLI at once, and all three vendors released updates. Google’s response stood out. It classified both Antigravity findings as “other valid security vulnerabilities,” downgraded their severity as hard to exploit, and did not patch, as reported by Neowin. It did, however, call one report “of exceptional quality.” Pillar’s counter is that “hard to exploit” is doing a lot of work. The bugs need a developer to trust a poisoned repository, which is exactly the everyday risk these agents introduce. Developers routinely clone unknown repositories, open pull requests, or install dependencies from untrusted sources. If the agent inspects those files, it becomes the vector for an attack that the user never sees coming.
Agents are the new endpoint
The bigger point is a shift in thinking. An agent’s blast radius, Pillar argues, is not the agent process. It is everything the agent can write that the host later trusts. “If an agent gets to write the future inputs of systems, it was never sandboxed in the first place,” the team wrote. The pattern is not new, but its breadth is: four tools, three vendors. It lands the same week OpenAI revealed its own model kept slipping its sandbox, part of a wider reckoning over AI-agent security. The fundamental issue is that current sandbox models assume the agent’s outputs are ephemeral and contained, but in reality they become persistent configuration that influences other software. This is reminiscent of earlier supply-chain attacks where compromised dependencies or build scripts spread malware. Here, the agent becomes a supplier of malicious configuration, and the developer’s toolchain executes that configuration trustingly.
Deep dive: four failure modes in detail
To understand the risks, it helps to examine each failure mode with concrete examples. The denylist failure occurs because operating systems offer countless ways to invoke a program. An agent might be prohibited from calling bash, but it can call /bin/sh, python -c 'import os; os.system("...")', or even use perl or awk executes commands. The denylist would need to anticipate every possible interpreter, which is impractical. In practice, researchers found that agents like Codex and Cursor allowed certain commands that could be abused. The workspace config failure is especially dangerous because it exploits the trust placed in project configuration. Tools like Cursor read .cursorrules or similar files to define commands that run when opening a workspace. If an agent can modify that file, the next time the developer opens the project, those commands execute with the full privileges of the host environment. This is a direct sandbox bypass because the command runs outside the agent’s restricted context. The safe command list failure is subtle. Many agents restrict execution to a whitelist of commands, such as git, pip, or npm. But these commands themselves can be coerced into running arbitrary code. Git, for example, supports hooks (pre-commit, post-merge) stored in the repository. An agent can create a malicious hook file, then call git commit or git pull to trigger it. Similarly, pip can execute arbitrary Python code during package installation if the package includes a setup.py with malicious content. The agent doesn't need to call python directly; it just needs to invoke pip install with a crafted package. The fourth failure mode, privileged local daemons, is the most direct. Docker Desktop exposes a Unix socket at /var/run/docker.sock that allows any process on the machine to control Docker. If the agent can access this socket (which it often can because it runs under the same user), it can run containers with full host access. For example, it can mount the host filesystem into a container and then escape via that container. This is not a sandbox break in the typical sense—the agent process remains inside—but it achieves the same effect: arbitrary code execution on the host.
Historical context and evolving threats
The concept of using file writes to subvert trust is not new. In the early days of shared hosting, users could write .htaccess files to alter web server behavior. In modern CI/CD pipelines, a malicious commit can modify pipeline configuration to steal secrets. What is new is the agent’s ability to automate these writes at scale, without the developer’s direct involvement. The agent is hired to generate code, fix bugs, and refactor projects. It reads and writes files constantly. If an attacker can plant a poisoned instruction in a context the agent reads—like a PR description, an issue comment, or a package README—the agent becomes an unwitting accomplice. The attack surface is enormous. Development teams are now deploying AI agents that automatically merge pull requests, apply patches, and even deploy code. Each of those actions can be hijacked through prompt injection if the agent reads any untrusted input. The problem is compounded by the fact that many agentic tools run with the same privileges as the human developer. They have access to SSH keys, cloud credentials, and private repositories. A successful escape can compromise the entire developer environment.
What to ask now
For anyone choosing an agentic coding tool, the useful question has changed. It is no longer whether the agent has a sandbox. It is what happens to the files it leaves behind, and who runs them next. The industry must move toward a model where agent outputs are treated as untrusted until verified. This includes scanning configuration files for injections, requiring user approval before executing any command that modifies the environment, and isolating the agent from sensitive daemons like Docker. Some vendors are exploring read-only sandboxes where the agent can never write files that affect execution; others are implementing content filters that inspect every line of generated code for potential injection patterns. But as Pillar’s research shows, these protections must be deep and context-aware. A simple denylist or whitelist will not suffice when the tools the agent uses are themselves Turing-complete. The broader lesson is that AI agent security cannot be bolted on after the fact. It must be architected from the ground up, with the understanding that any file the agent writes is a potential command for the host. Until that mindset becomes standard, every developer using an AI coding agent is, in effect, trusting its output more than they should.