antigravity/gemini review workflows use SUBMODULES_TOKEN to check out the caller's own repo, which fails for cross-owner consumers

[d-morrison]

antigravity-code-review.yml and gemini-code-review.yml pass
SUBMODULES_TOKEN as the token for checking out the caller's own
repository. When that token is scoped to a different owner --- which is the
only reason a repo sets it --- the checkout fails before the reviewer runs.

Observed

ucdavis/bcs#612, run
31338714703, job
review / antigravity-review:

Syncing repository: ucdavis/bcs
  persist-credentials: false
  submodules: true
  token: ***
[command]/usr/bin/git remote add origin https://github.com/ucdavis/bcs
##[group]Fetching the repository
##[error]fatal: could not read Username for 'https://github.com': terminal prompts disabled
The process '/usr/bin/git' failed with exit code 128

Three attempts, all identical. The failure is on the main repository fetch,
not the submodule.

Mechanism

The three review workflows do not agree on what SUBMODULES_TOKEN is for.

Workflow	Main-repo checkout token	Submodule handling
claude-code-review.yml	default github.token (no token: input)	separate checkout-submodules composite action, given submodules-token
antigravity-code-review.yml	${{ secrets.SUBMODULES_TOKEN || github.token }}	submodules: input on the same checkout
gemini-code-review.yml	${{ secrets.SUBMODULES_TOKEN || github.token }}	same

claude-code-review.yml has it right: the caller's own repo is checked out with
the token the runner already has, and SUBMODULES_TOKEN is used only where a
cross-owner fetch actually needs it. Its own comment says so.

The other two conflate the two roles. SUBMODULES_TOKEN exists precisely
because the submodule lives under a different owner than the consumer --- in
ucdavis/bcs it reaches Morrison-Lab/ai-config --- so a token that can read
the submodule has no reason to be able to read ucdavis/bcs, and here it
cannot.

Note the || fallback does not help and actively hides the problem: it fires
only when SUBMODULES_TOKEN is unset. A repo that sets it correctly for its
submodule is exactly the repo that breaks, so the workflows work fine until
someone configures them the way the docs ask.

Blast radius

antigravity-code-review.yml has run once, ever, and that run is the
failure above:

gh run list -R ucdavis/bcs --workflow antigravity-code-review.yml --limit 30 \
  --json conclusion,createdAt,headBranch
#=> a single row: 2026-08-09T22:10  failure  ci/check-secrets-610

It has never succeeded because no PR had drawn it before --- ai-code-review.yml
picks one agent per PR at random from claude, gemini, antigravity, so a broken
agent stays invisible until its number comes up. That is worth fixing
independently of the token: a selector that can route a PR to an agent which has
never worked will keep producing a red check and no review, on a random third of
PRs.

I have not verified the Gemini path empirically --- it may or may not have been
drawn in ucdavis/bcs --- but it carries the identical token: line, so treat
it as affected by inspection rather than as untested.

Suggested fix

Drop the token: input from both checkouts so the main repo uses the runner's
own token, and move submodule authentication to the same
.github/actions/checkout-submodules composite claude-code-review.yml
already uses. That makes all three consistent and removes the conflation
outright.

A regression test would need a fixture whose SUBMODULES_TOKEN is valid for a
different owner than the caller, which is awkward; a cheaper guard is a lint
asserting that no review workflow passes SUBMODULES_TOKEN to a top-level
actions/checkout token: input.

