Summary
codex-rescue's dispatch/monitoring path (agents/codex-rescue.md + scripts/codex-companion.mjs) reports task completion without ever checking whether the underlying work actually happened. This produces reproducible false-positive "done" reports. Confirmed on v1.0.6 (current as of 2026-09-08); the same gaps were present in a prior audit of an earlier pinned version, so this isn't a regression — it's been there across at least 6 version bumps.
What's missing
- No git-state check before reporting completion.
codex-companion.mjs (1073 lines) has zero references to git status, git log, or any equivalent verification. Completion is reported purely from the wrapper's own process exit, never from inspecting whether a commit/PR actually resulted.
agents/codex-rescue.md explicitly forbids the dispatched subagent from doing any git hygiene (commit/push/PR/cleanup) — it's instructed to forward text only, but nothing downstream picks up that responsibility either.- No
--add-dir <repo>/.git handling for worktrees. A worktree's .git admin directory lives in the main checkout, not the worktree itself — without this flag, git operations inside a dispatched worktree can silently fail.
- Dispatched jobs run network-isolated by default, so a job that's supposed to open a PR frequently can't, with no clear signal back that this happened.
- Observed concretely on 2026-09-03: a dispatch returned a job ID that the tool's own job registry had never recorded (
codex-companion.mjs status <job-id> reported "No jobs recorded yet" for an ID the same tool had just returned as if the job was queued).
Why this matters
Nothing in the tool's own output distinguishes "the wrapper stopped watching" from "the work is done." Callers have no reliable way to trust a completion report without independently re-deriving git state themselves every time, which defeats a large part of the point of an automated dispatch tool.
Suggested fix
Before codex-companion.mjs reports a job as done/completed, have it check git log/git status in the target worktree (or accept and record an explicit "no git changes expected" flag for review-only jobs) and surface a distinct status when the child process is still alive vs. genuinely exited. Optionally pass --add-dir <repo>/.git automatically when dispatching into a worktree, since the tool already knows the worktree path.
Version
@openai/codex-plugin-cc v1.0.6 (package.json). Note: CHANGELOG.md only has a single "1.0.0 - Initial version" entry despite 6 version bumps since, so I can't tell from the changelog whether any of this has already been addressed in a version between where a prior audit found these gaps and now — direct source inspection of v1.0.6 confirms they're all still present today.
Summary
codex-rescue's dispatch/monitoring path (agents/codex-rescue.md+scripts/codex-companion.mjs) reports task completion without ever checking whether the underlying work actually happened. This produces reproducible false-positive "done" reports. Confirmed on v1.0.6 (current as of 2026-09-08); the same gaps were present in a prior audit of an earlier pinned version, so this isn't a regression — it's been there across at least 6 version bumps.What's missing
codex-companion.mjs(1073 lines) has zero references togit status,git log, or any equivalent verification. Completion is reported purely from the wrapper's own process exit, never from inspecting whether a commit/PR actually resulted.agents/codex-rescue.mdexplicitly forbids the dispatched subagent from doing any git hygiene (commit/push/PR/cleanup) — it's instructed to forward text only, but nothing downstream picks up that responsibility either.--add-dir <repo>/.githandling for worktrees. A worktree's.gitadmin directory lives in the main checkout, not the worktree itself — without this flag, git operations inside a dispatched worktree can silently fail.codex-companion.mjs status <job-id>reported "No jobs recorded yet" for an ID the same tool had just returned as if the job was queued).Why this matters
Nothing in the tool's own output distinguishes "the wrapper stopped watching" from "the work is done." Callers have no reliable way to trust a completion report without independently re-deriving git state themselves every time, which defeats a large part of the point of an automated dispatch tool.
Suggested fix
Before
codex-companion.mjsreports a job asdone/completed, have it checkgit log/git statusin the target worktree (or accept and record an explicit "no git changes expected" flag for review-only jobs) and surface a distinct status when the child process is still alive vs. genuinely exited. Optionally pass--add-dir <repo>/.gitautomatically when dispatching into a worktree, since the tool already knows the worktree path.Version
@openai/codex-plugin-ccv1.0.6 (package.json). Note:CHANGELOG.mdonly has a single "1.0.0 - Initial version" entry despite 6 version bumps since, so I can't tell from the changelog whether any of this has already been addressed in a version between where a prior audit found these gaps and now — direct source inspection of v1.0.6 confirms they're all still present today.