GitHub put workflow lockfiles for GitHub Actions into public preview on October 14. A lockfile records the exact commit behind every action a workflow uses, including the actions those actions pull in and any reusable workflows, and runs then execute those recorded commits even if a tag or branch is later moved. The problem it targets: a workflow you reviewed last month can run different code today, because the v4 it points at is a label someone can repoint. GitHub changelog
For teams whose CI now runs coding agents, third-party review bots and a growing pile of marketplace actions, the feature reopens a practical choice: keep hand-pinning SHAs in YAML, or adopt a lockfile and enforce it by policy. GitHub does not frame the feature around AI agents. That angle is ours.
What shipped
| Item | Detail |
|---|---|
| Status | Public preview (lockfiles and the enforcement policy) |
| Plans | Free, Team, Enterprise Cloud, Enterprise Cloud with data residency |
| Tooling | gh actions-lock, a GitHub CLI extension from the public gh-actions-lock repository |
| File | .github/workflows/actions.lock, committed and reviewed like any other change |
| Scope | Actions, their transitive dependencies, reusable workflow dependencies |
| Enforcement | “Require lockfile” policy for enterprise, organization and repository admins |
| Dependabot | Regenerates the matching lockfile entry in the same version-update pull request, for onboarded workflows |
All rows: GitHub changelog. An editor’s note on that page updated the plan list on launch day, so check it again before planning around a particular tier.
Adoption is per workflow. Once a workflow is onboarded, every dependency it uses needs an entry in the lockfile. The CLI can also confirm the lockfile is current without changing any files, which is meant to run as a CI check. The changelog does not name the subcommand for that check, so read the extension’s own documentation rather than guessing at flags. GitHub changelog
Why SHA pinning wasn’t enough
GitHub’s docs tell users to pin third-party actions to a commit SHA, warning that a tag can be moved or deleted if a bad actor gains access to the repository storing the action. Its secure-use reference now describes a dependency lockfile as the stronger option, superseding SHA pinning for repositories that adopt one. GitHub Docs: secure use reference
The gap is in what a uses: line can reach. Pinning some-org/deploy@<sha> freezes that action’s code. If it is a composite action that itself calls other actions by tag, those inner references can still move, and nothing in your YAML shows them. Reusable workflows have the same shape. The lockfile extends the pin through the whole dependency tree, the part hand-pinning never covered. GitHub changelog
Where it helps agent-driven CI
A CI job that runs a coding agent usually needs a model API key and often a token that can push or comment on the repository. The actions that wrap those agents are newer than the checkout and setup actions most teams have used for years, and fewer people have read their source. A moved tag in one of them would run with whatever permissions the job grants.
A lockfile turns that silent change into a diff. Any new commit for a dependency has to land as an edit to actions.lock, which goes through the same pull-request review as code. With the “Require lockfile” policy turned on at the organization level, a team can make that the rule rather than a convention that one repository forgets. The changelog does not say whether the policy blocks an unlocked run outright or only warns, so verify the behavior in a test repository before relying on it as a hard gate. GitHub changelog
What it doesn’t do
GitHub is explicit that locking a dependency says nothing about whether it is safe, and tells users to review dependencies before locking them. GitHub changelog If a compromised commit is already in place when you generate the lockfile, you have pinned the compromise. The same goes for a Dependabot update: the lockfile entry regenerates in the same pull request, which makes the change reviewable, and a reviewer who approves version bumps on sight gets no protection from it.
There is also friction. Per-workflow onboarding means a repository with many workflows is partly locked until someone finishes the job, and the stale-lockfile check will fail builds whenever a workflow edit adds a dependency without updating the file. That is the point, but it lands on whoever edits workflows, including agents that open pull requests against them.
Several things are not stated on the launch page: a general-availability date, availability on GitHub Enterprise Server, the lockfile’s internal format, and how the policy treats a dependency that is already SHA-pinned in YAML. Treat all four as open. GitHub changelog
What to test this week
- Onboard one workflow that uses a composite action or a reusable workflow, and read the generated
actions.lockto see how many transitive entries appear that your YAML never mentioned. - Add the up-to-date check to CI, then open a pull request that adds an action without updating the lockfile and confirm it fails.
- Turn on “Require lockfile” in a sandbox repository and record what an unlocked workflow does: blocked, warned, or allowed.
- Let Dependabot open an action update on the onboarded workflow and check that the lockfile diff is legible enough for a reviewer to judge.
- If agents edit workflow files in your repositories, check whether they can regenerate the lockfile, and decide whether they should be allowed to.
Preview feedback goes to GitHub’s community discussion or the gh-actions-lock issue tracker. GitHub changelog
Related: Anthropic keys now blocked on push
A day earlier, on October 13, GitHub added secret scanning detectors for Anthropic API keys, anthropic_service_api_key and anthropic_user_api_key, and put both in push protection by default. Commits containing either are blocked in repositories with secret scanning enabled, free public repositories included. The same update added a cloudsmith_api_key detector and brought Salesforce in as a secret scanning partner for salesforce_marketing_cloud_api_oauth2_token, so tokens found in public repositories go to Salesforce to revoke or rotate. The changelog does not say whether the Cloudsmith or Salesforce types are push-protected by default. GitHub changelog
Teams building with Claude should expect blocked pushes wherever a key sits in a config file, test fixture or example script. The fix is to move the key into Actions secrets or an environment variable and rotate any key that has already been committed. Neither change replaces review. The source map that shipped inside an npm package in the Claude Code source leak would not have been caught by a lockfile or a secret detector; someone had to notice what was in the release. Both features make specific mistakes louder: a moved dependency now shows up as a diff, and a committed Anthropic key now stops the push.