Skip to content
Latchkey

OIDC id-token not granted to a reusable workflow in CI

A reusable workflow inherits permissions from the caller, capped by the caller's grant. If the calling job does not grant id-token: write, the called workflow cannot request an OIDC token no matter what it declares.

What this error means

A cloud login inside a called (reusable) workflow fails with an OIDC token error, while the same steps work when run directly. The caller job has no id-token: write.

.github/workflows/ci.yml
Error: Unable to get ACTIONS_ID_TOKEN_REQUEST_URL env variable.
# called workflow declares id-token: write, but caller job does not grant it

Common causes

The caller job does not grant id-token

Permissions for the called workflow are the intersection of caller and callee; the caller must also grant id-token: write.

A read-only default at the caller level

If the caller defaults to read-only and the calling job adds no grant, id-token stays unset for the whole call.

How to fix it

Grant id-token on the calling job

  1. Add permissions: id-token: write to the job that uses the reusable workflow.
  2. Keep the matching grant inside the called workflow too.
  3. Re-run so both levels allow the token request.
.github/workflows/ci.yml
jobs:
  call-deploy:
    permissions:
      id-token: write
      contents: read
    uses: my-org/my-repo/.github/workflows/deploy.yml@main

Declare the same scope in the called workflow

The reusable workflow should also declare id-token: write so its own jobs can use the token.

deploy.yml
permissions:
  id-token: write
  contents: read

How to prevent it

  • Grant id-token: write on the calling job for OIDC reusable workflows.
  • Remember permissions are the intersection of caller and callee.
  • Declare the scope in both the caller and the reusable workflow.

Related guides

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →