The workflow file is no longer the whole dependency record.
A GitHub Actions step can name actions/checkout@v4 or another tag that is easy to read. Tags and branches can move. GitHub's new workflow dependency lockfile records the commit that the runner should execute. It also records the numeric owner and repository identifiers behind the name.[1][2]
The lockfile lives at .github/workflows/actions.lock. It covers direct actions and their transitive action dependencies. A reusable workflow keeps its own dependency lock in the repository where that workflow is defined.[2]
Readable intent stays in the workflow. Executable identity moves into a reviewed lockfile.
The clamp has two jaws.
The commit is one jaw. The repository identity is the other. A matching commit without the expected owner_id and repo_id is not the same dependency record. GitHub says the runner checks those identifiers so a repository rename, transfer, or replacement cannot pass as the source you locked.[2]
This improves on copying full commit hashes into every workflow line. The lockfile can include transitive actions and leaves the human-facing ref readable. It does not decide whether the locked code is safe. Review still happens before the clamp closes.[1]
A relock is a change, not maintenance dust.
The published command keeps existing pins sticky during a normal run. The --relock option resolves moved refs again. If the old commit is no longer reachable, the command still reports an error unless the operator also supplies --accept-moved.[3]
That extra flag deserves a real review. A changed commit changes the code that runs. A changed owner or repository identifier can mean that the name points to a different repository. The GitHub guide tells reviewers to investigate identity changes before merging them.[4]
The tool exists, and the preview label matters.
We downloaded the published Linux AMD64 binary for gh-actions-lock v0.2.0. The file was 11,456,696 bytes with SHA-256 79ec84c191667fd935a277e6fd3662cf5d3669cccc9e99998731d8f306f373b6. Its help output exposed read-only --verify and --verify-local modes, relocking controls, JSON output, host selection, and the default lockfile path.
We did not authenticate the extension to GitHub or run it against a repository. The repository calls the tool pre-1.0 and warns that flags, behavior, and the lockfile format can change during public preview.[3]
Review one packet.
- Review the workflow ref and the action source before the first lock.
- Review every direct and transitive commit recorded in the lockfile.
- Check owner and repository identifiers when a lock entry changes.
- Run a frozen verification in continuous integration. Keep relocking in a separate reviewed change.
The bench below drafts that review packet. It does not read a repository, generate a lockfile, contact GitHub, or approve any dependency.