Code review setup can pass stale merge-base, causing reviewers to inspect unrelated main history

Summary

A Codex code-review thread was initialized with a hardcoded merge-base commit that was no longer the actual merge base between the PR branch and current main. Because the review prompt explicitly instructed the agent to run git diff <stale-merge-base>, the agent reviewed a huge unrelated diff containing hundreds of commits from main history instead of the actual PR diff.

Impact

This can produce false review findings against files that the PR did not change. In our case, multiple review attempts in separate Codex threads repeated the same mistake because they followed the stale merge-base instruction literally.

What Happened

1. PR branch was based on current main.
2. The real merge base from local git was current main.
3. The review prompt nevertheless supplied an older commit as “the merge base” and instructed:

``bash
git diff <stale-merge-base>
``

1. That command compared the PR checkout against an old main commit, so the diff included:

• all commits that landed on main after the stale commit
• plus the actual PR commits

1. Codex then reviewed unrelated changes and produced an invalid inline finding.

Expected Behavior

Before using a provided merge-base hash, Codex review should sanity-check it against the actual repository graph, for example:

git merge-base main HEAD

If the provided merge base differs from the actual merge base, the review should either:

• use the actual merge base/current PR diff, or
• stop and warn that the supplied review base is stale/inconsistent.

Observed Behavior

Codex treated the provided stale hash as authoritative and reviewed the wrong range. A second fresh Codex review thread did the same thing.

Suggested Fix

For review workflows, validate the supplied merge-base before running a broad diff:

• Resolve the current branch and base branch.
• Run git merge-base <base> HEAD.
• Compare it to any supplied merge-base value.
• If they differ, prefer the actual merge base or ask for confirmation.
• For GitHub PR reviews, prefer the GitHub PR changed-files/patch API as the source of truth when available.

This would prevent stale review metadata from causing false code-review comments.