GitHub Actions workflow lockfiles are generally available: keep readable tag references while running only the locked commits, transitive dependencies included
Actions dependencies get a package-lock-style lock, so a moved tag cannot quietly swap in different code.
// Key points
- The gh actions-lock CLI extension generates .github/workflows/actions.lock covering actions and their transitive dependencies; Actions runs the locked commits even if tags or branches move.
- Workflows are onboarded one at a time, admins can apply a Require lockfile policy at the enterprise, organization or repository level, and a non-modifying stale-lockfile check can run in CI.
- Dependabot version updates for onboarded actions regenerate the matching lockfile entries in the same pull request.
- GitHub notes that lockfiles guard against unexpected changes but do not show a dependency is safe, so review before locking.
Builder's takeRead with the LiteLLM poisoning in the 10-24 issue, the supply-chain problem now reaches CI itself. I would lock the workflows that hold secrets and publish first, like this site's own release flow, then turn on Require lockfile at the repository level rather than waiting for a full migration.
// Background · from #Coding agents
Full timeline →- Oct 31 Claude Code 2.1.314 adds a setting that blocks writes outside the working directories in every permission mode
- Oct 31 GitHub Agent Merge comes to pull requests: Copilot watches a PR in the cloud and fixes failing Actions workflows and merge conflicts
- Oct 31 Copilot Automations can now be shared by a team: they belong to the repository, bill the repository's owner and keep running if the creator leaves