Sandbox Configuration Escape: How AI Coding Agents Turn Their Own Execution Environment into Persistent, Trusted State

Sandbox configuration escape is SSA descriptive wording for a security-relevant write that an already-compromised agent session makes, from inside its own execution sandbox, to configuration, session hooks, or build-cache state that a host process or a later pipeline run treats as trusted. The defining consequence is that the write outlives the sandbox that produced it: the next launch, the next workflow run, or the next developer's session reloads that state and executes it with privilege the sandbox itself never granted.

What it is

The defining object is host-side or pipeline-side state that a sandboxed agent can write from inside its restricted environment, but that gets read and acted on outside that restriction: a settings file loaded at the next startup, a session hook fired before any user input is processed, or a build cache entry restored into the next workflow run. The defining cause is compromise that already occurred inside the sandbox, typically through prompt injection, untrusted repository content, or a compromised dependency the agent invoked. The defining consequence is privilege escalation through persistence rather than through a direct exploit: the attacker does not need to break out of the sandbox in the same session, only to leave something behind that a less-restricted process will trust later.

This differs from a one-off sandbox bug in scope. A pure code-execution bug inside a sandbox is contained by the sandbox boundary itself. Sandbox configuration escape specifically targets the files, hooks, and caches the sandbox's own design treats as legitimate inputs to the next session, so the escape does not require defeating the sandbox's isolation technology at all.

What it is not

A sandbox-escape technique that breaks isolation directly, such as a container kernel exploit, with no persistent write path involved.
Ordinary, user-approved configuration changes, including changes a user later regrets.
MCP tool poisoning, where a remote server changes a tool's definition after approval. That entry path never requires sandbox write access at all.
Instruction file poisoning, where the attacker's goal is changing what the agent believes or intends. This entry path targets what the agent, and the host process around it, is permitted to execute.
Reproducible exploit code, working payloads, or step-by-step bypass instructions for a specific product.

In scope

Configuration files an agent's sandbox can write that a host-side process loads and acts on at the next launch, without re-verifying that the write reflected the sandboxed session's actual intended settings.
Session-start or pre-flight hooks that fire before a new session has processed any trusted input.
CI and build caches that a workflow run can poison from inside a restricted job, for later, less-restricted, or higher-privilege jobs to consume.
Detection, containment, and design changes that reduce the gap between "the sandbox restricted this session" and "the sandbox's own outputs are trusted by the next one."

Target state and trust boundaries

The target state is host-side or pipeline-side configuration and cache state that sits just outside the sandbox boundary but is written from inside it. The relevant trust boundary is not the sandbox wall itself; it is the assumption, built into the surrounding system's design, that anything the sandbox is allowed to write is safe for a less-restricted process to read back unconditionally. A sandbox that mounts its own configuration directory as writable, so the agent can update its own settings across sessions, has moved the actual security boundary from "code cannot escape the container" to "the host correctly re-validates whatever the container wrote," and the second boundary is much easier to leave unguarded because it looks, from inside the sandbox's design, like ordinary state persistence rather than a privilege boundary.

What the research establishes

The clearest documented case is CVE-2026-25725 in Claude Code. Anthropic's bubblewrap sandbox mounted the project's parent directory as writable and explicitly protected `.claude/settings.local.json` with a read-only bind mount, but did not apply the same protection to `.claude/settings.json` when that file did not already exist at session start. Code running inside the sandbox, reached through prompt injection, untrusted repository content, or a compromised dependency, could create that file and inject a `SessionStart` hook. On the next launch, Claude Code loaded the file and ran the hook with the host user's full privileges, outside the sandbox that had restricted the session that wrote it. Anthropic patched the issue in version 2.1.2 (GitHub Advisory GHSA-ff64-7w26-62rf, CVE-2026-25725).

Security researchers at Cymulate documented the same vulnerability class, which they name Configuration-Based Sandbox Escape (CBSE), across three vendors' coding agents: Claude Code, Google's Gemini CLI, and OpenAI's Codex CLI. Their framing states the underlying design gap directly: "the sandbox is treated as the security boundary, while the real boundary, the host-side configuration and execution logic, remains writable from inside the sandbox." Reported findings included Gemini CLI mounting its configuration directory writable into the container alongside unsafe executable resolution on Windows, and Codex CLI's patch-apply tool creating a `.codex` directory without approval when one did not already exist. As of the researchers' reporting, the Gemini CLI finding remained unresolved past 90 days, and the Codex CLI finding was closed as informational rather than patched (Cymulate, The Race to Ship AI Tools Left Security Behind, Part 1: Sandbox Escape).

