fix(ci): restore fork filter for pull_request_review_comment events

[worktrunk-bot]

Problem

PR #1421 removed the fork filter (head.repo.full_name == github.repository) from the pull_request_review_comment trigger, based on the assumption that this event type has secret access for fork PRs like pull_request_target and issue_comment do.

This assumption was wrong — run 22914840420 failed at checkout with Input required and not supplied: token, confirming that pull_request_review_comment does not have secret access for fork PRs.

Solution

• Restore the fork filter (github.event.pull_request.head.repo.full_name == github.repository) in the if: condition
• Restore the workflow comment explaining the fork filter
• Restore the "Does not trigger" entry for fork PR inline review comments
• Add a new "Fork PR secret availability" reference table to .github/CLAUDE.md documenting which event types have secrets for fork PRs, to prevent this mistake from recurring

Testing

Workflow-only change — no code tests to run. The fix reverts the logic to the pre-#1421 state which was working correctly.

---

Closes #1424 — automated triage

[max-sixty]

I don't understand — we don't have access to the secrets from pull_request_review_comment but we do with pull_request_target and issue_comment?

can you really research this? we just want something that runs on any interaction, including comments on fork PRs...

[worktrunk-bot]

Good question — I dug into this properly.

Why the difference: It's a GitHub platform distinction based on which repo context the event runs in:

Event	Runs in context of	Secrets on fork PRs
pull_request_target	Base repo	Yes
issue_comment	Base repo	Yes
pull_request_review_comment	Fork repo	No
pull_request_review	Fork repo	No
pull_request	Fork repo	No

pull_request_target and issue_comment were specifically designed to run in the base repo's context (so maintainers can react to fork PRs with secrets). There's no equivalent pull_request_review_comment_target event — GitHub just never created one.

Run 22914840420 confirmed this: the pull_request_review_comment trigger on a fork PR failed at checkout with Input required and not supplied: token — the WORKTRUNK_BOT_TOKEN secret was empty.

Options for making inline review comments work on fork PRs:

1. workflow_run two-stage pipeline (GitHub's recommended workaround): A secretless pull_request_review_comment workflow saves the event payload as an artifact, then a workflow_run-triggered workflow downloads it and runs claude-code-action with secrets. This is the only approach that actually works, but adds significant complexity — two workflows, artifact passing, and claude-code-action would need to handle reconstructed event context rather than native GitHub event payloads.

2. Accept the gap (current PR): Fork PR users use conversation tab comments (issue_comment, which has secrets) instead of inline review comments. This is what the PR currently implements — restore the fork filter and document the limitation.

Given that fork PRs are relatively rare and conversation tab comments work fine for them, option 2 seems like the right trade-off — but happy to build the workflow_run pipeline if you'd prefer full coverage.

[max-sixty]

this seems like a strong claim and so needs stronger evidence — find primary sources + issues discussing this

[max-sixty]

didn't the bot respond here, for example: #1408 (comment)

(though later there stops responding!)

[worktrunk-bot]

Good catch — and this is exactly the kind of thing I should have traced before claiming it. I dug into the actual workflow runs for PR #1408 to answer both questions.

The bot's response at discussion_r2906398164 was NOT triggered by pull_request_review_comment. It was triggered by an issue_comment event — specifically your conversation comment at 15:54:48 UTC mentioning @worktrunk-bot. That fired issue_comment run 22862093653 (success, completed 16:03:20), and the bot posted its reply as a review comment via the API at 16:03:04.

Every pull_request_review_comment run on PR #1408 was skipped by the fork filter — all 6 of them. The bot's initial review was triggered by pull_request_target (run 22852797352, success).

"Later there stops responding" — exactly right. The later comments (2910069729, 2911871360) were pure review comments on the Files tab. These only trigger pull_request_review_comment (skipped for forks) — no issue_comment event was fired, so the bot was never invoked.

Primary sources on fork PR secret access

The GitHub docs on events state that for fork PRs, secrets are not passed to the runner (except a read-only GITHUB_TOKEN). The key distinction:

• pull_request_target and issue_comment run in the base repo's context → secrets available
• pull_request, pull_request_review, pull_request_review_comment run in the fork's context → no secrets

There is no pull_request_review_comment_target variant. This is a known gap — community discussion #55940 documents the same issue for pull_request_review, noting "it's the same issue as pull_request vs pull_request_target but there is no pull_request_review_target."

So the current state is actually working correctly for fork PRs — conversation tab comments (issue_comment) trigger the bot with secrets, while Files tab review comments (pull_request_review_comment) get filtered. The gap is only for inline review comments that don't have a corresponding conversation comment.

Given this, the PR as-is is the right fix — restore the fork filter and document the limitation. Want me to update the PR description to clarify this mechanism?

[max-sixty]

but this seems to suggest that the events are sent, no? https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows#pull-request-events-for-forked-repositories-2

Pull request events for forked repositories

For pull requests from a forked repository to the base repository, GitHub sends the pull_request, issue_comment, pull_request_review_comment, pull_request_review, and pull_request_target events to the base repository. No pull request events occur on the forked repository.

[worktrunk-bot]

You're right that the events are sent to the base repo — that quote is about event delivery (where the webhook goes), not about secret access. All five events fire on the base repo, but only some of them get secrets.

The primary source is the docs page you linked. Each event type has its own section, and the ones subject to fork restrictions have a "Workflows in forked repositories" subsection. Specifically:

• pull_request_review_comment has the subsection, which states: "With the exception of GITHUB_TOKEN, secrets are not passed to the runner when a workflow is triggered from a forked repository."
• issue_comment does not have this subsection — no fork restriction on secrets.
• pull_request_target explicitly says it "runs in the context of the default branch of the base repository" — secrets available by design.

The empirical evidence matches: run 22914840420 logs show Secret source: None for a pull_request_review_comment event on a fork PR, and checkout failed because WORKTRUNK_BOT_TOKEN was empty. Meanwhile issue_comment runs on the same fork PR (#1408) succeeded with secrets — e.g., run 22862093653.

So the table is: issue_comment and pull_request_target get secrets for fork PRs; pull_request, pull_request_review, and pull_request_review_comment do not.

[max-sixty]

OK, that does look reasonable.

Do lots of people complain about this? It seems like one very annoying hole in the approach, such that only in this tiny corner (inline comments on a forked PR) can a bot not be triggered by secrets? Search for places where people have raised this issue and what others do about it.

[worktrunk-bot]

Yes, it's a well-known pain point. There are several community discussions about the missing *_target variants:

• Discussion #55940 — directly about pull_request_review lacking a _target variant. A commenter says: "Too bad there isn't a pull_request_review_target event. Maybe one day more *_target events will be available." No GitHub response.
• Discussion #26651 — asks to elevate GITHUB_TOKEN permissions for pull_request_review on forks. No resolution.
• Discussion #50161 — general complaints about fork PR secret restrictions, 50+ comments.

What other bots do: Most accept the gap. AI review bots (CodeRabbit, Presubmit, claude-code-action) use pull_request_target for the initial automated review and issue_comment for follow-up interactions. None of them solve the inline review comment gap on fork PRs specifically — they just don't respond to those. claude-code-action#339 documents the same failure mode we hit.

The workflow_run two-stage pipeline (documented pattern, template) is the "proper" workaround, but I couldn't find any bot project actually using it for inline review comments — the complexity isn't worth it given that conversation tab comments (issue_comment) work fine as a fallback.

So the approach in this PR (filter fork PRs, document the limitation) matches what everyone else does. The gap only affects inline review comments on fork PRs specifically — a small enough corner that projects live with it.