GitHub Actions · actions.lock · Checked November 5, 2026

"lockfile missing pin for …": GitHub Actions workflow lockfiles (actions.lock), the job that fails in Set up job, and how to regenerate the lockfile

Since October 28, 2026, a repository can lock the actions its workflows use, and the actions those actions use, in .github/workflows/actions.lock (GitHub changelog; public preview from October 14). The file is generated by gh actions-lock, an extension for the GitHub CLI, and workflows are onboarded one at a time. Once a workflow is onboarded, GitHub Actions runs the commits recorded in the lockfile, and every action the workflow uses must have an entry. When one is missing, the run usually stops before any step. The fix is to run gh actions-lock again and commit the workflow and the lockfile together, not to edit the lockfile by hand.

What it looks like

When an action that another action calls has no entry, every job of the workflow fails in Set up job, naming the action and the reference (msgvault #1740, November 2, 2026):

##[error]lockfile missing pin for actions/cache@55cc8345863c7cc4c66a329aec7e433d2d1c52a9

In that repository, every run on main and on every pull request failed this way after one merge, whatever the pull request changed, and re-running did not help. When the calling action comes from another repository, the log shows it being downloaded first (cicd-suite #33):

Download action repository 'hyperpolymath/cicd-suite@c5270b0e0a0a7177d6ee77fc4451f38978b612f0'
##[error]lockfile missing pin for hyperpolymath/deed-ecosystem@f9d999b60cb5f383679ea19912bcdc49c944973a

When a uses: line of the workflow itself has no entry, the run fails before any job starts, as an invalid workflow file that references actions not present in the lockfile (metadatastician/standards #784), with no jobs in the run (statistikles #117). Both reports are from before the public preview.

An action used with a ./ path is the exception. If it calls an action with no entry, the job fails when it reaches that step, and the steps before it have already run, GitHub's documentation says.

Why

The lockfile has two sections. workflows lists the references each onboarded workflow uses, and dependencies records, for each reference, the tag or branch, the commit, and the numeric owner_id and repo_id of the repository. Entries are keyed by owner/repo@ref, so the same commit under another ref, a SHA instead of a tag, has no entry. In msgvault, the lockfile recorded actions/cache@v6.1.0, and two composite actions in the repository, called as $/.github/actions/go-cache-restore and $/.github/actions/go-cache-save, used actions/cache/restore@55cc8345… # v6.1.0: the same commit, by SHA.

The usual ways to get there:

• A uses: line was added or changed, by hand or by a tool, without running gh actions-lock. Dependabot is the exception: for an onboarded workflow, its version update regenerates the matching entry in the same pull request. It does not onboard a workflow that is not in the lockfile yet.
• A composite action in your repository, called with $/, changed what it calls. The actions it calls use the same lockfile, so their references must match its keys.
• The extension dropped an entry. Updating an existing lockfile with versions 0.2.0 and 0.4.0 dropped an action that a composite action called as DeterminateSystems/nix-installer-action@v23, when the lockfile already had it in lower case, and the runner then stopped with "lockfile missing pin". In 0.4.0, --verify reports it as incomplete-lockfile, and gh actions-lock --relock restores it (gh-manage #71, in Japanese).

Fix

From the root of the repository:

gh extension upgrade gh-actions-lock
gh actions-lock --verify
gh actions-lock

--verify runs the same checks without changing any file, and names a category for each problem (below). The plain run adds the missing entries and removes the ones no workflow uses. It can also rewrite uses: lines to the version it resolved, so @v3 can become @v3.1.0 at the same commit. Review the whole diff, and commit the workflows and the lockfile together.

Or change the uses: line to the reference the lockfile already records. msgvault fixed it that way (msgvault #1727):

-      uses: actions/cache/restore@55cc8345863c7cc4c66a329aec7e433d2d1c52a9 # v6.1.0
+      uses: actions/cache/restore@v6.1.0

The extension's troubleshooting guide says not to edit the lockfile by hand, since the extension rejects entries that do not match their references, and not to delete it to make an error go away. Locked references are sticky: without the file, every reference resolves again to what it points to today, and a tag that moved is accepted without a warning. To undo changes, restore it from the default branch (here main) and regenerate it:

git fetch origin
git checkout origin/main -- .github/workflows/actions.lock
gh actions-lock

If an action used with a ./ path calls other actions, the extension reports a local-action error and writes nothing. gh actions-lock --migrate-local-actions rewrites ./ to $/, which runs the action at the workflow's own commit and locks what it calls. --ignore-local-actions keeps ./, and leaves what it calls without entries.

What gh actions-lock --verify reports

Each problem has a headline and a category. It exits with 0 when no errors remain, 1 when a finding blocks, and 2 when the tool itself failed, for example on a lockfile it cannot read. From the troubleshooting guide in the gh-actions-lock repository:

• "Not pinned" (not-pinned): a uses: dependency has no entry, or the message says "workflow has no lockfile entry". Run gh actions-lock.
• "Ref changed" (ref-changed): a uses: line changed, for example from v6.2.0 to v6, and the lockfile still has the old one. Run gh actions-lock, or revert the line.
• "Pinned commit not in upstream history" (unreachable-pin): the locked commit is no longer in the reference's history, after a force-push, a moved tag or an edited entry. Compare the upstream history first; then gh actions-lock --accept-moved, never in automation. A uses: line with a full SHA that no tag or branch contains gets the same error, since the commit may exist only in a fork.
• "Locked commit isn't the tag's commit" (tag-commit-mismatch): the entry for an exact tag such as v4.2.1 locks an older commit than the one the tag points at, because the tag moved or the entry was edited. Run gh actions-lock --relock. Version 0.2.0 gave this case the headline above (gh-actions-lock #202).
• "Repository replaced (identity changed)" (repo-replaced): the name now belongs to a different repository from the one locked. Do not relock under the same name; find where the action lives now.
• "OLD-NAME was renamed or transferred to NEW-NAME" (repo-renamed): the same repository under a new name. Run gh actions-lock to update the uses: name.
• "Lockfile doesn't match locked manifest" (incomplete-lockfile): a locked action's action.yml uses an action that its entry does not record. Run gh actions-lock --relock.
• "Lockfile is unreadable", exit code 2: usually a hand edit, a search and replace across the repository, or a merge conflict resolved wrongly. Restore it as above. One report (gh-actions-lock #166):

  Lockfile .github\workflows\actions.lock is unreadable (lockfile is unreadable: .github/workflows/actions.lock: line 144, column 14: action body ref "v1.0.17" does not match pin key ref "v2.0.0" for dependency "jessehouwing/actions-dependency-submission@v2.0.0"). Delete and recreate it?

  The extension offered to delete and recreate the file there. The guide says to restore it instead, since a new file resolves every reference again.

Adopting the lockfile

gh extension install github/gh-actions-lock
gh actions-lock

That onboards every workflow under .github/workflows; pass a path such as .github/workflows/ci.yml to onboard one. Before you commit, GitHub's documentation lists three things to check:

• The allowed actions setting. If the repository, organization or enterprise allows only specified actions, an onboarded workflow is checked by its locked SHAs, so an entry with a tag, such as actions/checkout@v6, no longer matches. Use a wildcard or the full SHA.
• Reusable workflows called with jobs.<job_id>.uses are not locked. Pin them by full SHA. What they use is covered by the lockfile of their own repository.
• The policy "Require actions to be pinned to a full-length commit SHA" is satisfied for onboarded workflows, so their uses: lines can keep tags. A workflow that is not in the lockfile still needs SHAs.

To keep it current, GitHub suggests a workflow that runs gh actions-lock --verify on pull requests as a required check (verify-lockfile.yml in the gh-actions-lock repository is an example), and the lockfile in CODEOWNERS, so that someone reviews each changed commit. Administrators can also set the Require lockfile policy, which blocks runs of the targeted workflows that are not onboarded, including workflows with no uses:, and the run of a workflow that calls a reusable workflow not onboarded in its own repository.

Telling it apart

• "lockfile missing pin for OWNER/REPO@REF" in Set up job: an action called by another action has no entry. This page.
• The run fails before any job, as an invalid workflow file that references actions not present in the lockfile: a uses: line of the workflow has no entry. The same fix. For other invalid files: "Invalid workflow file".
• "lockfile verification did not produce a result for this action", followed by "Unable to resolve action" and "the repository has been renamed or transferred. Run `gh actions-lock` to update the lockfile": the action's repository moved (gh-actions-lock #110, August 2026). Change the uses: line to the new name, then run gh actions-lock.
• "Unable to resolve action" without the lockfile in the message: the action or its reference could not be found ("Unable to resolve action"). A move without a lockfile fails that way too (the free-disk-space move).

See failed jobs from IntelliJ IDEA

Pipeline Inbox for GitHub Actions Workflows, a plugin by Lesstep for JetBrains IDEs 2024.1 or later, lists the runs of all your repositories in an IDE tool window, with their jobs and steps, so a run that stopped in Set up job stands out, and your current branch's runs are in the status bar. Reading is free; re-running failed jobs, cancelling, running workflows and reviewing deployments are Pro (US$1.50 a month, with a 30-day trial).

Get it on JetBrains Marketplace

GitHub and GitHub Actions are trademarks of GitHub, Inc.; IntelliJ IDEA is a trademark of JetBrains s.r.o. This page is not affiliated with, sponsored or endorsed by GitHub, Inc. or JetBrains.

More: "Unable to resolve action" · "Invalid workflow file" · the free-disk-space move · GitHub Actions plugins for IntelliJ IDEA compared · 日本語