A separate, higher-impact case shows the same pattern extending past a single developer's machine into a shared build pipeline. Security researcher Adnan Khan documented Clinejection, an attack chain against Cline, an AI coding extension with a reported five million users. Cline had added an AI-powered issue-triage workflow that ran an agent with bash access against attacker-crafted GitHub issue titles. Khan used prompt injection against that triager to reach GitHub Actions cache poisoning: flooding the legitimate cache with junk data to trigger eviction, then inserting a poisoned entry under the same key using Cacheract, an open, proof-of-concept tool Khan had previously published for this technique (Cacheract: The Monster in Your Build Cache). The poisoned cache delivered a compromised `node_modules` tree into the project's nightly release workflow, positioning the attack to steal the production publication credentials used to sign and ship Cline's own extension to every one of its users. Cline fixed the reported vulnerability within an hour of public disclosure, removed the AI triage workflow, and rotated credentials, confirming no unauthorized release had shipped during the exposure window (Clinejection, Adnan Khan).

All three cases share a structure this article's scope is built around: a session that is supposed to be restricted, compromised through untrusted input the agent was designed to process, writes into state a later, less-restricted process trusts by default.

Persistence

A poisoned session hook or settings file persists until a human notices and removes it, and it re-executes with host privilege on every subsequent launch in the interim, which is a materially longer and higher-privilege exposure window than a single compromised turn. A poisoned CI or build cache entry persists until it is evicted or the cache key changes, and during that window it can reach every workflow run, and every downstream consumer of that pipeline's artifacts, that shares the same cache key, which is why the Clinejection case reached toward shared publication credentials rather than staying confined to one developer's machine.

Detection: observable signs

A configuration or hook file inside the agent's own settings directory was created or modified during a session, rather than by an explicit, user-initiated settings change.
A session-start or pre-flight hook fires and executes a command before the new session has processed any user input in that session.
A build or CI cache entry restored into a workflow does not match the size, hash, or contents expected for its cache key, or a cache entry exists for a key the current branch never legitimately populated.
An `actions/checkout` step, or an equivalent post-step in another CI system, performs file writes beyond what the checkout itself requires.
A host-side process loads a configuration file that did not exist, or had different contents, at the last point a human reviewed the environment.

Useful telemetry includes a diff between the sandbox's writable file set at session start and session end, a record of which files a host process reads on launch before any user input arrives, and cache-key-to-contents integrity records that a poisoned entry cannot also rewrite.

Defenses, containment, and recovery

The table below is SSA editorial guidance for defenders. It is neither a standard requirement nor a measured effectiveness ranking.

| Control | Transition it interrupts | Applicability | Residual risk and verification | | --- | --- | --- | --- | | Deny-by-default protection for not-yet-existing config files | A sandboxed session creating a trusted file that did not exist, rather than only protecting files already present | Any sandbox that mounts a configuration directory writable for legitimate settings persistence | A protection list enumerated by filename misses a rename or a new hook type; verify the boundary is "the directory," not "the files a developer thought to list." | | No-argument or pre-approved session-start hooks | An injected hook executing arbitrary commands before any trusted input reaches the new session | Agents that support automatic hooks or startup scripts | A hook mechanism with no execution step removes the entry path entirely; if hooks must run commands, require an explicit, out-of-band approval per command, not per session. | | Cache-entry integrity binding | A poisoned cache entry being restored and trusted under a legitimate key | CI and build pipelines that cache dependencies or build artifacts across runs | Binding a hash to a key stops silent substitution but not a legitimately-keyed poisoned entry from a compromised prior run; verify the source commit and workflow, not only the hash. | | Least-privilege separation between triage and release pipelines | A prompt-injectable, low-privilege workflow reaching credentials scoped to a high-privilege one | Any pipeline that lets an LLM-driven job read untrusted content, such as issues or PRs, with any path toward release credentials | Shared cache keys or shared runners can reconnect pipelines a permissions boundary formally separated; verify isolation at the infrastructure layer, not only the token scope. | | Session-boundary re-verification | A host process trusting sandbox output without confirming it reflects the session's actual, approved intent | Any system where a restricted session's output becomes another process's trusted input | Re-verification adds friction that teams may bypass under deadline pressure; measure whether the check actually blocks unreviewed changes rather than only logging them. |

Containment should treat any unexpected hook or cache-key contents as live until proven otherwise, disabling the affected launch path or workflow rather than deleting the evidence first. Recovery should rotate any credential the affected pipeline or session could have reached, rebuild caches from a known-clean source rather than trusting the most recent pre-incident entry, and re-audit every session or workflow run that executed between the suspected write and its discovery.

Boundaries with similar concepts

Sandbox configuration escape is a concrete, real-world instance of the mechanism the paper *Self-State Attacks on Self-Hosted AI Agents* describes analytically: a compromised agent issuing file-system writes against its own persistent configuration using the same operations and authorization it uses for legitimate self-updates, so that authorization alone cannot separate the attack from ordinary use (arXiv 2607.17986). This article's scope is narrower and product-specific; the paper's is the general analytical layer, discussed on the agent state attack definition page.

