Version 7 blocks unsafe fork checkout by default
Actions Checkout solves the first mundane requirement in most GitHub workflows: put the right repository state under GITHUB_WORKSPACE. Version 7 adds an important refusal. A workflow triggered by pull_request_target or workflow_run will not fetch fork pull-request code unless allow-unsafe-pr-checkout is explicitly set. Those events can carry the base repository's token, secrets, cache scope, and runner access, so the safer default prevents a common route from untrusted code to trusted credentials.
For ordinary push and pull_request jobs, the interface stays familiar. uses: actions/checkout@v7 fetches the triggering ref and persists the workflow token so later Git commands can authenticate. That convenience deserves a conscious decision: set persist-credentials: false when later steps should have no push-capable credential. For another private repository, the built-in token usually lacks access, and the README tells users to provide a least-privilege personal access token instead.
The default checkout contains only 1 commit
A plain checkout fetches one commit and does not fetch tags. This is fast and sufficient for compilers or unit tests that only need the current tree. It is wrong for version calculation, changelog generation, merge-base analysis, or a script that compares earlier tags. Set fetch-depth: 0 for all branches and tags, or choose a small positive depth when the job has a known lookback. The default is a product decision, not a transparent copy of a normal long-lived clone.
The action also handles sparse checkout, partial-clone filters, submodules, and Git LFS. Multiple repositories can sit beside each other or be nested under the main checkout. If Git 2.18 or newer is missing, checkout falls back to GitHub's REST API for files. That fallback cannot preserve every Git operation. Teams running old or stripped-down images should test the exact inputs they use rather than assuming the downloaded tree behaves like a repository cloned by Git.
What happened when we ran it
Our sandbox installed 530 npm packages in 13 seconds and used 167 MB on disk. The build completed in 12 seconds. Jest then passed all 128 tests in 10 seconds with 0 failures. The repository scan counted 98 files, about 7,586 lines of source, and 7 CI workflow files. It found no Dockerfile and no top-level tests directory, though the configured test command clearly discovered and ran the suite.
Npm audit reported 4 known vulnerabilities: 0 critical, 2 high, 1 moderate, and 1 low. The test result shows the checked-out code behaved as its suite expected; it does not cancel dependency advisories. For a component that executes inside CI and handles credentials, those findings deserve review before an organization blesses a pinned revision. Our measurements apply to commit f548e57 in the stated Node 22 sandbox, while the hosted action itself declares its bundled Node runtime through action metadata.
Node 24 sets a floor for self-hosted runners
Checkout v7 moved to Node 24 and requires Actions Runner v2.327.1 or later. Hosted GitHub runners absorb that compatibility work. Self-hosted fleets do not, so the upgrade belongs in the rollout checklist before changing the workflow reference. The README also notes that v6's separate credential file needs Runner v2.329.0 or later when authenticated Git commands run from a Docker container action. Major tags may look interchangeable in YAML while requiring different runner plumbing.
Issue 2393 gives one concrete self-hosted edge case for v6. A macOS runner used a symlinked _work directory, but Git evaluated the persisted credential include against the resolved path. The paths did not match, so authenticated fetch failed. The report does not establish the same fault in v7. It does show why runner filesystem layout, Git path resolution, and credential storage matter when a job moves away from GitHub's standard images.
GitHub accepts bug reports but not ordinary contributions
GitHub recorded the last repository push on August 10, 2026. Release v7.0.1 was published July 20 with pull-request safety changes, branch whitespace handling, escaped unset values, and dependency updates. The repository had 8,666 stars and 686 open issues and pull requests when fetched. That combined count is noisy for a widely used official action, but current issue updates show that users are still reporting runner and network behavior.
The maintenance model is unusually explicit. The README says the team is not taking contributions, while security updates and fixes for major breaking changes will continue. Questions and high-priority reports are directed to GitHub Community or Support. That is acceptable for a vendor-owned building block, though it removes the normal open-source expectation that a good external patch can merge. Choose it for supported GitHub integration, not for a community-governed checkout engine.
Pinning the commit is the stricter supply-chain choice
A major reference such as actions/checkout@v7 is readable and receives compatible updates, but the tag can point to newer code later. An exact commit SHA makes the executed source reviewable and repeatable. Teams can use an update bot to propose SHA changes while keeping the major version in a comment for humans. Issue 2316 asks the project to use GitHub's immutable release feature, which shows that release-reference integrity remains an active concern.
Actions Checkout is still the sensible default because it understands GitHub's token, events, workspace, and cleanup lifecycle. The 128 passing tests make its checked-out commit easy to trust functionally, while the 4 audit findings prevent a blank security endorsement. Use v7, request only contents: read unless the job must write, fetch the history the job truly needs, and treat credentials as an input you own rather than invisible workflow plumbing.