/review does not see any branches or commits after updating to 0.131

Bisected the regression range to v0.130.0..v0.131.0 in a source-only review (no local repro yet).

Picker call graph:

1. /review -> open_review_popup() in codex-rs/tui/src/chatwidget/review_popups.rs:6 shows the four-item menu (this part works for the reporter).
2. "Review against a base branch" sends AppEvent::OpenReviewBranchPicker(cwd) -> event_dispatch.rs:1774 -> show_review_branch_picker(cwd).await (review_popups.rs:63) -> local_git_branches(cwd).await (git-utils/src/info.rs:796).
3. "Review a commit" sends AppEvent::OpenReviewCommitPicker(cwd) -> event_dispatch.rs:1777 -> show_review_commit_picker(cwd).await (review_popups.rs:95) -> recent_commits(cwd, 100).await (git-utils/src/info.rs:313).

Both picker fns return Vec::new() whenever the underlying run_git_command_with_timeout returns None or non-success, which is the visible "empty list" symptom.

Code diff between v0.130.0 (58573da4) and v0.131.0 (05eb8678) in that call path:

• local_git_branches, current_branch_name, recent_commits are byte-identical.
• open_review_popup, show_review_branch_picker, show_review_commit_picker are byte-identical (just relocated from chatwidget.rs into the new chatwidget/review_popups.rs module by 3c3e18c2, phase-5 refactor).
• run_git_command_with_timeout in git-utils/src/info.rs:375 is the only meaningful change. Two commits modified it:
• 6ec8c4a6 (#22652, 2026-05-14) added .args(["-c", "core.fsmonitor=false"]).
• 9facdccb (#22843, 2026-05-15) added .args(["-c", &format!("core.hooksPath={DISABLED_HOOKS_PATH}")]) where DISABLED_HOOKS_PATH is "/dev/null" on Unix and "NUL" on Windows.

Both flags pass through fine on Linux with git 2.47 (git -c core.hooksPath=/dev/null -c core.fsmonitor=false branch --format='%(refname:short)' returns the branches as expected), so the smoking gun is platform- or git-version-dependent.

A couple of things that would narrow it:

1. The Codex doctor report block in the issue is empty. Running codex doctor from the affected repo and pasting the output would help.
2. Platform + git --version from the reporter's machine.
3. Output of running the actual command manually in the affected repo: git -c core.hooksPath=/dev/null -c core.fsmonitor=false branch --format='%(refname:short)' (substitute NUL for /dev/null on Windows).

If that command also returns empty/errors, the regression is in 9facdccb or 6ec8c4a6 and the fix is to either drop the override under specific conditions or fall back when git rejects it. If the command works fine, the failure is upstream of run_git_command_with_timeout (e.g., self.config.cwd resolving to a non-repo path on the reporter's setup).

1.
Environment
✓ runtime npm
version 0.131.0
install method npm
commit unknown
executable /usr/local/share/nvm/ver…-linux-musl/codex/codex
✓ install consistent
context npm
managed by npm: yes · bun: no · package root /usr/local/share/nvm/versions/node/v24.15.0/lib/node_modules/@openai/codex
PATH entries (4) /usr/local/share/nvm/ver…node/v24.15.0/bin/codex
/usr/local/share/nvm/current/bin/codex
/usr/local/share/nvm/ver…node/v24.15.0/bin/codex
… (full list with --all)
npm update target /usr/local/share/nvm/ver…e_modules/@openai/codex
✓ search ripgrep 15.1.0 (rev af60c2de9d) (system, rg)
search command rg
search provider system
search command readiness ripgrep 15.1.0 (rev af60c2de9d)
⚠ terminal height 23 rows - content may scroll off (recommended >=24)
terminal VS Code
TERM_PROGRAM vscode
terminal version 1.119.0
stdin is terminal true
stdout is terminal true
stderr is terminal true
▸ terminal size 164x23 (expected >= 24 rows)
color output enabled
COLORTERM truecolor
effective locale en_US.UTF-8
VSCODE_IPC_HOOK_CLI present
→ resize the window to at least 24 rows
✓ state databases healthy
CODEX_HOME ~/.codex (dir)
log dir ~/.codex/log (dir)
sqlite home ~/.codex (dir)
state DB ~/.codex/state_5.sqlite (file) · integrity ok
log DB ~/.codex/logs_2.sqlite (file) · integrity ok
active rollouts 1,595 files · 7.10 GB (avg 4.56 MB)
archived rollouts 0 files · 0 B (avg 0 B)

Configuration
✓ config loaded
model gpt-5.5 · openai
config.toml ~/.codex/config.toml
config.toml parse ok
MCP servers 0
feature flags 29 enabled · 1 overridden (full list with --all)
overrides goals
✓ auth auth is configured
auth storage mode File
auth file ~/.codex/auth.json
stored auth mode chatgpt
stored API key false
stored ChatGPT tokens true
stored agent identity false
✓ mcp no MCP servers configured
✓ sandbox unrestricted fs + enabled network · approval OnRequest
approval policy OnRequest
filesystem sandbox unrestricted
network sandbox enabled
linux helper ~/.codex/tmp/arg0/codex-…Izp/codex-linux-sandbox
execve wrapper helper ~/.codex/tmp/arg0/codex-…zp/codex-execve-wrapper

Updates
✓ updates update configuration is locally consistent
startup update check true
update action npm install -g @openai/codex
version cache ~/.codex/version.json
cached latest version 0.131.0
last checked at 2026-05-19 05:45 UTC
npm update target /usr/local/share/nvm/ver…e_modules/@openai/codex
latest version 0.131.0
latest version status current version is not older

Connectivity
✓ network no proxy env vars
proxy env vars none
✓ websocket connected (HTTP 101 Switching Protocols) · 15s timeout
model provider openai
provider name OpenAI
wire API responses
supports websockets true
proxy env vars none
connect timeout 15000 ms
auth mode chatgpt
endpoint wss://chatgpt.com/backend-api/<redacted>
DNS 2 IPv4, 2 IPv6, first IPv4
handshake result HTTP 101 Switching Protocols
reasoning header false
models etag present true
server model present false
✓ reachability active provider endpoints are reachable over HTTP
reachability mode ChatGPT auth
ChatGPT base URL https://chatgpt.com/backend-api/ reachable (HTTP 403)

Background Server
✓ app-server running (ephemeral mode)
daemon state dir ~/.codex/app-server-daemon
settings ~/.codex/app-server-daemon/settings.json (missing)
pid file ~/.codex/app-server-daemon/app-server.pid (missing)
update-loop pid file ~/.codex/app-server-daem…/app-server-updater.pid (missing)
control socket ~/.codex/app-server-cont…app-server-control.sock
status running
mode ephemeral

1. git version 2.51.1

1. git -c core.hooksPath=/dev/null -c core.fsmonitor=false branch --format='%(refname:short)' returns a list branches

Thanks for the doctor report. Two narrowing questions:

1. What's your $PWD when you launch Codex from the VS Code terminal? /review runs git in Codex's working directory, so launching outside a worktree would silently empty the picker. If v0.130 worked from the same launch directory, this isn't the regression — but worth ruling out before chasing a phantom.

1. When you hit /review, does the picker show any content (header, "no branches found" text, etc.), or is it completely empty/missing? That separates "git returned nothing" from "render layer suppressed it."

The doctor flagged your terminal at 23 rows (recommended >=24), and a too-tight vertical layout is one of the few v0.130→v0.131 deltas I haven't been able to rule out from source-reading alone.

Bonus if easy: RUST_LOG=codex_tui=debug,codex_core=debug codex before /review — the picker invocation path logs the exact git command + cwd it ran, which separates the two hypotheses definitively.

1. from a worktree folder, same as worked in 0.130

/review shows:
Select a review preset

› 1. Review against a base branch (PR Style)

1. Review uncommitted changes
2. Review a commit
3. Custom review instructions

Then when I choose

1. Review against a base branch

It says:

Select a base branch

Type to search branches
no matches

Press enter to confirm or esc to go back

Thanks, that narrows it cleanly. Picker chrome renders, you're in a worktree where v0.130 worked, and the exact -c invocation returns branches at your shell. So local_git_branches(cwd) is returning an empty Vec from inside codex even though the equivalent command works when you run it manually.

Looking at the source, local_git_branches at codex-rs/git-utils/src/info.rs:810-822 returns Vec::new() in exactly three cases:

1. The git command exits non-zero.
2. The 5-second timeout fires (GIT_COMMAND_TIMEOUT at info.rs:59).
3. Command::output() errors out before completing.

Cases 1 and 3 would mean the manual command also breaks for you, but it doesn't. That leaves case 2: the timeout.

The two -c flags that landed between v0.130 and v0.131 (#22652 for core.fsmonitor=false, #22843 for core.hooksPath=/dev/null) shouldn't slow git branch --format=... down, but they do change the invocation shape relative to v0.130, and your install has 1,595 active rollouts totaling 7.10 GB sitting in ~/.codex, so IO pressure on the host is plausible. The 5s ceiling is the only thing that distinguishes "codex says empty" from "shell says full" in your evidence.

One direct check, run from the same worktree you launch Codex in:

time GIT_OPTIONAL_LOCKS=0 git -c core.hooksPath=/dev/null -c core.fsmonitor=false branch --format='%(refname:short)'

GIT_OPTIONAL_LOCKS=0 is the only thing codex's subprocess sets that your manual run didn't, and time will tell us whether the call is under or over 5 seconds. If it's over, that's the bug surface. If it's well under and still returns branches, the timeout hypothesis is wrong and the problem is somewhere I haven't found yet.

For a second data point, the commit-picker path (Review a commit) runs through recent_commits(cwd, 100) at the same run_git_command_with_timeout wrapper. If that one also returns "no matches" for you in the same worktree, the failure is generic to run_git_command_with_timeout. If the commit picker works, the failure is specific to git branch --format.

time GIT_OPTIONAL_LOCKS=0 git -c core.hooksPath=/dev/null -c core.fsmonitor=false branch --format='%(refname:short)'
real 0m0.597s
user 0m0.003s
sys 0m0.010s

0.597s rules out the timeout. That kills failure mode (2) and leaves either (1) non-zero exit or (3) Command::output() erroring inside codex, with your manual run still succeeding. The simplest way those two diverge is cwd canonicalization.

Codex resolves cwd through env::current_dir() (codex-rs/utils/absolute-path/src/lib.rs:80), which on Linux calls getcwd(3) and returns the kernel-canonical path with symlinks resolved. Shells preserve the logical $PWD. If your worktree path goes through a symlink, codex's subprocess runs git branch from the canonical path while your shell test ran it from the logical one.

Two checks from the shell you launch codex from:

pwd
pwd -P

If those differ, codex is operating on the canonical path. To verify the diagnosis, run the failing command from that path:

cd "$(pwd -P)" && time GIT_OPTIONAL_LOCKS=0 git -c core.hooksPath=/dev/null -c core.fsmonitor=false branch --format='%(refname:short)'

If that returns no branches or non-zero exit, the bug is on the codex side resolving past your worktree's .git pointer.

If "Review a commit" is easy to try, that data point still helps: it goes through recent_commits(cwd, 100) at the same wrapper, so "no matches" there means the failure is generic, branches-only means it's specific to git branch --format.

It seems the issue is that codex things cwd is ~ no matter where it starts from.

If I start codex using "codex --cd folderofsomeworktree" it works.

I think this is the same underlying problem as https://github.com/openai/codex/issues/23367. We're working on a fix.

I think this is the same underlying problem as #23367. We're working on a fix.

Yes, it's the same issue. I guess this can be closed as a duplicate.