Codex review tool cannot inspect local commits due to bwrap sandbox error and does not request escalation

[bromdun]

What version of Codex CLI is running?

v(0.124.0)

What subscription do you have?

Pro

Which model were you using?

GPT-5.5 xhigh

What platform is your computer?

Linux 369b745156a0 6.14.11 #1-NixOS SMP PREEMPT_DYNAMIC Tue Jan 1 00:00:00 UTC 1980 x86_64 GNU/Linux

What terminal emulator and version are you using (if applicable)?

No response

What issue are you seeing?

I’m seeing a regression with the Codex review tool in an environment where normal Codex shell commands require escalation because sandboxed local commands fail with a bubblewrap/user-namespace error.

The review tool failed with:

I could not inspect these local commits: sandboxed local commands fail with the bwrap namespace error, and the SHAs are not present in the connected GitHub repository. With no accessible diff, I cannot report actionable code findings.

Context:

• Environment: Replit/workspace-style environment where sandboxed commands fail with bwrap namespace errors.
• Normal Codex commands in the same session work when rerun with escalation.
• The review tool appears to attempt sandboxed local commands only, fails on bwrap, and does not request escalation.
• At the time, the commits were local-only and not pushed to GitHub, so the GitHub fallback could not find the SHAs.
• This workflow reportedly worked previously with GPT-5.4 in the same environment.

Impact:

• Local pre-push code review is unavailable in this environment.
• The only workaround is to push commits to GitHub first or manually provide a diff to another reviewer.

What steps can reproduce the bug?

1. Open a Codex session in a Replit/workspace environment where sandboxed shell commands fail with a bwrap / user-
   namespace error.
2. Make one or more local commits that have not been pushed to GitHub.
3. Ask the Codex review tool to review those local commits, for example:
   Review commits ..
4. Observe that the review tool attempts to inspect the commits locally using sandboxed commands.
5. The local inspection fails with a bwrap namespace error.
6. The review tool then attempts/falls back to GitHub lookup, but the SHAs are not present because the commits are
   local-only.
7. The review returns no actionable findings and reports that it cannot inspect the commits.

What is the expected behavior?

Expected behavior:

• The review tool should either request/use the same escalation path available to Codex shell commands, or surface a
  clear instruction that the commits must be pushed/available via GitHub.
• Ideally, it should be able to inspect local diffs in the same environment where Codex itself can inspect them with
  escalation.

Actual behavior:

• Review terminated without inspecting the diff and without actionable findings.
• The failure reason was environmental/tooling-related, not related to the code under review.

Additional information

Suggested fix:

• Allow the review tool to use escalation when sandboxed local commands fail due to bwrap/namespace restrictions.
• Alternatively, detect this failure mode and prompt the user to push the branch or provide a diff, rather than
  returning no actionable findings.

[etraut-openai]

Just to clarify, are you using the local /review slash command in the interactive CLI, or are you using the code review integration with Github?

[bromdun]

Just to clarify, are you using the local /review slash command in the interactive CLI, or are you using the code review integration with Github?

In CLI and to be clear these were commits that I did not push to GitHub yet. I then pushed the commits to GitHub and ran the /review tool again in CLI and it eventually worked and completed the review (after a lot of bwrap errors).

[bromdun]

So I just realized that this was a problem in the previous version as well. I was getting a lot of false positives with the review tool in the previous version, and I understand now why, because I'm getting them again. Basically, I was doing reviews with the review tool just now, and I had not pushed all the changes to GitHub yet. It was finding issues that had already been fixed because it didn't have the latest commits. So this is not a new issue in this latest release. It goes back at least one version.