Review mode: expired GitHub App token silently fails submit_pending_pull_request_review, job still reports success

[Mearman]

Ran into this on novus-power/hive PR #1979 (a trivial 4-line diagnostic-logging change). The review job (mode: review, workflow_run trigger) took over an hour end to end -- it hit a context-compaction/resume partway through, which pushed the run well past the GitHub App installation token's TTL.

By the time the agent got to submitting the review, every mcp__github__ call started failing with:

failed to get current user: non-200 OK status code: 401 Unauthorized body: "{\r\n  \"message\": \"Bad credentials\",\r\n  \"documentation_url\": \"https://docs.github.com/rest\",\r\n  \"status\": \"401\"\r\n}"

It had already called create_pending_pull_request_review successfully (token still valid then), then add_comment_to_pending_review failed on an unrelated GraphQL validation error (missing subjectType), then after the compaction/resume, submit_pending_pull_request_review failed twice with the 401 above. The job's own top-level conclusion was still "success" -- nothing surfaced this failure anywhere a human or the calling workflow could see it. The PR sat with reviewDecision: REVIEW_REQUIRED indefinitely, with zero reviews ever actually posted, and no comment/error visible anywhere on the PR itself.

Two separate things worth fixing:

1. The App token should be refreshed if it's stale before the final review-submission call, not just minted once at job start -- the reusable action already has an OIDC exchange for the App token (this exact repo's claude-review.yml comment mentions id-token: write for it), so a mid-run refresh should be mechanically possible.
2. Regardless of (1), a submit_pending_pull_request_review failure (or any core review-submission tool failure) should make the job itself fail rather than reporting success -- silent failure here means the calling repo's own claude-review.yml can never distinguish "genuinely nothing to say" from "the review never actually happened."

Workaround used on the affected PR: manually re-ran the same review job (gh run rerun), which completed within the token's TTL the second time.

Triage summary

• Kind: Bug report.
• Area: Review mode's App-identity (OIDC) path in action.yml -- specifically the pinned anthropics/claude-code-action call's token minting/TTL, and the lack of a post-hoc check confirming a review was actually submitted.
• Duplicates: None found among this repo's open/closed issues.
• Severity: Silent failure (green run, no review posted, no visible error) on a narrow but real path -- App-identity review, long session with a compaction/resume, workflow_run-triggered timing. First-hand reproduction with real tool-call logs from novus-power/hive, not just a claim of urgency.
• Two separable asks: (1) mid-session App-token refresh -- likely an upstream (anthropics/claude-code-action) concern, not fixable in this wrapper's action.yml alone; (2) failing the job when submit_pending_pull_request_review never succeeds -- addressable here, e.g. a review-mode analogue of the existing triage-only "verify actual output" check around action.yml:2121.
• Missing info: confirmation of which trigger (workflow_run vs. the documented pull_request) is required to reproduce the token-TTL timing.
• Labelled: bug.

[claude]

What this looks like: A real bug report (not a duplicate of anything else open in this repo) about the App-identity review path: submit_pending_pull_request_review (and add_comment_to_pending_review) failing with a stale OIDC-minted App installation token on a long-running review session, with the job's own top-level conclusion still reporting success. Area: action.yml's review-mode call to the upstream anthropics/claude-code-action (pinned at v1.0.208, e.g. action.yml:1389) and its App-token minting, which happens entirely inside that upstream package, not in this wrapper.

Severity: no data is at risk, but the failure mode is silent and the workaround (manual gh run rerun) isn't discoverable from anything the run itself surfaces -- reviewDecision: REVIEW_REQUIRED with zero reviews and a green Actions run gives no signal to a human or to any calling workflow that nothing happened. This is a first-hand reproduction with real tool-call output, not just "the reporter says it's urgent," so I'd weigh it as more than cosmetic even though it's narrow in when it triggers (App-identity/OIDC path, a session long enough to hit a context-compaction resume, and a workflow_run trigger rather than the pull_request trigger this repo's own direct example documents).

Two things worth separating, since they need different fixes:

1. Refreshing the App token mid-session isn't something this wrapper's action.yml controls -- the OIDC exchange and token lifetime are internal to the pinned anthropics/claude-code-action release. If this needs fixing, it likely needs raising upstream (or picking it up via a future bump through this repo's own "Automated upstream bumps" pipeline), not a change here.
2. "The job should fail rather than report success" is more addressable in this wrapper. action.yml already has an analogous pattern for triage mode (the "Verify triage actually posted something" step, around action.yml:2121) that re-checks GitHub's own state rather than trusting the model's self-report -- but that check is triage-only. There's no equivalent for review mode: structured_review_summary (action.yml:2052 onward) does re-fetch what was actually submitted, but it's opt-in (off by default), and per its own documented behaviour "a schema-validation failure in that follow-up call only leaves structured_output empty, it cannot fail the review itself" -- so even with it enabled today, a genuinely-missing review wouldn't fail the job.

What is missing: which trigger the affected repo (novus-power/hive) actually runs its review job from -- the reporter says workflow_run, which isn't the pattern this repo's own examples/direct/claude-review.yml documents (that one triggers on pull_request directly, with id-token: write for the same App-token OIDC exchange). Confirming whether the long compaction/resume delay is specific to workflow_run's own startup lag, or can also happen on the documented pull_request trigger, would narrow the fix.

Suggested next step: given (2) above, the more tractable fix here is a review-mode equivalent of the triage verification step at action.yml:2121 -- after the primary review call, unconditionally re-check (via gh api repos/{owner}/{repo}/pulls/{pr}/reviews, not gated behind structured_review_summary) whether a review was actually submitted for this run's HEAD SHA, and fail the job loudly if not, the same way action.yml:1686-1689 already does for the "Claude Code never ran at all" case. That would turn this specific failure mode into a visible red run instead of a silent no-op, independent of whether the token-refresh gap ever gets fixed upstream.

Labelled: bug.

[github-actions]

🗜️ Headroom context compression

Metric	Value
Requests proxied	26
Tokens saved	40636
Aggregate savings	1.7% of all tokens sent
Average per-request compression	2.3%