AIコーディングツールのサンドボックスは破らなくても抜けられちゃう…というお話This article explains how AI coding tools' sandbox environments can be escaped…

AI coding assistants increasingly run generated commands and scripts inside sandboxes, the isolated environments meant to keep an autonomous agent from touching files, networks, or system resources it should not. A recent discussion aimed at Cursor users argues that this protection can be weaker than it looks, because a sandbox does not need to be broken in the traditional sense to be circumvented. The distinction matters because many developers treat "runs in a sandbox" as a synonym for "safe to let the model act freely," and that assumption can quietly fail.

The core argument is that there is a difference between breaking out of a sandbox and slipping around it. Breaking out implies exploiting a vulnerability in the isolation layer itself, such as a container escape or a kernel bug. Getting around it, by contrast, means using capabilities the sandbox was configured to allow, or handing work off to a process that lives outside the sandbox boundary. In both cases the isolation technology may be functioning exactly as designed, yet the practical security guarantee still evaporates.

Several concrete patterns tend to fall into this category. If a sandbox permits outbound network access so that the agent can install dependencies or call APIs, that same channel can be used to send data out or to fetch and execute additional instructions. If the sandbox shares a directory with the host so that the model can edit a project, a written file such as a shell configuration, a Git hook, or a build script may later be executed by the host, outside the confined environment, when the developer runs an ordinary command. Configuration files that trigger automatic actions, task runners, and editor extensions all create similar bridges. The sandbox stays intact; the effect leaks across it through a legitimate-looking side door.

This framing connects to a broader concern in the AI coding space often described as prompt injection or indirect instruction. An agent that reads a repository, a web page, a dependency's README, or an issue comment can encounter text crafted to steer its behavior. If that text convinces the model to write a file, adjust a permitted setting, or run an allowed command with harmful arguments, the malicious outcome is achieved without any exploit against the sandbox. The isolation prevents certain direct actions but does not judge intent, which is why the article treats it as a blind spot rather than a bug.

The context here is a rapid shift toward more autonomous coding tools. Cursor, an editor built around AI assistance, along with agent-style features in tools such as Claude Code, GitHub Copilot's agent modes, and various open-source frameworks, increasingly let a model plan and execute multi-step tasks, including running terminal commands. To make this usable, vendors add approval prompts, allowlists of safe commands, and sandboxed execution. Underlying technologies vary, from operating-system container features and virtual machines to lighter mechanisms, and each offers a different balance between convenience and containment. A more permissive configuration is more useful day to day but widens the surface that can be leveraged indirectly.

For developers, the practical takeaway is that a sandbox is one layer, not a complete boundary, and its value depends heavily on what it is allowed to reach. Reducing network egress, limiting shared file paths, avoiding automatic execution of model-written configuration, and keeping human approval on commands that touch credentials or external systems all appear to narrow the gap. Reviewing generated changes before running them, rather than after, is likely to catch the file-based bridges described above. Treating any external content the agent ingests as untrusted input follows the same logic used against traditional injection attacks.

None of this means sandboxing is worthless; it remains a meaningful defense against many accidental and direct failures. The article's point is more specific, that the mental model of an impenetrable wall does not match how these systems behave in practice, and that the interesting risks often live in the allowed pathways rather than in a dramatic escape. As agentic coding tools mature, defenses will probably move toward tighter default permissions and clearer separation between what a model can propose and what it can execute, but for now the responsibility for that separation still rests substantially with the developer.