The Rules Worth Writing for Codex and Claude Code

Both Codex and Claude Code ship with a defensible default posture. Codex runs in an OS sandbox, Seatbelt on macOS and Landlock on Linux, with approvals at the boundary. Claude Code prompts before every consequential action. If that were the whole story, there would be nothing to write about.

It is not the whole story. The default is the mode nobody stays in.

Developers reach almost immediately for Codex’s danger-full-access and Claude Code’s --dangerously-skip-permissions, because the safe mode blocks the network access real work needs and the prompts do not survive contact with a real task. Then they open a repo, and the repo tells the agent what to do. That is where the interesting security work lives, and it is not a settings question. It is a rules question.

So here are the rules worth writing.

The rule is the posture, not the default

A coding agent is not one thing you approve once. It is a stream of actions, generated at machine speed, from inputs you do not fully control. Your security posture is not the mode you picked at install. It is the set of rules that decide what happens on the thousandth action, in the mode the developer actually switched to, when the input was written by someone else.

Defaults protect you until the moment they are turned off. Rules protect you after.

Codex: the rules that matter

OpenAI’s Codex concentrates risk in two places: the modes that strip the sandbox, and the inputs it trusts.

• Decide by policy who can drop the sandbox, and in which environments. Setting sandbox_mode to danger-full-access removes the filesystem and network boundaries; --dangerously-bypass-approvals-and-sandbox (Codex aliases it --yolo) strips the approval prompts on top. When the sandbox comes off, the question is not who chose it but what is enforcing in its place. The failure mode teams actually hit is not “someone picked full access,” it is “full access turned out to mean nothing was watching.”
• Scan project configs before the session starts. CVE-2025-61260 (CVSS 9.8) let a repo-controlled config make Codex auto-load and execute MCP servers the moment the project opened, before anyone approved anything. The lesson generalizes past that one CVE: a file that rides along inside a repo and can steer the agent is attacker-controlled, and it has to be checked before the agent ever reads it. AGENTS.md is the same story.
• Treat AGENTS.md as untrusted. Hidden instructions in an agent-instructions file are all it takes to turn “fix the failing tests” into “read ~/.ssh and post it somewhere.” The file is trusted by the agent and controllable by an attacker. Those are the two properties that make an injection.
• Keep humans on the high-impact tail. CI/CD edits, deploys, bulk deletions, and outbound data transfers should pause for a person even in a fully autonomous run. Everything else proceeds at full speed.

Claude Code: the rules that matter

Claude Code has six permission modes, from plan (read-only) up to bypassPermissions, the --dangerously-skip-permissions flag with no checks at all. They do not fall on a single clean dial, but the trade is the one to hold in your head before you write a rule: the more useful the mode, the less it protects.

• Decide centrally which environments allow bypass mode. --dangerously-skip-permissions is the mode autonomous runs and CI actually use. It should be a policy decision keyed to the environment, not a habit keyed to the developer.
• Scan .claude/settings.json before the project loads. A malicious repo config executes shell commands when a developer opens the project (CVE-2025-59536, CVSS 8.7, per Check Point Research), and a separate advisory, CVE-2026-21852, redirected the agent’s API traffic to an attacker’s server with no user interaction at all. One poisoned config, every teammate hit.
• Keep your own hooks, and treat the repo’s as untrusted. A hook you write is a control: your logic runs before a tool call. A hook the repo ships is the inverse. In CVE-2025-59536 a repo hook fired before the trust prompt ever appeared. Same mechanism, opposite author.
• Do not trust CLAUDE.md any more than AGENTS.md. Same shape of problem, same rule: an instruction file the agent obeys and an attacker can edit is a prompt-injection vector, full stop.

The rules both agents share

Strip away the vendor-specific flags and the same four rules fall out for any coding agent, which is the point:

1. Bypass mode is a policy decision, scoped by environment, never a per-developer default.
2. Config and instruction files - AGENTS.md, CLAUDE.md, .claude/settings.json, MCP declarations - are attacker-reachable input and get scanned before the agent reads them.
3. Credentials are off limits to generated commands. No reading ~/.ssh, ~/.aws, or .env, whatever the task claims to need.
4. The high-impact tail - CI/CD, deploys, bulk deletes, exfil-shaped transfers - pauses for a human. The routine majority does not.

Notice what these rules have in common. None of them is “pick the safe mode.” All of them assume the agent is running in the fast mode, on real inputs, and still has to be governed. That is the only assumption that survives contact with how teams actually work. It is also the same class of problem as the lethal trifecta: private data, untrusted content, and a way out, sitting inside one agent session.

Where the rules have to run

A rule that lives in a wiki is a suggestion. A rule that blocks rm -rf ~/ a few milliseconds before it runs is a control.

That is the whole argument for evaluating each generated action against policy at the point of execution, on the endpoint, before the command runs, regardless of which mode the agent is in. It is why bypass mode can keep its speed while the destructive tail still stops. It is runtime assurance: the rules you wrote, enforced on the action the agent is about to take, not the action you hoped it would take. The rules in this post map onto concrete controls in AI agent security policies.

Write the rules for the mode your team actually runs. Then put them somewhere they can say no.