openai / openai/codex-plugin-cc

Windows: review --cwd <worktree> wastes ~15 sandbox-declined commands hunting for the right directory

Open
#280 0 comments 0 reactions 0 assignees View on GitHub

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:

  1. Sandbox policy is too narrow for worktrees. When cwd is a worktree, the reviewer's first instinct is git diff <SHA> from cwd. 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 plain git status after exhausting workarounds.
  2. The --cwd flag plumbing reaches cwd for the host-side runAppServerReview, but the spawned PowerShell sandbox in the Codex CLI starts somewhere that doesn't match. The first git diff attempt 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 fixed setup --cwd / status --cwd falling back to process.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, and GIT_* 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 diff works 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

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.