GitHub Actions OIDC sub claim: the old and the immutable format

GitHub's OIDC token carries a sub (subject) claim that your AWS role, Azure federated credential or Google Cloud pool compares with the value in your trust policy. For repositories created after 15 July 2026 GitHub changed the default format to include the owner ID and repository ID, so a trust policy written the old way stops matching. This page lists every default shape, from GitHub's OIDC reference (read on 13 Oct 2026), and how to keep both working.

Every default subject

GitHub's page gives the immutable syntax for a branch (repo:OWNER@OWNER-ID/REPO@REPO-ID:ref:refs/heads/BRANCH) and says renames and transfers after 15 July 2026 also move a repository to it; the environment, pull request and tag rows above apply the same owner and repo segment and are our reading, so confirm them with a real token (the debugger below decodes one). Immutable subjects are not available on GitHub Enterprise Server. A colon inside a name is written %3A, so an environment called Production:V1 appears as Production%3AV1.

Why it matters

• An environment beats the branch. If the job names an environment the subject carries the environment, not the ref. A condition on ref:refs/heads/main will not match it.
• Entra is case sensitive. Issuer, subject and audience are compared case sensitively, so Production and production are different environments. Microsoft applied this first to apps and managed identities created after 14 August 2024; for older active ones it said the date would be announced. A standard federated credential also compares exactly (no wildcards), and an app can hold at most 20 credentials; a flexible federated identity credential (preview, for GitHub, GitLab and Terraform Cloud) can match a pattern.
• An org-wide pattern is the likeliest thing to break. A StringLike condition such as repo:octo-org/* matches every old-format subject in the organisation but none of the new ones, which start repo:octo-org@123456/. For repositories on the new format write repo:octo-org@123456/* (with your own owner ID), and keep the old pattern alongside it while both exist. The debugger flags this case.
• AWS needs a list or a pattern. A condition key can take a list of values (Vercel's AWS docs use a list to allow an old and a new name at once), so you can list the old and the new subject side by side. StringLike accepts * and ?.

Keep both formats working

For AWS, put both subjects in one list under token.actions.githubusercontent.com:sub. For Entra, create one credential for each subject, or use a flexible federated identity credential (preview, for GitHub, GitLab and Terraform Cloud) whose expression matches both; for GitHub it must also match repository_id or repository_owner_id. For Google Cloud, write both in the attribute condition: assertion.sub=='repo:octo-org/octo-repo:ref:refs/heads/main' || assertion.sub=='repo:octo-org@123456/octo-repo@456789:ref:refs/heads/main' (a Common Expression Language expression; the IDs here are GitHub's own docs example). Once every repository you trust is on the immutable format, drop the old subjects: the old format can be matched by whoever later takes over a recycled name, which is why GitHub changed it.

Check your own token

Decode a real token in the OIDC token debugger (browser only) and paste the subject from your trust policy: it says whether the format, the case or an environment is the problem. The same format question exists on other platforms: Forgejo 16 puts numeric IDs into the subject for repositories that enabled Actions after that release, and GitLab 18.7 can add ref_protected and environment fields. The CI OIDC Atlas ($12) has the subject, audience, lifetime and gotcha for 11 platforms, each with a vendor quote; the free sample CSV has four.

Source: GitHub Docs, OpenID Connect reference, read 13 Oct 2026. Microsoft: federated credential matching change, August 2024; flexible federated identity credentials (preview). Format rules can change; re-read the page before relying on a row.