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 when agent sandboxes meet host trust?
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.
The evidence set spans 4 agent products and the same structural problem: data written inside one boundary can become executable behavior in another boundary.
What should security teams model?
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.