Code review feature completely broken due to bad sandboxing

Bumped to v0.69.0 (I install via brew, so sometimes it lags behind on versions a bit) and the same issue still occurs.

Bumped to v0.71.0 hoping that this would be fixed already: still broken.

@etraut-openai: I can only reproduce this issue in the CLI. Through the extension the /review command works fine. I think that CLI label makes sense here.

I encountered the same issue in the CLI as well

@etraut-openai
I'm facing the same issue, and it's really bothering me. When using the /review command in CLI, it prompts the following:
git: warning: confstr() failed with code 5: couldn't get path of DARWIN_USER_TEMP_DIR; using /tmp instead
git: error: couldn't create cache file '/tmp/xcrun_db-SQmI6uR4' (errno=Operation not permitted)

I reverted the codex version to v0.65.0 without any issues; all subsequent versions have this problem.

One more codex-cli release, 0.72.0 this time, the issue is still present. @etraut-openai, do you think you guys will fix this anytime soon? Kind of losing hope here.

@etraut-openai I'd like to work on this. Is this still available?

@anupammaurya6767, you're welcome to investigate the root cause. Post anything you find here.

@etraut-openai Found the root cause: review mode was hardcoding the sandbox policy to read-only, ignoring --yolo.

This was an intentional change. See this PR.

@jif-oai, thoughts?

I think you are on a good lead, @anupammaurya6767, but you are focussed on the wrong thing.

git status is somehow trying to write files outside the project's folder (see the error git: error: couldn't create cache file '/tmp/xcrun_db-8dRHB1xN' (errno=Operation not permitted)). So a heavily constrained read-only sandbox won't work.

The read-only sandbox should allow a git status to run, even if that git status needs to write a file to /tmp.

I am not sure if git changed the implementation of git status to write these temporary files or if just the read-only sandbox got so good that even writes to /tmp are now blocked.

This indicates that we might need a special "review" sandbox that will allow git commands to write to /tmp if they need.

@etraut-openai @douglascamata Thanks both for the clarification and extra detail.

I first assumed this was a /review + --yolo regression, but given that the always‑read‑only review sandbox is intentional, the real issue is that it’s now too strict for normal git usage: git status (and likely other git commands) need to write temp/cache files under /tmp, and those writes are being blocked, so even a “read‑only” review sandbox needs some controlled write capability.

A possible path forward would be a dedicated “review” sandbox policy that still keeps the workspace and other sensitive paths read‑only, but explicitly allows safe transient writes (like git’s temp files under /tmp) so /review works as expected. If that direction sounds acceptable, I’m happy to help explore what that policy should look like and try a prototype once you’re okay with the approach. @etraut-openai

A dedicated sandbox policy for /review doesn't sound like the right solution. That adds too much complexity.

Seems like we have more users reporting similar issues: #8105 and #8104.

Understood, a dedicated review sandbox policy would add complexity.

@etraut-openai A simpler fix: use the existing WorkspaceWrite policy for review, but configure it so the workspace itself is read-only (via read_only_subpaths) while /tmp remains writable. This lets git commands write their temp files to /tmp without allowing writes to the workspace.

If that direction works, I can draft a small change to switch review from ReadOnly to WorkspaceWrite with the workspace marked as a read-only subpath.

@anupammaurya6767, thanks for offering, but I don't think that's the right solution.

@douglascamata & @PhilChen-6765, we're wondering why git status would trigger a policy violation for a read-only sandbox. Is this perhaps related to something specific about the way you've configured git on your system?

I don't think I have anything special configured when it comes to git status. I don't change my ~/.gitconfig since a long time and the /review command broke just after an upgrade of the Codex CLI.

Sharing here my whole .gitconfig, just in case:

[color]
  branch = auto
  diff = auto
  status = auto
[alias]
  ci = commit
  st = status
  br = branch
  co = checkout
  df = diff
  lg = log -p
  who = shortlog -s --
  hist = log --pretty=format:\"%h %ad | %s%d [%an]\" --graph --date=short
  cf = !sh -c \"git diff --name-only | uniq | xargs subl -n\"
[filter "lfs"]
  clean = git-lfs clean -- %f
  smudge = git-lfs smudge -- %f
  process = git-lfs filter-process
  required = true
[init]
  defaultBranch = main
[core]
  autocrlf = input
  excludesFile = ~/.gitignore.global
  pager = delta
[interactive]
  diffFilter = delta --color-only
[delta]
  navigate = true
  light = false
[gpg]
  format = ssh
[commit]
  gpgsign = true
  verbose = true
[merge]
  conflictStyle = zdiff3
  ff = false
[diff]
  colorMoved = default
  algorithm = histogram
  mnemonicPrefix = true
  external = difft
[pager]
  branch = false
[push]
  autoSetupRemote = true
  default = simple
[pull]
  rebase = false
  ff = true
  autostash = true
[log]
  showSignature = false
[url "git@github.com:"]
	insteadof = https://github.com/
[column]
	ui = auto
[branch]
	sort = -committerdate
[tag]
	sort = version:refname
[rerere]
	enabled = true
	autoupdate = true

Other useful info:

$ git --version
git version 2.50.1 (Apple Git-155)

$ which git
/usr/bin/git

Ok, I figured out the issue, guys!

I did some deeper research regarding the error message with the help of LLMs (who could've guessed). I got a good explanation and solution.

1st, the folder in the error /tmp/xcrun_db-8dRHB1xN is a tell that leads to the root of the issue: in macOS, /usr/bin/git is a shim that calls xcrun to look up which git binary to use from the Xcode or macOS Command Line Tools. This xcrun tools creates a cache DB in /tmp to make faster lookups. That's why the sandbox catches this write and denies it.

2nd, the solution: brew install git and ensure that Homebrew's bin path has higher priority in your $PATH, so that which git returns /opt/homebrew/bin/git. This means Codex will use Homebrew's git and it'll work. I tested this locally.

I believe the deeeeper root cause of why it failed before could be related to this part of the error:

git: warning: confstr() failed with code 5: couldn't get path of DARWIN_USER_TEMP_DIR; using /tmp instead

Because I can check that DARWIN_USER_TEMP_DIR exists:

$ getconf DARWIN_USER_TEMP_DIR
/var/folders/s0/lq766py93v16kvh6lk7f0yyw0000gn/T/

And it points to a directory that is owned by my user. Maybe for some reason now the getconf call made by xcrun fails (another sandbox thing?), then it tries to fallback to /tmp, which also fails because sandbox again. 😓

But we got a solution, which is nice. Might be good to document it.

Thanks for the diagnosis. I think that's spot on.

The recent change was intended to prevent the model from making any code changes during a /review, which is occasionally does. Unfortunately, this change has had a number of unintended side effects, so we've decided to revert it for now. We'll need to come up with some other solution for the other problem.