Clarify apply_patch escalation under approval_policy = "never"

Open 💬 0 comments Opened Aug 18, 2026 by rebroad

Summary

When apply_patch targets a path that is not part of the effective sandbox writable roots, the sandbox rejects the write. With approval_policy = "never", the current runtime suppresses the no-sandbox escalation approval and returns the sandbox failure directly.

The backwards recovery behavior is the key problem: to perform the edit, we had to tighten the effective security policy by changing approval_policy from "never" to "on-request", then explicitly grant the escalation approval. A policy intended to avoid approval friction therefore made recovery from a sandbox permission failure impossible until a more restrictive approval mode was selected.

Observed behavior

  • apply_patch failed with Read-only file system because the requested path was not writable in the effective sandbox.
  • With approval_policy = "never", no escalation prompt was emitted.
  • Changing to on-request caused an approval prompt; granting it allowed the patch to succeed.
  • The edit could therefore only be completed by tightening approval behavior and granting a one-off exception.

Clarification requested

Which of these semantics is intended for never / Full Access mode?

  1. Never shows no approval prompts and rejects any sandbox escalation.
  2. Never still surfaces a sandbox escalation prompt to the user when needed.
  3. Never / Full Access automatically approves escalation, so the tool proceeds without prompting.

In particular, should recovery from an unexpected sandbox denial require switching to a more restrictive approval mode first?

I added a minimal fork-side safeguard so apply_patch asks for escalation instead of silently suppressing the fallback: rebroad/codex commit 1f6dac6d57.

View original on GitHub ↗