iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
actions/checkout v7 blocks certain fork pull-request checkouts by default in privileged workflows; the official documentation does not establish that this change required a 362KB credential-isolation rewrite. The fork-safety default is a v7 change. The project documents storing persisted credentials in a separate file under $RUNNER_TEMP as a distinct v6 change.
What changed in actions/checkout v7?
GitHub announced v7 as generally available on June 18, 2026. In workflows triggered by pull_request_target, checkout refuses to fetch code from fork pull requests by default. In workflow_run, the restriction applies when the upstream workflow was triggered by a pull_request* event. The change does not disable all fork pull-request workflows: GitHub says same-repository pull requests are unaffected, and the behavior of the pull_request event is unchanged. GitHub’s v7 announcement and the checkout README describe the behavior.
The opt-in input is allow-unsafe-pr-checkout: true. It permits the otherwise-blocked checkout pattern; it does not make execution of untrusted code safe.
Why does blocking fork code matter in privileged workflows?
pull_request_target runs workflow code from the base repository’s default branch. That context can have access to secrets and a read/write token. The danger arises if a workflow also checks out and executes code controlled by a fork: malicious commands in build scripts, tests, dependencies, or configuration could then run with the privileged workflow’s access.
#1 Best Overall
GitHub’s security guidance explains the distinction: “No code from the fork is executed by default.” A workflow that changes this by checking out and running fork code changes the threat model. See GitHub’s guidance on securely using pull_request_target.
Is the 362KB credential-isolation rewrite claim verified?
No. The official sources reviewed do not establish the 362KB figure or show that a credential-isolation rewrite was required for v7’s fork-checkout safety behavior. The project’s README and changelog describe the changes separately: the credential-storage change appears in v6, while v7 introduces the safer default for fork checkouts along with other updates.
In v6, persisted credentials moved from direct storage in .git/config to a separate file under $RUNNER_TEMP. That is a documented credential-handling change, but it should not be presented as the cause of v7’s fork-safety default or as evidence for a 362KB rewrite.
Recommended Free Tools
How should maintainers choose a safe workflow design?
Before opting in to fork checkout, answer these questions for the specific workflow:
- Which event triggers it? Consider whether
pull_requestcan meet the need instead of a privileged trigger. - What happens to the fork’s code? Inspecting files as data is different from executing scripts, tests, dependencies, or other contributor-controlled content.
- Does the job need secrets or write permissions? If not, avoid granting them. If it does, identify exactly why and where they are needed.
- Can the work be split? Separate untrusted pull-request processing from secret-bearing operations when that meets the workflow’s requirements.
- Is the opt-in justified? Review the code paths that could execute and the permissions available to the job before setting
allow-unsafe-pr-checkout: true.
GitHub recommends considering pull_request when secrets are unnecessary, or restructuring work so processing untrusted pull-request changes is separated from operations that use secrets. The right choice depends on the workflow’s permissions and what it actually executes; the opt-in input is not a general security fix.
What should you check when upgrading?
GitHub’s announcement was updated on July 15, 2026, to revise the backport enforcement date to July 20 and clarify that v1 would not receive the change. Supported floating major tags pick up the backport automatically; workflows pinned to a SHA, minor version, or patch version need an explicit upgrade. Because supported versions and rollout status can change, check the current GitHub announcement and project README when planning an upgrade.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
