Do GitHub OIDC trust policies break when a repository is renamed?

They can. A trust policy that matches a repository by name stops matching when the name changes, and GitHub's documentation says renames and transfers after 15 July 2026 move a repository to an immutable subject format with owner and repository IDs. Update the policy before you rename.

Why names are a weak identity

The classic GitHub subject is built from the owner and repository name, for example repo:ORG/REPO:ref:refs/heads/main. Names are labels people change. A rename fails closed in the happy case: the old policy no longer matches, and the deploy breaks. The worse case is a name that gets reused. If a repository is renamed and someone creates a new one under the old name, a policy keyed on the name may match the new, unrelated repository.

GitLab's guidance reflects the same worry. It recommends stable identifiers, noting that project_id is globally unique and unchanged for the life of the project, and warns that token issuance for a reused project path may be blocked until you switch to an ID based subject.

What GitHub changed

GitHub's documentation states:

• Repositories created after 15 July 2026 use an immutable default subject format.
• The format includes the owner and repository IDs, in the shape repo:OWNER@OWNER-ID/REPO@REPO-ID:ref:refs/heads/BRANCH.
• Repositories created before that date keep the previous format unless you opt in.
• Renames and transfers after that date also move a repository to the immutable format.
• GitHub Enterprise Server is not part of the rollout.

Customizing the subject claim, which administrators can do through the REST API, replaces the format for the entire claim. GitHub advises creating a matching condition in your cloud provider before customizing.

A safe rename procedure

1. List every cloud role and federated credential that references the repository. Search trust policies for the repository name.
2. Look up the new subject format from current GitHub documentation, or print the claims in a test job after a trial run.
3. Add the new subject to each trust policy next to the old one. For AWS, list both values in the condition. For Microsoft Entra, add a second federated credential, remembering the limit of 20 per app and that wildcards are unsupported.
4. Rename or transfer the repository.
5. Run a workflow that assumes each role and confirm success.
6. Remove the old subject from each policy.
7. Record the change so the next person knows why two formats appeared.

Prevention

• Use environments for deploy roles. The environment subject still includes the repository, so it needs the same update, but you get a single place to protect.
• Keep trust definitions in code, one file per role, so a search finds every reference.
• Prefer exact matches. A policy that uses a repository wildcard, which GitHub's AWS guide says allows any branch, pull request merge branch or environment, will not break on branch renames, but it is also too broad for a deploy role.
• Add a test: a scheduled job that assumes each role in a harmless way and alerts on failure. It will catch drift before a release day.

Transfers between organizations

A transfer changes the owner part of the subject as well. Treat it like a rename, with extra care: the destination owner may be able to create credentials in your cloud account only if your trust policy lets them, so do not widen the policy to "just work" during the move.

Quick check

Safeguard does not manage your cloud accounts. It scans your code and dependencies, applies pull request policies and gates, and automates compliance evidence. Free scan: gold.safeguard.sh/scan.

Sources

• GitHub Docs: OpenID Connect reference
• GitHub Docs: OpenID Connect concepts
• GitLab Docs: ID token authentication
• Microsoft Learn: Create a trust relationship between an app and an external identity provider

Last reviewed: 19 October 2026.