Check what GitHub Actions workflow lockfiles pin before adopting them

Which plans are included, and what changes?

The October 14 announcement covers Enterprise Cloud, Enterprise Cloud with data residency, Team, and Free. This is a public preview and may change. You can retain tag or branch references in workflows while pinning execution to locked commits.

This addresses cases where an upstream tag moves after you review it. Locking does not assess dependency safety. It fixes the code under review, but a malicious commit you select will still run.

How do you generate and maintain the lockfile?

The official concept documentation says to generate .github/workflows/actions.lock with the GitHub CLI extension gh actions-lock. Never edit this generated file by hand. Follow the installation guidance, then compare the generated dependency references and commits.

The file records workflow dependencies and the commits their references resolve to, along with numeric identifiers for source repositories. Every dependency of an onboarded workflow must be present. Runs use the recorded commit, which is also the commit checked by allowed actions policies.

Are reusable workflow internals locked too?

The lockfile includes transitive action dependencies: actions called by other actions. It also locks reusable workflow calls, but dependencies inside a reusable workflow use the lockfile in the repository where that workflow is defined. Treating the caller's file as control over all internal dependencies would misstate its scope.

As preparation, consider drawing the call relationships. When you find an external reusable workflow, ask its owning team whether locking is in place. If different people review the caller and update its internal actions, agree on which changes each person reviews.

What should you check before requiring it across an organization?

You can onboard workflows gradually. The Require lockfile policy lets enterprise, organization, and repository administrators require locking. When Dependabot opens an action version update for an onboarded workflow, it regenerates the matching entry in the same PR to synchronize the reference and commit.

For your team's rollout, consider this sequence.

1. Choose a CI workflow with a clear owner and compare its dependencies with the generated commit changes.
2. Check locking separately in repositories that provide reusable workflows.
3. Review both references and lockfile entries in a Dependabot update PR.
4. Identify remaining workflows and update owners before considering a mandatory policy.

Enforcing the policy first could block workflows that have not been onboarded. Before enforcement, compare the intended scope with the workflows actually listed in the lockfile. Official sources were checked on October 17, 2026.