What makes a coding agent safe enough to run on a real repository?
A coding agent is a program with a powerful interface. It reads files, runs commands, and may reach external systems on your behalf. The model choosing what to do is only one part of the safety design. OpenAI’s guidance on running Codex safely describes sandbox boundaries, an approval policy, network controls and agent-aware telemetry as separate controls that work together, not one setting that makes an agent trustworthy.
This article uses OpenAI’s public product documentation as a reference point; its two source pages were not independently re-fetched during this review, blocked by a Cloudflare challenge on every attempt on 22 September 2026. It does not report an independent security audit of any product.
The model is only one part of the safety design
It’s tempting to treat “is the model good” as the whole safety question. It isn’t. A capable model given unrestricted file access, network access and command execution is dangerous regardless of how well it reasons, because the danger lives in what the surrounding environment lets it do, not only in what it decides to do. The useful mental model is a small operating environment around the model: which paths are writable, whether the network is reachable at all, which domains are allowed if it is, which commands require a human approval, and where the resulting logs go.
A small operating environment
Make the default boring. A routine test run should not need a fresh permission grant every time it happens, or people stop reading the prompts. A deployment step or a credential access should feel visibly different from a routine command, and it should leave a record that survives the session. OpenAI’s Codex upgrades describe sandbox defaults, network limits and a human-verification step as parts of this same design, which matches the general pattern: sandboxing, approvals and network restriction working as layers.
A permission prompt is a product decision
This changes how you should think about product design, not only security configuration. A permission prompt is the moment the system explains a specific risk and asks for a specific decision. If every action produces the same vague “allow this agent to continue?” prompt, people learn to click through without reading, and the prompt stops doing its job. The boundary needs to be narrow enough that a person can actually understand what they are being asked to allow, and different enough between a safe action and a risky one that the difference registers.
Working inside a narrow boundary
The most capable agent, in the sense that matters for running it on a real repository, can make useful progress inside a clear, narrow boundary and show exactly where that boundary shaped the result. Ask the agent to record blocked actions alongside its diff and test results, so a reviewer can see where the boundary affected the work.
Follow the English RSS feed for the next article.
About the author: see my portfolio and my agency, Bimbi Digital.