›_ Codex Issues
Codex Issues / #39085

Codex documentation and model-facing instructions recommend unsafe prefix rules as examples of safe ones

Open 💬 2 comments Opened Aug 17, 2026 by dfoxfranke

What is the type of issue?

Documentation is incorrect

What is the issue?

The Codex auto-review documentation recommends,

Add narrowly scoped prefix rules. Prefer precise command prefixes such as ["cargo", "test"] or ["pnpm", "run", "lint"] over broad patterns such as ["python"] or ["curl"].

cargo test is not in any meaningful sense safer or more narrowly-scoped than python if the agent has write access to the workspace. Rust test suites may execute arbitrary code. Assuming a default :workspace-write permission setting, the agent can put whatever it wants into the test suite without requiring escalation. cargo test will execute that suite.

The same bad recommendation appears in the model-facing escalation-request instructions which provide guidance on what prefix rule to suggest for a persistent approval. They mention ["npm", "run", "dev"] and ["cargo", "test"] as good examples.

A similar error is present in the OpenAI-authored code-change-verification skill which tells the agent to ask for a persistent prefix-rule authorization that executes a repository-owned shell script, and in the curated cloudflare-deploy skill which suggests an ["npm", "run", "deploy"] escalation.

Where did you find it?

View original on GitHub ↗

2 Comments

jdcodes1 · 10 days ago

Verified in-repo on main @ 1f41cc5d92, and the combination is exactly as stated: the escalation template's opening line says approved / rule-matched commands run outside the sandbox, and the same file then recommends ["npm", "run", "dev"] and ["cargo", "test"] as example prefix rules to suggest for persistence:

https://github.com/openai/codex/blob/1f41cc5d92722748e45cae9cecc6d883a4e7cbb1/codex-rs/prompts/templates/permissions/approval_policy/on_request.md#L1-L57

So under the default workspace-write profile, persisting one of these rules means: the agent may freely edit package.json/Cargo.toml/the test tree (no approval needed — that's in-sandbox writing), and then any future npm run dev / cargo test executes that agent-authored code unsandboxed, forever, with no prompt. The prefix boundary is syntactic; the payload lives in files the agent controls.

The crisp criterion the docs are missing: a prefix rule is only a meaningful boundary if the command's behavior is not a function of agent-writable state. cargo test, npm run <anything>, pnpm run lint, make, pytest, go test, gradle are workspace interpreters — with write access to the workspace they are equivalent to ["bash"] for a persistent rule. It's notable that the same template is very careful about shell-syntax scoping (segment splitting at |/&&/;, refusing to match commands with redirection or substitutions "to limit the scope of what an approved rule allows") — the scoping rigor exists, it just stops one level below where the actual capability lives.

Constructive fix shapes, compatible with keeping prefix rules useful:

  1. Docs/template: replace the workspace-interpreter examples with genuinely constrained ones, and explicitly label rules for workspace-interpreting commands as "this trusts the repository's current and future contents — equivalent to permanent full access for this project". That framing is honest and still lets users opt in deliberately.
  2. Product: when the approval UI offers to persist a suggested prefix rule, warn if the command's basename+verb is on a small static workspace-interpreter list (a dozen entries covers the ecosystem majority). The UI already distinguishes one-time vs persistent approval; this is one more line of context at the moment it matters.
  3. Defense-in-depth alternative: most escalations cited in the template need one capability (usually network, sometimes a specific write path), not "no sandbox". Rules that auto-approve while re-running inside the sandbox with the named extra permission would preserve almost all the convenience while keeping the workspace-interpreter hazard contained. That's a larger change, but it addresses the class rather than the examples.

The cross-repo instances you list (openai/skills, openai-agents-python) inherit the same conceptual error from the docs, so fixing the criterion at the documentation/template level is the leverage point.

pmetzger · 10 days ago

See also: https://github.com/openai/codex/issues/23227 — it would be nice to be able to be able to edit proposed permissions and construct cleaner, narrower permissions that none the less allow the agent to work without needing escalations most of the time. Unfortunately there is no way right now to interactively edit these things while they are being proposed.