claude-review check fails on OIDC token fetch despite id-token: write being declared

[rey-ms]

The claude-review check fails during authentication, before it reviews anything — it dies in ~24s, where a real review run takes minutes. Every other check on the PR passes.

Reporting the observations rather than a root cause, because the run history doesn't fit a single clean explanation (details below).

Symptom

Run: https://github.com/JSv4/Docxodus/actions/runs/30828296388 (PR #337, a fork PR)

Requesting OIDC token...
Failed to get OIDC token: error: Error message: Unable to get ACTIONS_ID_TOKEN_REQUEST_URL env variable
    at /home/runner/work/_actions/anthropics/claude-code-action/v1/node_modules/@actions/core/lib/oidc-utils.js:71:27

Action failed with error: Could not fetch an OIDC token.
  Did you remember to add `id-token: write` to your workflow permissions?
Process completed with exit code 1

The action's hint is misleading here

id-token: write is already declared in .github/workflows/claude-code-review.yml:

    permissions:
      contents: read
      pull-requests: read
      issues: read
      id-token: write

That file hasn't changed since 3a412b3 (2026-07-07), so the same declaration was in place for both the failing and the succeeding runs below. So the suggested fix in the error message doesn't apply — something is preventing the permission from being granted, not from being requested.

Run history (Claude Code Review, most recent first)

Result	Started (UTC)	From a fork?	Branch
failure	2026-08-03 15:36	yes	pr/word-compare-parity (#337)
success	2026-08-03 13:08	no	fix/nvca-list-numbering-screenshot
success	2026-08-03 12:22	no	fix/nvca-list-numbering-screenshot
success	2026-08-03 11:59	no	fix/nvca-list-numbering-screenshot
success	2026-08-03 11:58	no	fix/nvca-list-numbering-screenshot
skipped	2026-08-03 11:48	no	dependabot/... (skipped by the existing guard)
skipped	2026-08-03 11:47	no	dependabot/...
failure	2026-08-03 02:32	no	fix/331-docx-compression (#333)
failure	2026-08-03 01:26	no	issue-330-tracked-surgical-replacements
failure	2026-08-03 00:07	no	smoke-test-mcp-round-three
failure	2026-08-02 23:26	no	smoke-test-mcp-round-three
failure	2026-08-02 21:48	no	agent/issue-319-tracked-formatting
failure	2026-08-02 21:48	no	agent/issue-317-comment-threads
failure	2026-08-02 21:47	no	agent/issue-316-mcp-header-footer

Two things stand out:

1. The earlier failures were not fork PRs. Seven consecutive same-repo runs failed (Aug 2 21:47 → Aug 3 02:32) with the same OIDC error — I spot-checked Fix DOCX output compression loss #333's log and it matches. So this is not purely a fork restriction.
2. It then recovered for same-repo PRs (four successes, 11:58 → 13:08) and failed again on the only fork-originated run.

That pattern is consistent with a fork-PR restriction being one cause (a pull_request run from a fork gets a read-only token and no secrets/OIDC by design — the same restriction your dependabot comment already documents), but it does not explain the earlier same-repo cluster. There may be two things going on, or something environmental in that window.

Questions

• Is claude-review intended to run on fork PRs at all? If not, extending the existing dependabot guard to cover forks (e.g. also skipping when github.event.pull_request.head.repo.fork) would turn a permanently-red, uncontributor-fixable check into a clean skip — the same reasoning as the comment already in the workflow:

  Dependabot PRs never get repository secrets (including CLAUDE_CODE_OAUTH_TOKEN) on pull_request-triggered runs — that's a GitHub security restriction, not something this workflow can work around. Skip the job there instead of showing a permanently-red, unfixable check on every dependency-bump PR.

• Was the Aug 2–3 same-repo failure cluster known/expected? If those were a separate transient problem, the fork case may be the only remaining one.

Not blocking

Nothing here suggests a problem with the PR's contents — build-and-test, test, build-npm and all three build-matrix legs pass. Filing this only so the red check on external PRs is explainable, and in case the earlier same-repo cluster points at something real.