GitHub's July 15 OIDC Change Will Not Break Your Existing AWS Deploys

The Headline Going Around Is Wrong

If you run GitHub Actions that deploy to AWS with OIDC, you have probably seen the warning: GitHub is changing its OIDC subject claim on July 15, 2026, and it will break your deploys. For repositories that already exist and that you leave alone, that is simply not true. The change is real, it is a good one, and for most teams it changes nothing on July 15. Here is what actually happens, straight from GitHub's own changelog, and how to make sure you are never caught out by it.

What Actually Changes

GitHub Actions requests a short-lived OIDC token, and your cloud trusts it by matching the token's sub (subject) claim. Today the default subject looks like this:

repo:octo-org/octo-repo:ref:refs/heads/main

The new immutable format appends permanent numeric owner and repository IDs:

repo:octo-org@123456/octo-repo@456789:ref:refs/heads/main

The @ is the delimiter, because @ can never appear in a GitHub org or repository name. The point is security. If an org or repository name is deleted and later recycled by someone else, the old name-based subject could be reused to mint tokens your cloud still trusts. The numeric IDs are permanent, so a recycled name no longer matches. This is genuine hardening, and it applies to github.com only, not GitHub Enterprise Server.

The Three Things That Actually Flip You To The New Format

Per GitHub's changelog, on and after July 15, 2026 the immutable subject is applied automatically only when one of these happens:

1. A repository is created after July 15, 2026.
2. An existing repository is renamed after July 15, 2026.
3. An existing repository is transferred after July 15, 2026.

That is the whole list. In GitHub's own words, existing repositories are not affected unless you explicitly opt in, using a toggle in the repository or organization OIDC settings. There is no forced cutover that silently rewrites every repository's token on July 15. So if your deploy repository already exists and you do not rename, transfer, or opt it in, your current trust policy keeps working exactly as it does today.

When It Will Actually Bite You

The failure mode is specific. It happens when an IAM role trust policy pins the exact old subject with StringEquals:

"Condition": {
  "StringEquals": {
    "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
    "token.actions.githubusercontent.com:sub": "repo:octo-org/octo-repo:ref:refs/heads/main"
  }
}

The moment one of the three triggers fires, the token's subject becomes the @-ID format, no longer equals the pinned string, and sts:AssumeRoleWithWebIdentity fails with AccessDenied. A brand-new repository created after July 15 hits this on its very first deploy. A long-lived repository hits it only if you rename or transfer it. Nobody hits it just because the calendar turned to July 15.

How To Future-Proof Now, With Zero Downtime

Make the trust policy accept both the legacy and the immutable subject with StringLike, so a future rename, transfer, opt-in, or new sibling repository cannot break a deploy:

"Condition": {
  "StringEquals": {
    "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
  },
  "StringLike": {
    "token.actions.githubusercontent.com:sub": [
      "repo:octo-org/octo-repo:ref:refs/heads/main",
      "repo:octo-org@*/octo-repo@*:ref:refs/heads/main"
    ]
  }
}

One caveat worth understanding: those @* wildcards are unbounded globs that match any characters, not only the numeric IDs, so the policy trusts more than the immutable format intends. Keep the dual pattern as a short transition bridge, not a permanent home, and note that both blocks above keep the aud check that scopes the token to AWS STS.

The Hardened End State

Once a repository is on the immutable format, pin the exact subject with the real numeric IDs, because that is the entire security benefit. Find the IDs with the GitHub CLI:

gh api repos/octo-org/octo-repo --jq '{repo_id: .id, owner_id: .owner.id}'

Then lock the trust policy to the exact immutable subject:

"Condition": {
  "StringEquals": {
    "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
    "token.actions.githubusercontent.com:sub": "repo:octo-org@123456/octo-repo@456789:ref:refs/heads/main"
  }
}

Your Checklist

1. Inventory every IAM role that trusts GitHub OIDC, and note which ones pin the exact subject with StringEquals.
2. For repositories you will not rename or transfer: no urgency, but add the dual-pattern StringLike as cheap insurance.
3. For any repository you create, rename, or transfer after July 15: update the trust policy to the immutable format first, or the first deploy will fail.
4. Test an actual deploy after any trust-policy change. Do not trust a policy you have not exercised.
5. Once stable, prefer the hardened StringEquals with real IDs over permanent wildcards.

The Real Takeaway

The change closes a real name-recycling hole, and that is good. The panic that it breaks everyone's deploys on July 15 is wrong. The teams that actually get burned will be the ones that hardcoded the old subject and then rename or transfer a repository without touching IAM, or that spin up a new repository after July 15 against an old-style trust policy. Read the changelog, not the thread, and add one extra line to your trust policy today so the question never comes up.

This kind of quiet, calendar-driven breakage is exactly what our CI/CD pipeline and security and compliance work is built to catch before it reaches production.

Sources

The subject formats, the @ delimiter, the July 15, 2026 enforcement scope (new repositories and renames or transfers only), the opt-in for existing repositories, and the github.com-only scope are from GitHub's official changelog "Immutable subject claims for GitHub Actions OIDC tokens" (April 23, 2026) and GitHub's "Configuring OpenID Connect in Amazon Web Services" documentation. The dual-pattern StringLike and hardened StringEquals trust policies are standard AWS IAM practice applied to those documented formats. Test any trust-policy change against your own role before relying on it.