GitHub Adds Immutable IDs to Actions OIDC Subject Claims to Close a Repository-Name Recycling Hole
GitHub is embedding permanent owner and repository IDs into Actions OIDC subject claims, with the new format becoming the default for repos created after July 15, 2026.
Overview
GitHub is changing how GitHub Actions workflows prove their identity to cloud providers. In a change announced on April 23, 2026, the company is embedding permanent numeric identifiers into the subject claim of the OpenID Connect (OIDC) tokens that Actions hands to clouds like AWS, Azure, and GCP, according to the GitHub Changelog. The stated goal is to close a gap in which a recycled repository or organization name could let a new owner impersonate the old one when requesting cloud credentials.
The new format is available to opt into today, and it becomes the default for newly created repositories after a mid-July cutover.
What We Know
GitHub Actions can use OIDC to obtain cloud credentials without storing long-lived secrets. The cloud provider, after validating the token, “provides a short-lived cloud access token that is available only for the duration of the job,” per the GitHub Docs. Trust is anchored on the token’s subject (sub) claim: “To validate the token, the cloud provider checks if the OIDC token’s subject and other claims are a match for the conditions that were preconfigured on the cloud role’s OIDC trust definition,” the GitHub Docs state.
Historically that subject claim has been built from human-readable names alone — for example, a default of the form repo:octo-org/octo-repo:ref:refs/heads/demo-branch, as shown in the GitHub Docs OIDC reference. The new format appends immutable owner and repository IDs, joined to the names with an @ delimiter. GitHub’s example of the new shape is repo:octocat@123456/my-repo@456789:ref:refs/heads/main, according to the GitHub Changelog. The same immutable form, repo:octo-org@123456/octo-repo@456789:ref:refs/heads/demo-branch, appears in the GitHub Docs reference as the post-cutover default.
The vulnerability being addressed is namespace recycling. “If a repository or organization name was recycled, a new owner could mint tokens with the same subject claim, potentially gaining unauthorized access to cloud resources that still trusted the original identity,” the GitHub Changelog explains. Because numeric IDs are never reassigned, binding the claim to them prevents a later occupant of a freed-up name from matching a trust policy written for the original.
On timing, the change rolls out by default for new repositories. “All repositories created after July 15, 2026 will automatically use the new immutable subject claim format,” the GitHub Changelog states, adding that “Repository renames and transfers after July 15, 2026 will also adopt the new format.” Existing repositories are not moved automatically: “Existing repositories won’t be affected unless you explicitly opt in,” per the same GitHub Changelog. Teams that want the format now can do so: “You can adopt the new format for your existing repositories today using a new toggle in the repository or organization OIDC settings UI and API,” the GitHub Changelog says.
Why It Matters
The subject claim is the string that cloud trust policies pin against. As the GitHub Docs reference puts it, “Audience and subject claims are typically used in combination while setting conditions on the cloud role/resources to scope its access to the GitHub workflows,” and administrators “must define at least one condition, so that untrusted repositories can’t request access tokens for your cloud resources.” Those conditions are spelled out in provider-specific syntax — the GitHub Docs reference shows an AWS condition matching "token.actions.githubusercontent.com:sub": "repo:octo-org/octo-repo:ref:refs/heads/demo-branch", with parallel forms for Azure and GCP.
The practical consequence is that any trust policy hard-coding the old name-only subject string will not match once a repository switches to the immutable format. Adopters therefore need to update the corresponding cloud-side trust conditions to the new IDs before flipping the toggle, or risk breaking their workflows’ cloud access.
What We Don’t Know
The announcement is scoped to GitHub.com and does not extend to GitHub Enterprise Server, per the GitHub Changelog. The changelog does not quantify how many repositories have opted in ahead of the July 15 default, nor does it detail enforcement behavior for organizations that take no action by that date beyond stating that newly created, renamed, and transferred repositories adopt the format automatically.