Before renaming a GitHub repository, check its cloud OIDC trust

A repository rename can also change the trusted subject

If an agent-maintained repository deploys through GitHub Actions, include cloud trust in the review of a planned rename or transfer. GitHub's current documentation says those operations after July 15, 2026 move repositories to the immutable OIDC subject format, including repositories that previously used name-only subjects.[1][3]

OpenID Connect (OIDC) lets a workflow present an identity token to a cloud provider. The token's subject claim, sub, identifies the workflow context. The provider checks that subject and other claims against conditions preconfigured on the cloud role before granting access.[2][3] A repository change therefore needs a comparison of the proposed identity with the role's existing condition, not just a check that GitHub saved the change.

GitHub announced the subject change on April 23, 2026. Its June 10 correction replaced the previously documented hyphen between each name and ID with @. The current reference confirms the documented July transition; this is not an October launch announcement or a measurement of rollout completion.[1][3]

Immutable IDs do not update the cloud match

The old default used owner and repository names. GitHub explains that a recycled namespace could let a different owner create the same subject value. The new format adds immutable owner and repository IDs to distinguish that identity.[1][3]

GitHub's main-branch examples are reproduced exactly below. The numbers are GitHub's illustrative IDs, not IDs collected from a real repository.[3]

• Previous format: repo:octo-org/octo-repo:ref:refs/heads/main
• Immutable format: repo:octo-org@123456/octo-repo@456789:ref:refs/heads/main

Those are different strings. A condition requiring exact equality with the first cannot match the second. The immutable format still contains readable names: do not infer that a rename leaves the entire sub unchanged, or that a transfer preserves the owner identity. Obtain the complete subject intended for the specific operation.[1][3]

GitHub instructs readers to update cloud trust policies to match the format their repository uses.[3] That does not establish a universal migration policy. Whether a provider can accept a temporary overlap, how to keep it narrowly scoped, and what rollback is possible require that provider's current guidance and the actual role configuration.

Check the trigger before choosing a migration path

The announcement's shorter Timeline bullet mentions new repositories and renames; its What's changing section includes transfers, as does the current reference.[1][3] Read those together. The inspected sources do not establish the precise cutoff hour, timezone or treatment of the boundary day; a July 15 creation or change needs repository-specific evidence.

Keep job context and template settings in the comparison

The main-branch example is not a universal deployment subject. In the default context rules, a job's environment takes precedence. Without an environment, a pull-request event uses pull_request; branch and tag subjects apply only when neither of those conditions applies. Colons inside metadata values are encoded as %3A.[3] Inspect the deployment job rather than pasting the branch example into an environment-based role.

Check the issuer and audience separately as well. GitHub documents the issuer as https://token.actions.githubusercontent.com. Audience values can depend on the action or customization, so preserve the value expected by the actual integration.[3] A correct repository segment alone does not establish that every trust condition is satisfied.

A customized subject template changes the complete sub format. GitHub says owner_id and repo_id remain in the repo segment for immutable subjects even with include_claim_keys.[3] Do not mechanically add IDs to an old customization example and treat the result as an observed token.

The REST documentation names use_immutable_subject for immutable-format opt-in. The repository customization endpoint also requires use_default, which controls the default template; include_claim_keys is ignored when use_default is true.[4] These are different controls. This briefing is not a request payload: inspect the intended template and inherited settings before changing either.

A proposed sequence for the GitHub and cloud owners

Use this sequence to plan an authorized change. It has not been executed here. For subject customization, GitHub explicitly recommends creating the matching cloud condition before changing the GitHub configuration.[3] For renames, transfers and immutable opt-in, the steps below are planning guidance; provider-specific sequencing and verification still need to be established.

• 1. Identify the deployment jobs and cloud roles affected by the operation. Record the GitHub host, current repository and owner identity, effective subject/template settings, and the accountable GitHub and cloud owners.
• 2. Establish the current and proposed complete subjects from authorized settings and claim evidence. Include job environment or event/ref context, any customization, issuer and audience. GitHub's announcement mentions a subject-prefix preview endpoint, but the inspected sources do not establish its exact route or payload.[1][4] Do not invent a preview command or treat a prefix as the full deployment subject. If the proposed value cannot be established, hold the operation.
• 3. Compare the proposed claims with each role's real trust conditions. Check exact equality where required and the scope of any pattern. Do not replace a repository restriction with a broad wildcard to make the comparison pass. The intended repository and deployment context must remain bounded.
• 4. Have the GitHub and cloud owners agree on the matching condition and change sequence before the repository operation or opt-in. Establish any temporary overlap and recovery plan using current provider guidance; this article supplies no universal dual-format or rollback configuration.
• 5. After the separately approved change, use the team's authorized verification workflow to record the actual claims, intended role, token-exchange result and allowed or denied scope. Keep tokens and secrets out of the record. A saved setting is not the result. If acceptance evidence is missing, leave migration acceptance unresolved and identify the owner and next check.

Completed hypothetical example: hold the opt-in before a later rename

Assume a fictional team is considering immutable-subject opt-in before a later repository rename. For this reasoning exercise, its cloud role requires exact equality with GitHub's previous main-branch example, and its proposed opt-in subject is GitHub's immutable example. The branch context is unchanged. Both strings and all example IDs below come from GitHub's documentation; none is an observed team setting or token.[3]

• Assumed current exact-match condition: repo:octo-org/octo-repo:ref:refs/heads/main
• Assumed proposed opt-in subject: repo:octo-org@123456/octo-repo@456789:ref:refs/heads/main

The comparison is complete: the repository segment differs, so the proposed subject does not equal the assumed condition. Keeping refs/heads/main unchanged does not fix that mismatch. Decision: HOLD the opt-in and the planned rename. The cloud-trust owner must coordinate a narrowly scoped matching condition with the GitHub owner, then obtain actual acceptance evidence through the team's authorized workflow.

The example resolves the planning decision, not a migration test. No token exchange was run and no provider rejection or success is claimed. The exact subject after the later rename remains unestablished; the pre-rename names above are not a proven post-rename result. The team must return to the comparison for that operation.

Keep the remaining evidence gap specific

For a pending repository change, the useful handoff is the affected role, the current condition, the proposed complete claims, and the owner responsible for resolving any mismatch or unknown. Immutable IDs address recycled-name identity; they do not supply that handoff or prove provider acceptance.[1][2][3]

This briefing uses four official documents checked on October 13, 2026. The inspected GitHub Docs pages do not establish their publication or update dates. No real repository IDs, custom subject, provider overlap policy or migration result were collected. Continue with current provider-specific documentation and authorized configuration evidence before carrying out the operation.