Found while wiring up check-secrets in ucdavis/bcs (PR #612), which is the
PR that drew Antigravity.

[d-morrison]

Additional data from ucdavis/bcs, on how long this can stay invisible.

Of the three agents in that repo's pool, only Claude has ever produced a review:

workflow	runs ever in ucdavis/bcs
claude-code-review.yml	many, succeeding
antigravity-code-review.yml	1, the failure in this issue
gemini-code-review.yml	0

gh run list -R ucdavis/bcs --workflow gemini-code-review.yml --limit 20 \
  --json conclusion,createdAt,headBranch    # returns nothing

So Gemini remains untested rather than proven broken --- I am not upgrading
the by-inspection claim in the issue body. The point is the reverse: two of the
three pool members had never run at all since #578 added them on 2026-08-07, so
the random selector concealed the defect for two days and would have kept
concealing it.

One more thing worth confirming when this is fixed: the selector does not
fall through when a dispatched agent fails. Its header says it falls through
"if one cannot be dispatched", and Antigravity dispatched fine and then died
during checkout --- so ucdavis/bcs#612 ended up with a red check and no review
at all, until I dispatched Claude by hand. If that is the intended behaviour it
is worth saying so; if not, a dispatched-but-failed agent probably wants the
same fallthrough.

[d-morrison]

Third data point, from the same PR (ucdavis/bcs#612) across three pushes:

head	agent dispatched	outcome
98719439	claude-review	cancelled by the next push
d7d1ca75	antigravity-review	failure (this issue)
4ae6f46e	antigravity-review	failure (this issue)

I am not claiming the selector is deterministic --- two draws in a row at
1/3 is a 1-in-9 coincidence and this is a sample of three. What the table does
show is the practical cost: one PR has now consumed three automatic review
dispatches and received zero automatic reviews. The only review it has is
one I dispatched by hand.

That is worth weighing when prioritising this. The per-PR failure rate is
whatever the selector's draw rate is, but the failures are not independent
across a PR's lifetime in the way a per-push rate suggests --- every push
re-rolls, so a PR that keeps getting the broken agent keeps getting no review,
and nothing about the PR's own state tells the author that is what happened.
The check is red, which reads as an ordinary CI failure rather than as
"your reviewer never ran".

[d-morrison]

Gemini is now confirmed broken, not just affected by inspection.

I was careful earlier not to upgrade that claim without evidence. Here it is.

ucdavis/bcs#612 pushed a new head at 23:01, the selector drew Gemini, and
run 31340870156
failed identically to the Antigravity runs:

  token: ***
Syncing repository: ucdavis/bcs
##[error]fatal: could not read Username for 'https://github.com': terminal prompts disabled
The process '/usr/bin/git' failed with exit code 128

Three attempts, same message, failing on the main repository fetch --- the
same signature, same step, same cause as antigravity-code-review.yml. Both
carry token: ${{ secrets.SUBMODULES_TOKEN || github.token }} on the top-level
checkout; claude-code-review.yml does not, and works.

So the scoreboard for ucdavis/bcs is now:

agent	runs	successes
claude-code-review	many	many
antigravity-code-review	2	0
gemini-code-review	1	0

That changes the severity. It is not one broken agent in a pool of three --- it
is two of three, so roughly two thirds of PRs in any repo that sets
SUBMODULES_TOKEN for a cross-owner submodule get a red check and no review.
The failure is silent in the way that matters: the check is red, which reads as
an ordinary CI failure rather than as "your reviewer never ran".

Note the shared root also means a fix to one is a fix to both, and the fix is
the same one line in each: drop the token: input so the main checkout uses the
runner's own token, and move submodule auth to the
.github/actions/checkout-submodules composite that
claude-code-review.yml already uses.

The lint I suggested in the issue body --- asserting that no review workflow
passes SUBMODULES_TOKEN to a top-level actions/checkout token: input ---
would have caught both at authoring time.

[d-morrison]

Adding the scope from the consumer side, since the issue documents the mechanism but not how much review coverage it costs.

Every run of each reviewer workflow in ucdavis/bcs, derived rather than sampled:

for wf in claude-code-review.yml gemini-code-review.yml antigravity-code-review.yml; do
  gh run list -R ucdavis/bcs --workflow "$wf" --limit 100 --json conclusion --jq '
    [.[].conclusion] as $c
    | "total=\($c|length) success=\([$c[]|select(.=="success")]|length) failure=\([$c[]|select(.=="failure")]|length)"'
done

Workflow	Total runs	Success	Failure
claude-code-review.yml	100 (capped)	66	7
gemini-code-review.yml	2	0	2
antigravity-code-review.yml	6	0	6

So in this consumer neither workflow has ever produced a verdict --- 0 for 8 between them, every failure the could not read Username checkout error above.

Why that is worse than an 8-run outage. ucdavis/bcs's ai-code-review.yml sets agents: 'claude, gemini, antigravity' and the reusable workflow selects one at random per PR. Two of the three can never succeed, so roughly two PRs in three get no AI review at all --- and the caller's own ai-review / select-and-review check reports pass regardless, because dispatching is what it verifies, not reviewing. Measured on ucdavis/bcs#614 just now: select-and-review green, antigravity dispatched, run 31353937138 failed on this bug, zero review comments on the PR.

That is the shape review-verdict-pitfalls calls a check that cannot fail on its own content, so its green carries no signal --- here sitting on the one job whose purpose is to secure a review.

Not proposing a fix beyond what the issue already specifies (claude-code-review.yml's split is the right model). Flagging the priority: until this lands, a bcs PR's review coverage is a coin flip that nothing on the PR page reveals.

Found while driving ucdavis/bcs#614; no duplicate filed.