Skip to content
Latchkey

GitHub Actions "id-token" permission missing for a reusable workflow OIDC call in CI

OIDC cloud login inside a reusable workflow needs id-token: write. Because a callee cannot exceed the caller, the calling workflow must grant id-token: write, or the OIDC step fails to fetch a token.

What this error means

A cloud login step inside the reusable workflow fails with "Unable to get ACTIONS_ID_TOKEN_REQUEST_URL" or a permission error, because id-token was never granted by the caller.

GitHub Actions
Error: Unable to get ACTIONS_ID_TOKEN_REQUEST_URL env variable
The reusable workflow requires 'id-token: write', but the calling workflow
did not grant it.

Common causes

The caller did not grant id-token: write

The OIDC token endpoint is only exposed when id-token: write is granted. A callee inherits the caller cap, so the caller must grant it.

Permissions set only in the callee

Declaring id-token: write only inside the reusable workflow is not enough; the caller must also allow it.

How to fix it

Grant id-token: write on the calling job

  1. Add id-token: write to the calling job permissions.
  2. Keep contents: read (and any other needed scope).
  3. Re-run so the reusable workflow can request an OIDC token.
.github/workflows/ci.yml
jobs:
  deploy:
    permissions:
      id-token: write
      contents: read
    uses: ./.github/workflows/deploy.yml

Also declare it in the reusable workflow

The called workflow should declare id-token: write on the job that logs in, so the effective token has it when the caller allows it.

.github/workflows/deploy.yml
# deploy.yml
jobs:
  run:
    permissions:
      id-token: write
      contents: read

How to prevent it

  • Grant id-token: write on the calling job for OIDC reusable workflows.
  • Declare id-token: write in the callee jobs that log in.
  • Keep other scopes least-privilege alongside id-token.

Related guides

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