Skip PR preview deploy for fork pull requests

[d-morrison]

Summary

• Fixes the failing Quarto Preview job on PR Add Elaine Wang profile to team page #77 (https://github.com/UCD-SERG/ucd-serg.github.io/actions/runs/30663427667/job/91264763960?pr=77)
• The job's Deploy PR Preview step (rossjrw/pr-preview-action@main) failed with:

  remote: Permission to UCD-SERG/ucd-serg.github.io.git denied to github-actions[bot].
  fatal: unable to access '...': The requested URL returned error: 403
  

• Root cause: PR Add Elaine Wang profile to team page #77 comes from a fork (imelainew/ucd-serg.github.io). For pull_request events from forks, GitHub always issues a read-only GITHUB_TOKEN, no matter what permissions: the workflow declares. rossjrw/pr-preview-action's current major version explicitly does not support fork PRs ("will do so in the upcoming v2"), so the deploy step can never succeed for a forked PR — it will always 403.
• Fix: skip the build-deploy job entirely when the PR's head repo isn't this repo, so forked-PR CI shows as skipped/neutral instead of a hard failure. Same-repo branch PRs (the common case here) are unaffected.

Also investigated

Per the same request, looked into why https://ucd-serg.github.io/pr-preview/pr-86/team.html doesn't show Everlyn Kamau (PR #86). That's a separate, unrelated content issue in PR #86's branch (ekamau-patch-2), not touched by this PR — reported separately in chat.

Test plan

