v1.2 to v1.3

---

name: codexloop

description: >

Iteratively satisfy OpenAI Codex's code review on a GitHub PR, but treat every Codex comment

SKEPTICALLY: verify each finding against the real code first, fix ONLY the genuinely-correct

review", "fix codex comments", "codex loop", or wants to iterate on Codex PR review feedback.

compatibility: GitHub only (Codex code review is a GitHub app). Requires git + jq + gh (GitHub CLI) authenticated, and the Codex / ChatGPT connector app installed on the repo with code review enabled.

metadata:

allowed-tools: Bash(gh:*) Bash(git:*)

---

<!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->

# Codexloop

Drive a GitHub PR until Codex has no unresolved review comments, **but do not cargo-cult its

suggestions.** Every comment is a *claim to verify*, not an instruction to obey. A wrong

suggestion applied is worse than the comment itself.

## How Codex differs from Greptile / Gemini

- **No check-run, no score.** Codex does not publish an `X/5` confidence or a named check. It posts

a **PR review** (state `COMMENTED`) plus inline review comments. Detection is by polling the

- **Trigger phrase is `@codex review`.** Codex reviews automatically when a PR opens or gets new

commits if auto-review is enabled on the repo; the mention forces a fresh pass. Other useful

mentions: `@codex review focus on <area>` for a scoped re-review.

- **Priority, not confidence.** Codex findings usually lead with a severity/priority word (`P1`,

`P2`, `P3` or `critical`/`major`/`minor`) or a short titled heading. Weight the top tier

seriously; treat the bottom tier as usually-skippable nits unless clearly correct.

- **Codex is terse and often reasons from the diff alone.** Its characteristic failure is

confidently asserting a bug based only on the changed hunk, without the surrounding file or the

call sites. That makes "read the whole file before believing it" the single highest-value check.

## Not for

- GitLab / Perforce (Codex code review is a GitHub app). For other review bots this catalog ships

`copilotloop`, `geminiloop`, `coderabbitloop`, and `qodoloop`; for CI failures rather than review comments, use

`ci-fix-loop`.

## 0. Resolve the Codex bot login (do this first, do not hardcode)

The connector's bot login varies by installation, so discover it from the PR rather than

assuming it:

```bash

gh api repos/{owner}/{repo}/pulls/<PR>/reviews --paginate --jq '.[].user.login' | sort -u

gh api repos/{owner}/{repo}/pulls/<PR>/comments --paginate --jq '.[].user.login' | sort -u

```

Pick the login matching `*codex*` (commonly `chatgpt-codex-connector[bot]`, sometimes

`codex[bot]`) and export it as `BOT`.

**Finding nothing here is NOT a stop condition.** On a PR Codex has never reviewed there is no bot

login to find yet: that is the normal starting state, not a missing app. When the probe comes back

until then match any login containing `codex` when polling. Only conclude the app is absent after

then say so and stop, rather than looping against nothing.

## 1. Identify the PR

```bash

gh pr view --json number,headRefName,headRefOid -q '{number,branch:.headRefName,head:.headRefOid}'

```

Switch to the PR branch if not already on it. Capture `OWNER`/`REPO` (`gh repo view --json owner,name`).

## 2. The loop (max 5 iterations)

At the end of every invocation, post exactly one top-level PR conversation comment summarizing

the result, including iterations, comments fixed, comments rebutted, and anything remaining. This

is required even when the loop times out or reaches its iteration cap; report that state honestly.

End the comment with: **Useful? React with 👍 / 👎.** Do not post a separate summary comment for

each iteration.

Keep an explicit iteration counter and stop at 5: the cap is a real bound to enforce, not a

figure of speech. Each pass through A–G is one iteration; on hitting the cap, go straight to the

report and list what is still unresolved rather than starting a sixth.

```bash

```

### B. Fetch the findings

spread.

```bash

```

Mark each unresolved comment as seen, so the bot and a watching human can tell it is being handled.

GitHub's reaction set is fixed; `eyes` is the only "looking at it" value:

```bash

gh api --method POST repos/{owner}/{repo}/pulls/comments/<COMMENT_ID>/reactions -f content=eyes

```

### C. Critically evaluate EACH comment (the core of this skill)

For every comment, **verify the claim against the actual code and repo conventions before touching

anything.** Read the whole file, not just the diff hunk Codex saw, plus the types and the call

sites. Then classify:

1. **CORRECT + actionable**: the finding is real and the fix improves the code. → fix it (step D).

