Separate approval policy for file edits vs. shell commands

[jarrod-lowe]

What variant of Codex are you using?

cli, ide

What feature would you like to see?

Summary

Today, Codex has a single approval policy that applies to both apply_patch (file writes) and shell command execution. This forces an uncomfortable choice: either approve everything automatically — including arbitrary shell commands — or approve every single change, including each individual file edit.

A separate, lower-privilege approval tier for file writes would allow users to work at full speed on code, while still retaining meaningful oversight over command execution.

The problem in practice

The obvious risk people talk about with autonomous agents is catastrophic mistakes — "the AI deleted my database." That's real, but it's not the scenario that's actually hurting my day-to-day workflow.

Here's a more realistic and subtle one: the model writes some Terraform, the deployment fails, so the model goes and manually adjusts the deployed infrastructure to make the dev environment work. Problem solved — except now the dev environment has drifted from the codebase. In production, where the model has no access, the next deployment will fail in ways that are hard to diagnose, because the fix only ever existed in the deployed development system state, not the code.

This isn't a catastrophe. It's a slow erosion of correctness. And it happens because there was no friction on the shell command that reached out to the deployed environment — even though I would have been fine with the file edits that preceded it.

Velocity

The other side of this is flow. Approving every code edit individually — every patch to every file — is deeply disruptive when working across multiple tasks at once. If I want meaningful oversight on commands, I have to pay that cost on every file change as well. I've used other coding agents that treat these as distinct permission tiers, and the difference in how safely I can work quickly is significant. Switching to Codex has meant giving up one or the other: speed, or safety on commands.

Proposed solution

Add a file_write_policy configuration option, separate from approval_policy, with the following values:

Value	Behaviour
use-approval-policy	Current behaviour (default, no breaking change)
allow	Auto-approve all file writes; approval_policy still governs commands
deny-in-plan-allow-default	Reject writes in plan mode; auto-approve otherwise

Note: deny-in-plan-allow-default is largely redundant in practice — the system prompt already instructs the model not to make file changes in plan mode. It exists as a defence-in-depth measure, enforcing that constraint at the tool layer rather than relying solely on prompt-level instruction.

Example config:

# Approve file edits silently; still prompt before running commands
file_write_policy = "deny-in-plan-allow-default"
approval_policy   = "untrusted"

This is a targeted, additive change. The default preserves existing behaviour exactly. It simply unlocks a combination that is currently impossible: trusting file edits without also trusting shell execution.

Additional information

I have a patch at https://github.com/jarrod-lowe/codex/tree/file-write-policy . I am using this currently.

[etraut-openai]

Thanks for the thoughtful feature request.

We designed our approval policy and sandbox mechanism nine months ago — a lifetime in terms of agentic coding. We've learned a lot since then. We're talking internally about how to take all of these learnings and rethink our approach.

I don't think it would work to have separate policies for file edits vs shell commands because shell commands can be (and often are) used for editing files. However, I think your observations and articulation of the problem are on point.