Workflows that use the action fail. GitHub redirects most things when a repository is renamed, but its documentation says it will not redirect calls to an action hosted by a renamed repository, and the run errors with a repository not found message. That is a reliability issue first, and a name reuse risk second.
What GitHub says
The renaming documentation says that all existing information, with exception of project site URLs, is redirected to the new name, and that git operations on the old location keep working. Then it carves out actions: GitHub will not redirect calls to an action hosted by a renamed repository. Workflows that use it fail with a repository not found error.
The recommended fix for action authors is to create a new repository and action under the new name and archive the old repository.
Why that matters to a consumer
For the person who uses the action, three things follow.
- Builds can break without any change on your side. A maintainer renames a repository, and your next run fails.
- The failure is loud, which is better than the alternative, but it is still an outage for pipelines that deploy.
- The old name is a shared concern. The documentation warns that if someone later creates a repository with the original name, redirects to the renamed repository no longer work. For git links this is an inconvenience. For an action reference it raises a question worth asking: who controls the old name now?
The name reuse concern, stated carefully
Nothing in the documentation says a reused name is automatically dangerous. The concern is a general one: a reference by owner and repository name is a reference to whoever holds that name at run time. A reference by commit SHA narrows the risk, because the commit has to exist in the repository that holds the name. GitHub's guidance says to verify the SHA comes from the action's own repository and not a fork.
That is also why a pinned SHA and a periodic check that the repository still belongs to the expected owner work well together. For a longer treatment of this attack class, see what is repo-jacking.
What to do about it
| Situation | Action |
|---|---|
| Your build fails with repository not found for an action | Check whether the repository was renamed or removed, then update the reference and re-pin to a SHA |
| You depend on an action that matters to a release | Mirror or fork it into your organization, and review changes when you sync |
| You maintain an action | Avoid renaming; if you must, publish under the new name and archive the old repository, and tell users |
| You want early warning | Keep an inventory of every action and its owner, and review it on a schedule |
Try it yourself
Click through it at your own pace, or open it full screen. Notice that each dependency has a source and a version, which is the minimum you want recorded for every action too.
Write the failure down in your runbook
A renamed action is a predictable failure. Put a line in your pipeline runbook: if a third-party action fails with repository not found, check the repository status, find the new location, review it, update and pin. That turns a surprise into a ten-minute task.
Quick check
Does git clone of a renamed repository still work?
Yes, GitHub documents that git operations on the previous location continue to work. Action references are the exception.
Does pinning to a SHA prevent the failure?
No. A pinned SHA still points at an owner and repository name. If the name is gone, the reference fails. Pinning protects the content, not the address.
Sources
Last reviewed: 19 October 2026.