2. **FALSE POSITIVE / technically wrong**: the claim doesn't hold. → do **NOT** change code; write a

specific, evidence-based reply (cite the exact code/line/behavior that disproves it), then resolve.

3. **Valid but out-of-scope / stylistic nit** that conflicts with repo convention or the PR's intent

→ briefly decline with a reason, then resolve. Do not expand the PR's scope to satisfy a nit.

**Hard rules:**

- **Never modify correct code just to silence Codex.** Prefer a reasoned rebuttal.

- When uncertain whether a claim holds, **investigate** (read more code, run the type-checker / tests)

rather than assume Codex is right. Default to skepticism.

- If a suggested change would break other call sites, alter public behavior, or contradict a verified

repo convention, it is a category-2 rebuttal, not a fix.

- Never fabricate identifiers to satisfy a comment (e.g. a Linear/ticket prefix). If Codex asks for a

ticket reference and none exists, say so; do not invent one.

**Codex's common failure modes to watch for (default these to category 2):**

- Diff-local reasoning: asserts a bug that the unchanged surrounding code already handles.

- "This can be null/undefined here" where the type or an earlier guard already rules it out.

- Invented race conditions or error paths with no actual trigger.

- Suggestions that compile-break or break other callers.

- Security/perf warnings with no exploit path or measurable cost.

- Restating library/framework semantics incorrectly.

- Style demands that contradict the repo's existing, consistent pattern.

### D. Apply fixes: category 1 only

Make the minimal correct change. Re-run the local gate if the repo has one (typecheck/tests) before

moving on.

### E. Commit and push FIRST, before resolving anything

Order matters. A resolved thread is a claim that the fix is on the branch, so the push has to

succeed before the claim is made: otherwise a failed commit or push leaves the PR unfixed with the

finding marked resolved, and nobody looks at it again.

If step D changed code:

```bash

# Stage ONLY the files your fixes touched: never `git add -A`, which sweeps up

# unrelated work and untracked secrets sitting in the worktree.

git status --short # look before you stage

git add <path> [<path>...] # the files named in the findings you fixed

git commit -m "address codex review feedback (codexloop iteration N)"

git push

```

Author the commit per the repo's norms (e.g. the user's identity; no AI attribution if that is the

convention). Confirm the push actually landed before continuing:

```bash

git rev-parse HEAD

gh pr view <PR> --json headRefOid -q .headRefOid # must match

```

If they differ, stop: the fix is not on the PR, so nothing may be resolved yet.

Every fixed Codex thread must be replied to and resolved after this push is verified. A fix is not

complete while its thread remains unresolved. If no code changed, rebutted threads can be replied

to and resolved without a push.

### F. Reply to and resolve every addressed thread

Reply on a thread's comment via `gh api repos/{owner}/{repo}/pulls/<PR>/comments -f body="..." -F in_reply_to=<comment_id>`,

then resolve:

```bash

gh api graphql -f query='mutation { resolveReviewThread(input: {threadId: "THREAD_ID"}) { thread { isResolved } } }'

```

Then record the disposition as a reaction on the bot's own comment: the learning signal, and a

visible marker for a human scanning the PR:

- 👍 (`+1`): the finding was accepted and fixed.

- 👎 (`-1`): the finding was rebutted as a false positive. **This is the correction signal.**

```bash

gh api --method POST repos/{owner}/{repo}/pulls/comments/<COMMENT_ID>/reactions -f content=+1

# rebutted finding:

gh api --method POST repos/{owner}/{repo}/pulls/comments/<COMMENT_ID>/reactions -f content=-1

```

Reply first, then react, then resolve: the reaction is not a substitute for the reply, and a

resolved thread with no reply loses the reasoning.

blanket-resolve, and never resolve a human reviewer's thread. For each fixed comment, verify the

push first, reply with the change made, then resolve the thread and verify `isResolved: true`.

For each rebutted comment, reply with the evidence and verify resolution. Do not report a comment

as fixed or rebutted until its thread is confirmed resolved.

Threads you are **rebutting** need no push, so they may be replied to and resolved regardless of

whether step D changed code.

## 3. Exit conditions

Stop when **any** is true:

## 4. Report

```text

Codexloop complete.

PR: #<n>

Bot login: <resolved $BOT>

Iterations: N

Comments fixed: N (genuinely-correct findings)

Comments rebutted: N (false positives / nits, resolved with rationale)

```

If it stopped at max iterations, list the remaining threads with your current assessment

(fix-pending vs disputed) so a human can arbitrate.