---
schema_version: "newruntime-agent-readable-v0.1"
type: "post"
slug: "pillar-sandbox-escapes"
title: "Coding Agent Sandboxes Break in Places Teams Do Not Expect"
description: "Pillar shows that agent sandboxes must be assessed not only around the agent process, but around files, configs, allowlisted commands, and local daemons the host later trusts."
status: "published"
published_at: "2026-07-21"
topics: ["agent-security","coding-agents","sandbox"]
source_urls: ["https://www.pillar.security/blog/the-week-of-sandbox-escapes"]
routes: {"html":"https://newruntime.com/posts/pillar-sandbox-escapes/","markdown":"https://newruntime.com/posts/pillar-sandbox-escapes.md","json":"https://newruntime.com/posts/pillar-sandbox-escapes.json"}
source_format: "markdown"
---

# Coding Agent Sandboxes Break in Places Teams Do Not Expect

Pillar Security collected a series of sandbox escapes around coding agents: Cursor, Codex, Gemini CLI, and Antigravity. The point is not that sandboxes are useless. It is that the boundary often sits somewhere other than the product diagram suggests.

The agent may not execute a forbidden command directly. It only needs to write a file that a trusted component outside the sandbox will later read and execute: an IDE extension, task runner, Git helper, hook, Python discovery mechanism, Docker daemon, or another local service.

## What changes

The old question was: can the agent process escape the workspace?

The harder question is: what can the agent write, and which non-sandboxed parts of the system will later trust that data?

That makes an agentic IDE more than an editor extension. It is an endpoint actor. Security teams must track provenance, side effects, command arguments, local daemons, and host-side automation, not only a list of forbidden paths.

## New Runtime Read

An agent sandbox must model the whole trust chain: model output -> file write -> host component -> execution. If controls see only the first process, they miss half the attack.