GitHub Actions adds workflow lockfiles in public preview to keep dependency commits fixed
GitHub announced workflow dependency lockfiles in public preview on October 14, 2026. The changelog lists availability for GitHub Enterprise Cloud, Enterprise Cloud with data residency, Team and Free plans. Its same-day editor's note updates the plans with access. This is a public preview, not a general-availability announcement or a claim that every workflow already uses locking.
The feature addresses the risk that an action's tag or branch can move after a workflow has been reviewed. A lockfile keeps an onboarded workflow running the exact dependency commits it recorded, even if those references later change. This can limit unexpected dependency changes, but GitHub explicitly says locking does not determine whether a dependency is itself safe.
To create and maintain the file, GitHub directs users to the gh actions-lock extension for the GitHub CLI. It generates .github/workflows/actions.lock with reviewable commits for actions, their transitive dependencies and reusable workflow dependencies. Teams should review those dependencies and the generated workflow changes before committing them.
Adoption can proceed one workflow at a time. Once a workflow is onboarded, its dependencies must have lockfile entries and GitHub Actions uses the recorded commits. The extension can also check whether a lockfile is current without modifying files, including as a continuous-integration check. The announcement does not say that installation alone onboards every workflow.
GitHub also placed its Require lockfile policy in public preview. Enterprise, organization and repository administrators can use that policy to require workflow lockfiles at their respective levels. A policy requirement and a dependency safety review remain different controls: forcing a recorded commit does not certify the code inside that commit.
For workflows already onboarded, Dependabot regenerates the matching lockfile entry when it opens an action version update, keeping the changed workflow reference and locked commit together in the same pull request without extra configuration. Teams should review both parts of that update. The practical benefit is consistent, reviewable dependency versions, not a promise to prevent every compromised dependency or secure an entire AI deployment pipeline.