Update GitHub Actions OIDC Trust Policies Before New Repos Break Cloud Deploys

Confirmed: GitHub's immutable subject claim format for GitHub Actions OIDC tokens now applies automatically to repositories created after July 15, 2026, and to repository renames or transfers after that date. Existing repositories keep the older format unless an organization or repository opts in. If your cloud trust policy matches the old name-based sub claim too tightly, new deployments can fail even though the workflow and cloud role are otherwise correct.

What changed

GitHub Actions OIDC tokens can now use an immutable subject claim that includes stable owner and repository IDs. The change matters because cloud providers and secret brokers often use the token's sub claim to decide whether a workflow may assume a role or request credentials.

For repositories created after July 15, 2026, GitHub says the immutable format is automatic. Repository renames and transfers after that date also move to the immutable format. Repositories created before July 15 keep the previous subject format unless you opt in through GitHub's OIDC settings UI or REST API.

Key takeaways

• New github.com repositories now receive ID-based OIDC subject claims by default.
• Repository renames and transfers after July 15, 2026 also move to the immutable format.
• Older repositories keep the name-based behavior unless explicitly opted in.
• AWS, Azure, Google Cloud, Vault, and other relying parties may need trust-policy updates.
• GitHub Enterprise Server is outside the scope of this change.

Availability and access

This is already live on github.com. GitHub's documentation says repositories created after July 15, 2026 and post-date renames or transfers use the immutable default subject format. Existing repositories can opt in at the organization or repository level.

There is no new paid tier attached to the change in GitHub's announcement. The practical cost is operational: teams must audit cloud trust policies, deployment templates, Terraform modules, and any identity broker rules that assume the old repo:owner/name subject shape.

Practical LinkLoot angle

Treat this as a CI/CD identity migration, not a routine changelog item. The safest workflow is to preview the subject claim format, update trust policies in a staging role, run a deployment from a test repository, and only then opt existing production repositories into immutable claims.

Teams building AI-assisted or automated release workflows should be stricter, not looser, here. A broad wildcard may make broken deployments disappear, but it also weakens the boundary that makes GitHub Actions OIDC useful in the first place. For related automation planning, keep LinkLoot's AI workflow guide handy: /guides/ai-workflow-automation.

What to verify before you act

• Check whether the repository was created before or after July 15, 2026.
• Confirm whether the organization or repository has opted in to immutable subject claims.
• Preview or inspect the actual OIDC sub claim before editing production trust policies.
• Update cloud-provider conditions for AWS, Azure, Google Cloud, Vault, or any custom broker.
• Test repository rename and transfer scenarios if your platform team uses template repos.

Source check

Confirmed by: GitHub's changelog states the July 15, 2026 enforcement date for new repositories and renames or transfers. GitHub's OIDC reference documents the owner_id and repo_id subject format and confirms that existing repositories keep the previous format unless opted in.

Context: GitHub's cloud-provider guidance for Google Cloud repeats the July 15 behavior for new repositories and renames or transfers. Independent security writing on GitHub Actions OIDC provides background on why subject-claim matching is central to cloud trust-policy design, but the enforcement date comes from GitHub.