GitHub Actions lockfiles pin the code behind workflow dependencies

GitHub [announced on October 14](https://github.blog/changelog/2026‑10‑14‑github‑actions‑workflow‑lockfiles‑in‑public‑preview/) that workflow dependency lockfiles are in public preview for GitHub Enterprise Cloud, including Enterprise Cloud with data residency. A workflow can keep a readable reference such as `actions/checkout@v6`, while GitHub Actions runs the exact commit recorded in `.github/workflows/actions.lock`. That changes the execution boundary. A tag or branch can move after review, but an onboarded workflow resolves each listed dependency through the committed lockfile. The lock records the reference, commit and source repository identity. This protects against an unexpected reference move; it does not establish that the locked commit is trustworthy. Teams still need to review the dependency before accepting the pin.

GitHub's [lockfile concept guide](https://docs.github.com/en/enterprise‑cloud@latest/actions/concepts/security/workflow‑dependency‑lockfiles) says the file covers direct action dependencies and the transitive actions they invoke. It also records reusable workflow dependencies. The boundary matters for shared automation. Dependencies used inside a reusable workflow are governed by the lockfile in that reusable workflow's own repository, rather than by every caller's lockfile. Teams that maintain central workflows should onboard those repositories before relying on caller coverage. Local actions are rewritten to a repository‑relative reference that resolves to the running commit. Review the generated diff rather than editing the machine‑generated lockfile by hand.

The `gh actions‑lock` GitHub CLI extension can onboard workflows individually. Once a workflow is onboarded, each dependency needs a lockfile entry and GitHub runs the recorded commit. A verify command can detect stale entries before merge. GitHub also offers a Require lockfile policy at repository, organization and enterprise scope. The [enforcement guide](https://docs.github.com/en/actions/how‑tos/administer/enforce‑workflow‑lockfiles) recommends piloting selected repositories and workflows first. Turning the policy on before coverage and update automation are ready can block workflow runs. Use Evaluate mode where available, measure which workflows would fail and activate enforcement only after the intended scope is clean.

When Dependabot updates an action version in an onboarded workflow, GitHub says it regenerates the matching lockfile entry in the same pull request. That lets reviewers see the workflow reference and commit change together. Dependabot does not onboard a workflow that has no lockfile entries. New workflows and local‑action changes therefore still need a generation step, such as a dedicated workflow, a pre‑commit check or an agent instruction that runs the supported CLI. A useful required check runs verification on pull requests and fails when the lockfile is stale. Put the lockfile under CODEOWNERS so a security or build owner reviews commit changes.

Start with one repository and a workflow whose dependencies are already understood. Generate the lockfile, confirm the current workflow produces the same result, then deliberately update one action and inspect the changed commit and repository identifiers. Test the stale‑lockfile failure before activating a blocking policy. Document who regenerates the file, who reviews it and how an emergency dependency update is approved. Keep workflow allowlists aligned with locked commit SHAs during migration. The preview improves reproducibility and auditability, while dependency selection, maintainer trust and compromised code review remain separate controls. Follow [GitHub's OpenTools organization page](https://opentools.ai/organizations/github) for material Actions changes. *Image: Real screenshot of GitHub's official October 14 workflow‑lockfiles release page. OpenTools captured the source page without generative alteration or artificial upscaling.*