• Confirm a subsequent push to a forked PR (e.g. PR Add Elaine Wang profile to team page #77) shows the preview job as skipped rather than failing
• Confirm same-repo branch PRs (e.g. PR add ekamau website bio #86) still build and deploy previews normally

---

Generated by Claude Code

[github-actions]

PR Preview Action v1.8.1-2-g6ad689f
Preview removed because the pull request was closed.
2026-08-01 05:45 UTC

[d-morrison]

The claude-review check failure here is unrelated to this PR's diff: it's failing with App token exchange failed: 401 Unauthorized - Invalid OIDC token in the claude-code-action setup step, before any review runs. That's an OIDC/credentials issue on the Claude Code Review app integration, and it's intermittent across the repo — it also failed on the latest run against main itself (run 30663424918) and on other unrelated branches, and has succeeded on other runs. Nothing in this PR (a two-line change to .github/workflows/preview.yml) can affect that token exchange, so no fix is needed here — flagging it in case it needs attention on the Anthropic/GitHub App integration side.

The Quarto Preview job itself now passes and deployed a preview successfully, confirming the fix.

---

Generated by Claude Code

[d-morrison]

The new build-deploy failure here is expected and confirms the warning-to-error check works as intended:

WARN: The listing in 'team.qmd' using the following contents:
- people/ekamau/bio-ekamau.qmd
doesn't match any files or folders.
##[error]A Quarto listing references a file or folder that doesn't exist (see WARN above). Fix the listing contents or add the missing file.

This is a pre-existing content issue already on main (team.qmd references people/ekamau/bio-ekamau.qmd, but that file doesn't exist there yet — it's only added, in the wrong location, on PR #86's branch). It's not caused by this PR's diff.

I'm holding off on changing team.qmd here since there are two reasonable ways to unblock this and it's not my call: (1) fix team.qmd in this PR to unblock CI now, with the entry restored once PR #86 lands with corrected file paths, or (2) leave this PR red until PR #86 (or another commit) fixes the ekamau file paths. Following up with the repo owner on which they'd prefer.

---

Generated by Claude Code

[d-morrison]

Pushed a follow-up commit disabling the broken postdocs listing in team.qmd (the people/ekamau/bio-ekamau.qmd entry) per your instruction, since that file doesn't exist at that path on this branch yet. build-deploy is green again — confirmed via the render log (no more unmatched-listing warning) and the updated preview-deploy comment above.

Remaining mergeable_state: blocked looks like it's just the still-failing claude-review check (the unrelated OIDC issue flagged earlier) and/or a pending review approval — not something introduced by this PR's diff.

---

Generated by Claude Code

[d-morrison]

Update: merged main in to pick up #89's fix for the claude-review OIDC failure (turns out it was pull_request_target's OIDC tokens being rejected by Anthropic's token-exchange endpoint — see anthropics/claude-code-action#713 — now reverted to pull_request).

All checks are green on the current commit: build-deploy, claude-review, Spellcheck, lint-project, CodeFactor. This PR just needs a review/approval to merge.

---

Generated by Claude Code

[d-morrison]

Correction — #91's fix did not actually resolve this. This run (commit de1673e, main's fix already merged in, and this PR doesn't touch the workflow file itself so it wasn't skipped by validation) still shows:

"permission_denials_count": 17
...
No buffered inline comments

That's more denials than the pre-fix run had (17 vs. 8), and still zero claude comments or reviews on this PR. So declaring pull-requests: write in the workflow YAML isn't sufficient by itself.

My guess: this repository (or org) likely has Settings → Actions → General → Workflow permissions set to "Read repository contents permission" (read-only) as the default. That setting acts as a hard ceiling — a workflow's own permissions: block can only narrow it, never widen beyond it. If that's the case, every GITHUB_TOKEN issued in this repo is capped to read regardless of what any individual workflow YAML declares, and no workflow-level YAML change can fix it. That setting can only be checked/changed by someone with admin access to the repo (or org) — I don't have visibility into it from here.

Could someone with admin access check that setting? If it's set to read-only, flipping it to "Read and write permissions" (the repo-wide default, not a per-workflow override) should be the actual fix — at which point #91's pull-requests: write becomes meaningful instead of a no-op.

---

Generated by Claude Code

[d-morrison]

Correction #2 — my "org default Workflow permissions" theory was wrong too (repo Settings → Actions confirms "Read and write permissions" is already the default). Different root cause, and this time I have solid evidence for it.

permission_denials_count isn't a GitHub API/token permission error at all — it's Claude Code's own tool-permission gate, entirely separate from GITHUB_TOKEN scope. The code-review plugin's own command source posts reviews via exactly two mechanisms:

• gh pr comment (a Bash tool call) for the summary
• mcp__github_inline_comment__create_inline_comment (an MCP tool) for inline comments

Neither is in Claude Code's default allowed-tools set for a non-interactive run, so every attempt to call them is auto-denied (no human present to approve the prompt) — that's what permission_denials_count is counting, and it explains why the number went up after #91: with pull-requests: write in place, Claude now has somewhere to try posting and keeps retrying/failing across turns, instead of giving up earlier.

The workflow file already has the fix half-written as a dead comment:

# claude_args: '--allowed-tools Bash(gh pr *)'

Opening a PR that uncomments/extends this to cover both tools the plugin actually calls.

---

Generated by Claude Code

[d-morrison]

Progress update on this run (commit c90a584, with #92's allowed-tools fix merged in): permission_denials_count dropped from 17 → 1, and it did real work this time (33 turns vs. ~10-11 before) — so the --allowed-tools fix is mostly working. But it's still 1 denial short of actually posting: still No buffered inline comments and zero claude comments/reviews here.

The action hides Claude's detailed tool-call stream by default ("full output hidden for security"), so I can't see which specific call is still being denied from the log alone — I only get the count. Rather than guess a third time, opening a small diagnostic PR to set show_full_output: true temporarily so the next run's log shows exactly which tool call is still blocked, then I'll fix that precisely and turn verbose output back off.

---

Generated by Claude Code

[d-morrison]

Diagnosis complete, thanks to #93's verbose log. The narrow claude_args from #92 was itself the bug: --allowed-tools replaces the effective tool allowlist rather than adding to it, so it denied the plugin's own read-side steps too (gh pr diff, gh pr view, etc.) — the agent never even reached gh pr comment or the inline-comment tool. Fetched the plugin's real source directly this time and matched claude_args to its own declared allowed-tools frontmatter exactly. Opened #94 with the fix and reverted #93's temporary show_full_output.

---

Generated by Claude Code

[d-morrison]

This run (commit 91d02aa, #94's corrected allowed-tools) looks like the fix actually worked, just not in a way this specific PR can prove: allowedTools in the SDK options now correctly shows the full 8-item list, and the run itself was clean — 14 turns, $0.24, 33s, only 1 remaining denial (almost certainly the same harmless recursive Skill self-call seen before, unrelated to posting). That's a big change from the earlier runs (10-11 turns burning $1.60-2.05 while failing repeatedly) — this looks like a normal, complete run rather than one hitting a wall.

Still zero comments here, but I think that's because this specific PR is a small, workflow-only YAML diff — the plugin's own step 1 explicitly tells it to skip PRs that are "trivial" or "obviously correct" without commenting. So the silence here is plausibly the plugin working as designed, not still broken.

I don't want to keep re-enabling show_full_output to chase this further on a PR that may just never get a comment by design. The real confirmation will come from the next PR with substantive code changes that runs through this fixed workflow (e.g. once #86 is corrected and re-synced with main) — if a claude review appears there, the fix chain (#89 → #91 → #92 → #93 → #94) is fully validated.

---

Generated by Claude Code