This differs from MCP tool poisoning in entry path: that surface targets a tool's definition as served by a remote party the agent already trusts, with no sandbox write access required at all. It differs from instruction file poisoning in target: that surface changes what the agent believes or intends by editing files like `CLAUDE.md` or `AGENTS.md`, while this surface changes what the agent, and the host process around it, is permitted to execute. A single incident can cross both: a poisoned instruction file could itself be the vehicle that first compromises the session that then writes a poisoned hook.

A CI or build cache read by multiple workflow runs, branches, or downstream consumers is also a boundary case with shared state poisoning: once the poisoned object is read by more than one pipeline or team, propagation tracing applies the same way it does for a shared blackboard or memory store.

Mapping to standards and research

| Source | Source-owned term or item | Relationship to this article | | --- | --- | --- | | GitHub Advisory Database | `CVE-2026-25725` / `GHSA-ff64-7w26-62rf` | Standard-identified vulnerability; direct evidence for the configuration-file entry path. | | Cymulate (2026) | Configuration-Based Sandbox Escape (CBSE) | Industry-coined term for the vulnerability class across three vendors; direct evidence this is a pattern, not one product's bug. | | Adnan Khan (2024, 2026) | Cacheract, Clinejection | Industry security research documenting the CI/build-cache instance of this pattern and its escalation to a supply-chain compromise attempt. | | OWASP Top 10 for Agentic Applications 2026 | `ASI04 Agentic Supply Chain Vulnerabilities`; `ASI05 Unexpected Code Execution (RCE)` | Broader risk categories this entry path falls under. | | MITRE ATLAS v2026.06 | `AML.T0081 Modify AI Agent Configuration` | Attacker-behavior classification matching the configuration-write mechanism described here. | | NVIDIA (2026) | Sandboxing guidance for agentic workflows | Vendor-neutral design guidance consistent with the containment and prevention controls above (NVIDIA Developer Blog). | | Agent State Attack | Sandbox configuration escape | SSA descriptive phrase, not attributed to the sources above. |

Related terms

Agent state attack: the umbrella definition, including the self-state attack disambiguation this article's case studies instantiate.
MCP tool poisoning: the adjacent Tool & Environment State surface for remotely-served tool definitions rather than sandbox-writable local state.
Instruction file poisoning: the adjacent surface targeting what the agent believes rather than what it and its host process are permitted to execute.
Shared state poisoning in multi-agent systems: the boundary case where a poisoned cache or configuration object is read by more than one pipeline, team, or agent.
Detecting agent state attacks: a cross-surface telemetry and signal model: the signal families this article's detection section draws from.

FAQ

Does this require a bug in the sandbox's isolation technology itself?

No. Every documented case here involved a sandbox that isolated the session correctly. The gap was in what the surrounding system trusted after the session ended, not in whether the container or restricted execution environment itself could be broken out of directly.

Is this the same as a supply-chain attack?

They overlap when the poisoned state is a build cache or CI artifact that reaches a release pipeline, as in the Clinejection case. They differ when the poisoned state is local, host-side configuration with no build or release pipeline involved, as in the CVE-2026-25725 and CBSE cases. Attribute the specific mechanism rather than treating every instance as a generic supply-chain incident.

Does disabling agent hooks and startup scripts eliminate the risk?

It removes the configuration-hook entry path specifically, at the cost of legitimate automation features that rely on it. The CI/build-cache entry path is separate and requires cache-integrity and pipeline-isolation controls regardless of whether any agent hook feature is enabled.

Is an unpatched finding in one vendor's product evidence the whole vendor category is unsafe?

No. Treat each finding as evidence of a recurring design pattern worth checking for, not as a blanket claim about a specific product's current state. Verify the patch status and mitigations for the exact version in use before drawing a conclusion about present risk.

Sources

Verification and change history

Standards and versions referenced: OWASP Top 10 for Agentic Applications, Version 2026 (December 2025); MITRE ATLAS, data release v2026.06 (2026-06-30); CVE-2026-25725 / GHSA-ff64-7w26-62rf.

Last verified: 2026-09-04. The CVE and advisory details, the Cymulate CBSE findings, and the Clinejection and Cacheract mechanics were read from the sources' own pages on this date. The OWASP and MITRE identifiers were reused from this site's previously verified crosswalk entries.

Change history: 2026-09-04, initial defensive draft. Not scheduled for publication.

Working-term label: **Mixed provenance.** `CVE-2026-25725` and its GitHub Security Advisory are Standard-identified. "CBSE" is an industry term coined by Cymulate's researchers. "Cacheract" and "Clinejection" are industry security-research terms owned by their author, Adnan Khan. `ASI04`, `ASI05`, and `AML.T0081` are Standard Terms owned by OWASP and MITRE. "Sandbox configuration escape" is SSA descriptive wording, not a standard term.