AI Code Review on Fork PRs: The Secrets Problem

If your AI code reviewer suddenly goes silent on a pull request from an outside contributor, it’s almost never broken — it’s working exactly as GitHub designed it. Workflows triggered by a pull_request event from a fork run without access to your repository secrets. No secret means no LLM API key, and no API key means the reviewer can’t call the model. This is a deliberate security boundary, not a bug, and understanding it is the difference between a safe open-source review setup and a repository takeover waiting to happen.

This post explains why the boundary exists, what the tempting-but-dangerous workaround is, and how to review fork PRs without handing the keys to a stranger.

Key Takeaways

• Fork PRs run workflows without secrets, so any reviewer that needs an API key won’t run automatically on them.
• The common “fix,” pull_request_target, runs with secrets and write access — and is a well-documented way to get a repo compromised.
• The safe pattern is to have a maintainer trigger the review manually after reading the diff.
• Robin deliberately does not use pull_request_target; on fork PRs a maintainer comments /robin to run the review in the trusted base-repo context.

Why Don’t Fork PRs Get Secrets?

When someone forks your repository and opens a pull request, the code in that PR is untrusted by definition — it’s whatever they wrote, and you haven’t reviewed it yet. If GitHub handed your secrets to a workflow running that untrusted code, a malicious contributor could open a PR whose only purpose is to print LLM_API_KEY to the build log or exfiltrate it to their own server. They wouldn’t need write access to your repo; the workflow would leak the secret for them.

So GitHub draws a hard line: workflows triggered by pull_request from a fork get a read-only GITHUB_TOKEN and no access to secrets. Your LLM_API_KEY, LLM_BASE_URL, and anything else in repository or environment secrets are simply unavailable. The workflow still runs — linters, formatters, tests that need nothing secret all work fine — but anything requiring a credential silently fails or skips.

This is why an AI reviewer that’s perfectly happy on your own branches goes quiet the moment an external contributor opens a PR. The reviewer needs a key; the key isn’t there.

The Dangerous Shortcut: pull_request_target

There’s a GitHub Actions event that does expose secrets on fork PRs: pull_request_target. It runs in the context of the base repository — your repository — with access to secrets and, often, write permissions. On paper it solves the problem. In practice it’s one of the sharpest footguns in CI.

The danger is subtle. pull_request_target runs your base branch’s workflow, but if that workflow checks out and executes the PR’s code (a build step, a test run, an install script), you’re now running untrusted code with secrets and write access in scope. GitHub’s own security hardening guide is blunt about the class of risk: such workflows “may have repository write access and access to referenced secrets,” and it advises teams to “avoid using the pull_request_target workflow trigger if it’s not necessary” and to ensure workflows “must not explicitly check out untrusted code.” A single careless checkout step turns a code-review convenience into a credential leak.

The takeaway: pull_request_target is not a casual fix for “my reviewer needs secrets on fork PRs.” It’s a sharp tool that demands you never execute PR code, and getting that wrong has cost real projects their repositories.

The Safe Pattern: A Maintainer in the Loop

The clean answer keeps a human between an outside contributor and your secrets. Instead of trying to auto-run a secret-dependent reviewer on every fork PR, you let a maintainer trigger it deliberately after a glance at the diff.

This works because a maintainer’s comment or manual run executes in the trusted base-repository context — where secrets are available — without ever granting them to the untrusted fork event. The maintainer has already eyeballed the change for anything obviously hostile (a modified workflow file, a suspicious new script) before spending an API call on it. The review still happens; it just happens on a trusted trigger.

There’s one rule that makes this genuinely safe rather than just convenient: the triggered review must read the diff, not check out and execute the PR’s head code. A maintainer-triggered workflow still runs with secrets, so if it builds, installs, or runs the contributor’s code, it inherits the exact pull_request_target risk described above. The safe version reviews the diff text itself and never executes the PR’s code — so the secret is used only to call the model, never to run untrusted code. Robin works this way by design: it reviews the diff, it doesn’t run your contributor’s branch.

This is exactly how Robin handles it. Robin intentionally does not use pull_request_target — that event is skipped by design. On a normal branch, Robin reviews automatically when you open a PR. On a fork PR from an outside contributor, where secrets aren’t available, the automatic run simply can’t fire. A maintainer then comments /robin to trigger the review, which runs in the base-repo context with the key available. The control stays with the maintainer, and the API key never enters an untrusted execution path.

A Practical Setup for Open-Source Maintainers

If you maintain a public repository that takes outside contributions, here’s a workflow that stays safe:

1. Let normal CI run on fork PRs. Tests, linters, and type checks that need no secrets give you and the contributor immediate signal.
2. Don’t auto-run the AI reviewer on fork events. Accept that secret-dependent steps skip on forks. That’s the boundary doing its job.
3. Trigger review manually after a quick scan. Once you’ve glanced at the diff — especially any changes to workflow files — comment /robin (or your tool’s equivalent) to run the review on a trusted trigger.
4. Never reach for pull_request_target to “just make it work.” If you ever do use it, the workflow must not check out or execute the PR’s code, and it should not be the path your reviewer runs on.

For contributors on branches within your repository (not forks) — which is how most internal teams work — none of this applies. Secrets are available, and the reviewer runs automatically on every PR. The fork-secret problem is specific to outside contributions, and the manual-trigger pattern handles it cleanly.

Frequently Asked Questions

Why doesn’t my AI reviewer comment on pull requests from forks?

Because GitHub does not pass repository secrets to workflows triggered by a pull_request event from a fork. Your AI reviewer needs an API key, that key lives in secrets, and secrets are withheld on fork PRs for security. The reviewer isn’t broken — it has no credential to call the model with. Trigger it manually from a maintainer account instead.

Is pull_request_target safe to use for code review?

Only with extreme care. It exposes secrets and often write access, and if the workflow checks out or runs the PR’s untrusted code, it can leak those secrets or compromise the repository. GitHub’s guidance is to avoid it unless necessary and never to execute untrusted code in it. For AI review specifically, a maintainer-triggered run is a far safer pattern.

How does Robin review fork PRs?

Robin skips pull_request_target by design. Automatic reviews run on branches that have secret access; on fork PRs, where secrets aren’t available, a maintainer comments /robin to run the review in the trusted base-repository context. The API key is never exposed to the untrusted fork event.

Where to Go From Here

The fork-secret boundary is one of the few places where AI code review intersects with real CI security, and the safe pattern is simple once you see why it exists: keep a maintainer between outside code and your secrets. The Robin setup docs cover the workflow configuration in detail, including the events Robin listens on and why it avoids the risky ones. If you’re still choosing a reviewer, the AI code review tools page lays out which tools fit an open-source, outside-contributor workflow.