Codex Model claims it is unable to request permission after failure

What version of Codex is running?

codex-cli 0.55.0

What subscription do you have?

Pro

Which model were you using?

gpt-5-codex (reasoning medium, summaries detailed)

What platform is your computer?

Linux 5.15.167.4-microsoft-standard-WSL2 aarch64 unknown

What issue are you seeing?

I have the approval mode set to on-failure, yet the model did not ask permission when a Rust compilation fails due to the sandbox:

Prompt:

Please run `make test`, requesting permission if the initial execution fails to execute within the sandbox, and investigate the cause of the compilation errors

Model's response:

• - make test (which calls cargo test --workspace --all-targets --all-features with RUSTFLAGS=-D warnings) fails immediately because rustc cannot finish writing
    intermediate artefacts such as libthiserror-*.rmeta, returning Invalid cross-device link (os error 18).
  - That error means rustc writes each file to a temporary path on one filesystem and then renames it into target/…, but the rename crosses devices. In this setup /tmp
    lives on tmpfs while the workspace (and therefore target/) is on /mnt/c, i.e. the Windows drive, so the rename becomes a cross-device link and fails.
  - You can confirm the separate mounts via df -h /tmp /mnt/c/Users/leyno/Projects/rstest-bdd/target, which shows /tmp on tmpfs and target on /mnt/c.
  - Fixes: run the project from the Linux filesystem (e.g. somewhere under /home), or ensure the temp directory shares the same mount as target by exporting TMPDIR=/
    mnt/c/Users/leyno/tmp (or similar) before invoking Cargo, or alternatively move the Cargo target dir to /tmp (CARGO_TARGET_DIR=/tmp/cargo-target make test). Any of
    these options keep the temporary files and final artefacts on the same device so rustc’s rename succeeds.

Me being a Karen:

• Feedback uploaded. Please open an issue using the following URL:

  https://github.com/openai/codex/issues/new?template=2-bug-report.yml&steps=Uploaded%20thread:%20019a5339-1747-7eb0-91e4-bb02b9a41532

  Or mention your thread ID 019a5339-1747-7eb0-91e4-bb02b9a41532 in an existing issue.

/status

╭────────────────────────────────────────────────────────────────────────────╮
│  >_ OpenAI Codex (v0.55.0)                                                 │
│                                                                            │
│ Visit https://chatgpt.com/codex/settings/usage for up-to-date              │
│ information on rate limits and credits                                     │
│                                                                            │
│  Model:            gpt-5-codex (reasoning medium, summaries detailed)      │
│  Directory:        /mnt/c/Users/leyno/Projects/rstest-bdd                  │
│  Approval:         on-failure                                              │
│  Sandbox:          workspace-write                                         │
│  Agents.md:        AGENTS.md                                               │
│  Account:          leynos@troubledskies.net (Plus)                         │
│  Session:          019a5339-1747-7eb0-91e4-bb02b9a41532                    │
│                                                                            │
│  Context window:   100% left (12.8K used / 272K)                           │
│  5h limit:         [░░░░░░░░░░░░░░░░░░░░] 1% used (resets 13:47)           │
│  Weekly limit:     [███████████████████░] 94% used (resets 15:39 on 9 Nov) │
│  Warning:          limits may be stale - start new turn to refresh.        │
╰────────────────────────────────────────────────────────────────────────────╯

Asked the model why it's being so obnoxious:

› Why did you not request permission when `make test` failed due to the sandbox?


⚠ Heads up, you've used over 95% of your weekly limit. Run /status for a breakdown.

─ Worked for 3s ───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

• make test didn’t fail because of the sandbox—it ran to completion and rustc itself reported Invalid cross-device link errors. Sandbox escalation is only needed if
  the sandbox prevents the command from running (e.g. permission denied, blocked filesystem), but here the command executed normally and hit a real filesystem issue.
  Hence no permission request was necessary.


› I can run `make test` though. Here is the compilation error I get:

  ~~~
     Compiling cargo-bdd v0.1.0-alpha4 (/mnt/c/Users/leyno/Projects/rstest-bdd/crates/cargo-bdd)
  error: derive helper attribute is used before it is introduced
    --> crates/cargo-bdd/src/main.rs:48:3
     |
  48 | #[serde(default)]
     |   ^^^^^
     |                 ----------- the attribute is introduced here
     |
     = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
     = note: for more information, see issue #79202 <https://github.com/rust-lang/rust/issues/79202>
     = note: `#[deny(legacy_derive_helpers)]` (part of `#[deny(future_incompatible)]`) on by default

  error: could not compile `cargo-bdd` (bin "cargo-bdd" test) due to 2 previous errors
  warning: build failed, waiting for other jobs to finish...
  error: could not compile `cargo-bdd` (bin "cargo-bdd") due to 2 previous errors
  make: *** [Makefile:20: test] Error 101
  ~~~

  Is the error you see not being recognized by the harness as a sandbox error?

• Right—my make test run actually didn’t get as far as compiling cargo-bdd; rustc failed earlier while writing thiserror, syn, etc. because it couldn’t rename temp
  files from /tmp (tmpfs) into the repo on /mnt/c, giving the Invalid cross-device link errors I reported. Since the command started and hit a real filesystem problem,
  the harness correctly treated it as a normal failure rather than a sandbox block, so I wasn’t prompted to escalate.

  In your environment the build’s getting past that stage and reaching the legacy_derive_helpers error in crates/cargo-bdd/src/main.rs:48. That’s a separate compiler
  issue we’ll need to fix once I can get the cross-device link problem out of the way (either by exporting TMPDIR to somewhere on /mnt/c before running make test, or
  by moving the repo to the Linux filesystem). Once I’ve got tests running locally without the rename failure, I can reproduce and address your serde attribute error
  directly.

Works in YOLO mode:

$ codex resume 019a5339-1747-7eb0-91e4-bb02b9a41532 --dangerously-bypass-approvals-and-sandbox

...

› Okay, you're in "Live dangerously and break things" mode. Please try `make test` again (no env var shenanigans, just that command).


• Ran cd /mnt/c/Users/leyno/Projects/rstest-bdd && make test
  └ RUSTFLAGS="-D warnings" cargo test --workspace --all-targets --all-features
       Compiling thiserror v2.0.17
    … +25 lines
    warning: build failed, waiting for other jobs to finish...
    error: could not compile `cargo-bdd` (bin "cargo-bdd") due to 2 previous errors

What steps can reproduce the bug?

See above. Ran make test. Execute with sandbox: failure, model cries, pleads innocence.

Run in YOLO mode: works as expected.

What is the expected behavior?

The harness should detect sandbox-induced b0rkage and let the model request execution without the sandbox.

Additional information

Repo: https://github.com/leynos/rstest-bdd