openai / openai/codex-plugin-cc
Windows: review --cwd <worktree> wastes ~15 sandbox-declined commands hunting for the right directory
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 33.3k
- Forks
- 2.3k
- PR merge metrics
- No merged PRs in 30d
Description
Summary
codex-companion review --cwd <worktree> on Windows + PowerShell + a git worktree consistently spends ~15 PowerShell tool-use attempts before the reviewer's own git diff runs successfully. The first git diff <base> fails, the model then calls Get-Location, reads the worktree's .git gitdir-pointer file, attempts --git-dir=, safe.directory=, and a series of $env:GIT_CONFIG_* shell tricks — most of which are declined by the sandbox policy — until eventually a plain git status succeeds and a retry of git diff works.
When the diff is small the review still produces correct output (because the model eventually does run a working git diff). But the failure pattern is wasteful, slow, and on at least one of my runs the model gave up after the early failures and produced a review of unrelated files from a different checkout.
Repro
Tested on 1.0.2 and 1.0.4 — same behavior on both.
node "$CLAUDE_PLUGIN_ROOT/scripts/codex-companion.mjs" review \
--wait --base <SHA> --scope branch \
--cwd "C:/Users/me/code/repo-worktree-x"
…where repo-worktree-x is a git worktree add-ed worktree of repo (so .git inside it is a file containing gitdir: …, not a directory).
What the trace looks like
[codex] Reviewer started: changes against '<SHA>'
[codex] Running command: pwsh -Command 'git diff <SHA>...'
[codex] Command failed: ... (exit 1)
[codex] Running command: pwsh -Command 'Get-Location; Get-ChildItem -Force'
[codex] Command completed
[codex] Running command: pwsh -Command 'Get-Content -LiteralPath .git'
[codex] Command completed ← reads the gitdir pointer
[codex] Running command: pwsh -Command 'git status --short --branch'
[codex] Command failed
[codex] Running command: pwsh -Command 'git -c safe.directory=<path> ...'
[codex] Command declined ← sandbox policy
[codex] Running command: pwsh -Command 'git --git-dir=<path> ...'
[codex] Command declined
[codex] Running command: pwsh -Command '$env:GIT_CONFIG_COUNT=1; ...'
[codex] Command declined
... (many more attempts)
[codex] Running command: pwsh -Command 'git status'
[codex] Command completed ← finally works
[codex] Running command: pwsh -Command 'git diff <SHA>...'
[codex] Command completed
(Full trace from a 1.0.4 run available on request.)
Likely root cause (informed guesses)
Two distinct things compounding:
- Sandbox policy is too narrow for worktrees. When
cwdis a worktree, the reviewer's first instinct isgit diff <SHA>fromcwd. That fails — git's response on Windows includes "fatal: detected dubious ownership in repository" or a similar guard, and every standard workaround (-c safe.directory=…,--git-dir=…,$env:GIT_CONFIG_COUNT=…) is rejected by the sandbox before git ever runs. The model only succeeds when it falls through to a plaingit statusafter exhausting workarounds. - The
--cwdflag plumbing reachescwdfor the host-siderunAppServerReview, but the spawned PowerShell sandbox in the Codex CLI starts somewhere that doesn't match. The firstgit diffattempt either runs from the wrong directory or runs in an environment where the worktree's gitdir pointer isn't resolved. (Seems related to #30 which fixedsetup --cwd/status --cwdfalling back toprocess.cwd()— possibly the same fix needs to extend to the review subcommand's downstream sandbox cwd handoff.)
Environment
- OS: Windows 11 Pro
- Shell: PowerShell 7 (pwsh.exe)
- Plugin: codex@openai-codex 1.0.4 (also reproduced on 1.0.2)
- Codex CLI: latest released, installed via npm
Why it's worth fixing even though reviews still complete
- A small-diff review takes 30–60s of churn before the first useful tool call.
- The wasted tool calls eat token budget — one of my runs hit the daily Codex usage limit during exactly this hunt phase, killing a review that hadn't started yet.
- On a separate occasion (also documented), the model did not recover from the early failures and reviewed files from a different checkout entirely (a sibling directory with the same repo name, opposite-case drive letter), producing a confidently-wrong review of unrelated changes.
Suggested fix directions
- Allow
safe.directory=*,--git-dir, andGIT_*environment overrides through the review sandbox policy (or pre-configure them so they don't need to be set per-command). - Resolve the worktree's gitdir pointer host-side before launching the review thread, and pass the resolved repo root to the sandbox so the reviewer's first
git diffworks on the first try. - Related: #30 (closed) for the same shape of bug on
setup/status.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in scripts/codex-companion.mjs, tracing the review --cwd path into runAppServerReview and the downstream Codex sandbox. Reproduce the Windows worktree command from the issue and inspect related --cwd handling from #30. Done means the review sandbox uses the intended worktree and the first git diff succeeds without workaround attempts or unrelated files.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- git, javascript, powershell
- Domain
- cli, devtools, tooling
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100