e2e: actions/checkout@v7 rejects fork PR checkouts in pull_request_target workflow

[ralphbean]

What happens

After PR #2457 upgraded actions/checkout from v4 to v7, the e2e workflow fails on all fork PRs with:

##[error]Refusing to check out fork pull request code from a 'pull_request_target' workflow.
This workflow runs with the base repository's GITHUB_TOKEN, secrets, default-branch cache scope,
and runner access. Fetching and executing a fork's code in that trusted context commonly leads
to "pwn request" vulnerabilities. To opt in, review the risks at
https://gh.io/securely-using-pull_request_target and set 'allow-unsafe-pr-checkout: true'
on the actions/checkout step.

Observed on PR #2010 (run 27952613286). The job never reaches the test step — it fails at checkout.

What should happen

The e2e workflow should be able to check out fork PR code, with appropriate security controls. Before the v7 upgrade this worked because checkout v4 did not enforce the fork safety check.

Context

actions/checkout@v7 added a security guard that blocks fork PR checkouts in pull_request_target workflows by default. The e2e workflow uses pull_request_target because it needs access to secrets (GCP credentials, GitHub PAT) that aren't available to pull_request events on forks.

The ok-to-test label gate already provides a manual review step before e2e runs on fork PRs, which is the mitigation actions/checkout recommends verifying before opting in with allow-unsafe-pr-checkout: true.

This blocks e2e CI for all external contributors.

[fullsend-ai-triage]

🤖 Finished Triage · ✅ Success · Started 2:04 PM UTC · Completed 2:06 PM UTC
Commit: 4e21a60 · View workflow run →

[fullsend-ai-triage]

Triage Summary

This is a regression introduced by PR #2457, which upgraded actions/checkout from v4 to v7. The v7 action added a default-on security guard that blocks fork PR checkouts in pull_request_target workflows, breaking e2e CI for all external contributors.

Root Cause

actions/checkout@v7 refuses to check out fork PR code in pull_request_target workflows unless allow-unsafe-pr-checkout: true is explicitly set on the checkout step. This is a new security default that v4 did not enforce.

Recommended Fix

Add allow-unsafe-pr-checkout: true to the actions/checkout step(s) in the e2e workflow. The existing ok-to-test label gate already provides the manual maintainer review step that the checkout action recommends before opting in.

The developer should inspect all workflow files using pull_request_target with actions/checkout@v7 — particularly the e2e workflow and potentially reusable-dispatch.yml / the scaffold dispatch.yml.

Proposed Test Case

Scenario: Fork PR e2e checkout succeeds with ok-to-test label
  Given a PR opened from a fork
  And the ok-to-test label has been applied by a maintainer
  When the e2e workflow triggers
  Then the checkout step completes successfully
  And e2e tests proceed to execution

Edge case: Verify the ok-to-test label gate still blocks
  fork PRs without the label from running e2e tests.

---

Labels: Confirmed e2e/CI regression from a dependency upgrade, with significant impact on external contributor workflow.