GitHub Actions OIDC, immutable IDs, and one very annoying deployment failure

Expanded from a LinkedIn post originally published on 2026-07-18.

I’ve spent the last couple of days tearing my hair out over what looked like a broken GitHub Actions OIDC setup.

I was configuring a workflow to authenticate with a cloud provider using the same trust-policy pattern I’d used successfully before:

`repo:org/repo:*`

But every newly created repository kept failing, while the older ones continued to work perfectly.

Eventually, I found the reason buried in a recent GitHub changelog update.

GitHub has introduced immutable organisation and repository IDs into the OIDC subject claim. Instead of the subject only containing the readable names, newer repositories can now produce claims that look more like:

`repo:org@207638922/repo@1298665805:*`

The old pattern:

`repo:org/repo:*`

will no longer match that claim.

From a security perspective, the change makes complete sense. Organisation and repository names can be renamed, transferred or reused, whereas the underlying IDs remain permanently tied to the original resources.

From an infrastructure perspective, though, it is the sort of change that can quietly break your deployment pipeline while making you question absolutely everything else in the setup.

In my case, repositories created before 15 July continued working with the old pattern, while newly created repositories required the immutable ID-based subject.

That inconsistency was what made the problem particularly difficult to diagnose.

So, should anyone suddenly find that GitHub Actions OIDC works for their existing repositories but mysteriously fails for new ones, check the actual `sub` claim in the token before rewriting your entire infrastructure configuration.

Hopefully this saves somebody else the same bloody nightmare.

#GitHubActions #OIDC #DevOps #CloudInfrastructure #CloudSecurity #SoftwareEngineering

The failure looked like everything except the real problem

The worst infrastructure bugs are the ones that look familiar. You have a pattern that worked last week. You use it again. The new workflow fails. The old workflows keep passing. Naturally, you start suspecting everything around the thing that changed.

In this case the setup was GitHub Actions OIDC authentication into a cloud provider. The trust policy used the readable repository pattern I had used before: repo:org/repo:*.

That pattern was fine for the older repositories. It was not fine for the newer ones.

The subject claim changed shape

GitHub has introduced immutable organisation and repository IDs into the OIDC subject claim for newer repositories. Instead of relying only on readable names, the claim can include stable IDs, such as repo:org@207638922/repo@1298665805:*.

The security reason is sound. Repository names can change. Organisations can be renamed. Names can be transferred or reused. IDs are tied to the underlying resources.

The operational downside is that your old trust policy may simply stop matching the token. Nothing is wrong with the cloud provider. Nothing is wrong with the workflow syntax. The token is just no longer saying what your policy expects it to say.

Check the token before rebuilding the house

The lesson is painfully simple: inspect the actual sub claim before rewriting the surrounding infrastructure.

If OIDC works for existing repositories but fails for newly created ones, do not assume the whole pipeline is broken. Compare the subject claims. Check whether the new repository is using the immutable ID-based format. Then update the trust policy deliberately.

This is exactly the sort of change that is sensible in a changelog and infuriating at 1am when a deployment pipeline has decided to become a riddle.