Priority Level
High
Task Summary
Harden the Agentic CI PR review workflow so maintainer-approved fork PRs can be reviewed without exposing secrets, repository credentials, or the self-hosted runner to fork-controlled code and project configuration.
PR #795 upgrades actions/checkout to v7, which blocks fork PR checkout from pull_request_target workflows unless allow-unsafe-pr-checkout: true is set. As a short-term compatibility decision, #795 will explicitly opt in so behavior remains equivalent to the existing checkout v6 workflow. This issue tracks replacing that accepted risk with a hardened design.
Technical Details & Implementation Plan
Suggested approach:
- Resolve and validate immutable PR context before any checkout:
- PR number
- base SHA
- head SHA
- head repository
- whether the PR comes from a fork
- Keep the existing full Claude Code review path for same-repository PRs.
- For fork PRs, use a hardened diff-only path:
- Do not check out the fork.
- Do not run repository scripts, tests, hooks, project settings, or Claude Code tools.
- Fetch PR metadata, changed file names, and the diff through GitHub using the validated PR number and head SHA.
- Treat all PR metadata and diff content as untrusted data.
- Send only that inert review payload to the model through a tool-free API request.
- Set
persist-credentials: false on checkouts and avoid making a write-capable repository token available to the model process.
- Preserve explicit maintainer authorization for fork reviews and bind approval to the reviewed head SHA. A changed head must require fresh authorization.
- Minimize workflow permissions and isolate secret-bearing steps. Prefer an ephemeral runner for any job processing untrusted input.
- Audit or disable project-controlled Claude settings, hooks, and instruction files anywhere untrusted content can be present.
- Add workflow validation for:
- same-repository PRs
- maintainer-approved fork PRs
- fork head changes after approval
- manual
workflow_dispatch of a fork PR
- missing model configuration and API failures
Acceptance criteria:
- Fork PR review does not check out or execute fork-controlled content.
- Fork-controlled project configuration cannot run on the self-hosted runner.
- Repository credentials are not persisted in the checkout.
- Authorization is tied to an immutable head SHA.
- Same-repository review behavior remains unchanged.
- The workflow still posts a useful advisory review or an explicit incomplete-review result.
Investigation / Context
The current workflow was intentionally moved to pull_request_target in #541 so approved fork PR reviews could access the model configuration and secrets. Existing safeguards include collaborator/label gating, an agentic-ci environment gate, and loading review recipes and tools from the base branch.
Those controls reduce exposure but do not fully isolate untrusted content:
- The fork working tree is placed on a self-hosted runner.
actions/checkout persists the repository token by default.
- Claude Code runs with
GH_TOKEN and model API credentials while inspecting untrusted content.
- Prompt injection, project-controlled configuration, hooks, or tool execution could potentially read and exfiltrate credentials.
Checkout v7 made this trust boundary explicit by requiring allow-unsafe-pr-checkout: true for fork PR heads in pull_request_target and workflow_run workflows: actions/checkout#2454
Related: #795 and #541.
Agent Plan / Findings
Implement the fork/non-fork split first. The preferred fork path is metadata-plus-diff review through a direct, tool-free model request. This retains useful automated review while removing the need to place fork code in the secret-bearing workspace.
After implementation, validate workflow syntax locally and perform a controlled fork PR smoke test. Confirm that the reviewed SHA appears in workflow logs and that updating the fork requires new authorization.
Dependencies
Short-term compatibility opt-in in PR #795.
Priority Level
High
Task Summary
Harden the Agentic CI PR review workflow so maintainer-approved fork PRs can be reviewed without exposing secrets, repository credentials, or the self-hosted runner to fork-controlled code and project configuration.
PR #795 upgrades
actions/checkoutto v7, which blocks fork PR checkout frompull_request_targetworkflows unlessallow-unsafe-pr-checkout: trueis set. As a short-term compatibility decision, #795 will explicitly opt in so behavior remains equivalent to the existing checkout v6 workflow. This issue tracks replacing that accepted risk with a hardened design.Technical Details & Implementation Plan
Suggested approach:
persist-credentials: falseon checkouts and avoid making a write-capable repository token available to the model process.workflow_dispatchof a fork PRAcceptance criteria:
Investigation / Context
The current workflow was intentionally moved to
pull_request_targetin #541 so approved fork PR reviews could access the model configuration and secrets. Existing safeguards include collaborator/label gating, anagentic-cienvironment gate, and loading review recipes and tools from the base branch.Those controls reduce exposure but do not fully isolate untrusted content:
actions/checkoutpersists the repository token by default.GH_TOKENand model API credentials while inspecting untrusted content.Checkout v7 made this trust boundary explicit by requiring
allow-unsafe-pr-checkout: truefor fork PR heads inpull_request_targetandworkflow_runworkflows: actions/checkout#2454Related: #795 and #541.
Agent Plan / Findings
Implement the fork/non-fork split first. The preferred fork path is metadata-plus-diff review through a direct, tool-free model request. This retains useful automated review while removing the need to place fork code in the secret-bearing workspace.
After implementation, validate workflow syntax locally and perform a controlled fork PR smoke test. Confirm that the reviewed SHA appears in workflow logs and that updating the fork requires new authorization.
Dependencies
Short-term compatibility opt-in in PR #795.