Overeager assumption of sandbox error

Resolved 💬 4 comments Opened Oct 7, 2025 by corrylc Closed Oct 9, 2025

What version of Codex is running?

codex-cli 0.45.0

Which model were you using?

gpt-5-codex high

What platform is your computer?

Darwin 25.0.0 arm64 arm

What steps can reproduce the bug?

Ask codex to "run bash -c false"

What is the expected behavior?

Command is interpreted as "failing" (i.e. returns an error code) but isn't attributed to the sandbox.

What do you see instead?

• Ran bash -c false
  └ failed in sandbox:

Additional information

This is a reduction of the more complicated case I see, where some testing triggers this behavior. I tried to come up with the most basic test case that plainly can't be caused by the sandbox/seatbelt.

View original on GitHub ↗

4 Comments

dipsy · 10 months ago

same bug in codex-cli 0.45.0 (not in 0.44)

corrylc · 10 months ago

For now, I am using a small patch to nullify this issue, since it is almost never a sandbox issue. It seems odd for the codebase to so aggressively assume it is always a sandbox issue, when usually it... isn't?

I am not enough of a rust programmer to trace the intended path here and fix the issue more properly, but this does work as a _very rough_ workaround.

diff --git a/codex-rs/core/src/exec.rs b/codex-rs/core/src/exec.rs
index d84bbc9fc..7d2b7d1cc 100644
--- a/codex-rs/core/src/exec.rs
+++ b/codex-rs/core/src/exec.rs
@@ -208,8 +208,7 @@ fn is_likely_sandbox_denied(sandbox_type: SandboxType, exit_code: i32) -> bool {
         return false;
     }
 
-    // For all other cases, we assume the sandbox is the cause
-    true
+    false
 }

corrylc · 10 months ago

Looks like #4874 is resolves, at least in part, this issue. Will test a bit more, but it covers my basic test above 🎉

corrylc · 10 months ago

Closing, as I don't see any issues following the fix PR.