GitHub Actions · OIDC · Checked November 4, 2026

GitHub Actions: "Unable to get ACTIONS_ID_TOKEN_REQUEST_URL env variable"

A step asks GitHub for an OIDC token through two variables, ACTIONS_ID_TOKEN_REQUEST_URL and ACTIONS_ID_TOKEN_REQUEST_TOKEN. GitHub sets them only in a job that may have a token, and this job may not. The action stopped before it reached Azure, AWS, Google Cloud or any other service, so the fix is in the workflow file, not in the cloud's trust settings.

What it looks like

Most JavaScript actions ask through core.getIDToken() in @actions/core, which fails with:

Error: Error message: Unable to get ACTIONS_ID_TOKEN_REQUEST_URL env variable

Some actions say it their own way:

azure/login: "Failed to fetch federated token from GitHub. Please make sure to give write permissions to id-token in the workflow." and then "Login failed with Error: Error message: Unable to get ACTIONS_ID_TOKEN_REQUEST_URL env variable."
actions/deploy-pages: Ensure GITHUB_TOKEN has permission "id-token: write".
google-github-actions/auth: "GitHub Actions did not inject $ACTIONS_ID_TOKEN_REQUEST_TOKEN or $ACTIONS_ID_TOKEN_REQUEST_URL into this job. This most likely means the GitHub Actions workflow permissions are incorrect, or this job is being run from a fork."
anthropics/claude-code-action: "Could not fetch an OIDC token. Did you remember to add id-token: write to your workflow permissions?"
aws-actions/configure-aws-credentials words it differently again: the AWS page, section 4.
npm publish with trusted publishing prints nothing about it and falls back to no login: "ENEEDAUTH".

1. id-token: write is not in the job's permissions

jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read

As soon as a workflow names one permission, every permission it does not name is none (GitHub's workflow syntax). A permissions: contents: read added at the top to harden a workflow therefore removes the token from every job that had one. id-token itself takes only write or none.
A permissions: block on the job replaces the workflow's for that job, so it needs id-token: write too. In camunda-platform-helm #7771, the Vault login failed in a post-release job that granted only contents: read and pull-requests: write, and in a notify job left with the workflow's permissions: {}.
Some actions need more than the token. actions/deploy-pages also needs pages: write, and actions/attest needs attestations: write and artifact-metadata: write (their READMEs).

To see what the job got, open its "Set up job" step: the "GITHUB_TOKEN Permissions" group lists IdToken: write when the job may ask for a token.

2. A pull request from a fork

For a pull_request run from a fork, the permissions key can add and remove read access but typically cannot grant write access (GitHub's workflow syntax), so id-token: write in the file does not take effect. The exception is a private repository whose admin turned on "Send write tokens to workflows from pull requests". The usual report is a job that passes on branches and fails on every outside pull request, as in Nextstrain's shared CI (nextstrain/.github #178). Ways out:

Skip the step for forks. On push there is no pull request, so the condition has to let it through:

if: github.event_name != 'pull_request' || github.event.pull_request.head.repo.full_name == github.repository

Codecov: its README says pull requests from forks to a public repository can upload without a token, so use OIDC only for runs that can have it:

- uses: codecov/codecov-action@v5
  with:
    use_oidc: ${{ !(github.event_name == 'pull_request' && github.event.pull_request.head.repo.fork) }}

An AI review action such as claude-code-action usually has nothing to work with on a fork anyway, since secrets are not passed to those runs either. Projects skip it for forks (idvorkin.github.io #829 had both problems on every pull request).
pull_request_target runs with the base repository's token and can have id-token: write, but it must not check out and run the fork's code (GitHub's guidance on pull_request_target).

3. A reusable workflow

A called workflow can only lower the permissions it receives, never raise them (GitHub's documentation on reusing workflows). id-token: write in the called file is not enough when the caller's job does not have it. For a reusable workflow from outside your organization or enterprise, the documentation says to set it in the caller explicitly:

jobs:
  deploy:
    permissions:
      id-token: write
      contents: read
    uses: octo-org/shared-workflows/.github/workflows/deploy.yml@v1

Telling it apart

The token was issued and the cloud refused it: on Azure, "AADSTS700213: No matching federated identity record found"; on AWS, "Not authorized to perform sts:AssumeRoleWithWebIdentity"; on Google Cloud, "The given credential is rejected by the attribute condition". Permissions are fine; the trust settings are not.
"Failed to get ID Token." with an error code: the variables were there and the request to GitHub failed. A re-run is the first thing to try.
An action that writes ${{ env.ACTIONS_ID_TOKEN_REQUEST_URL }} in its own action.yml fails at "Set up job" on every use: "Unrecognized named-value" in action.yml.

See failed jobs from IntelliJ IDEA

Pipeline Inbox for GitHub Actions Workflows, a plugin by Lesstep for JetBrains IDEs 2024.1 or later, lists the runs of all your repositories in an IDE tool window, with their jobs and steps, and your current branch's runs are in the status bar. Reading is free; re-running failed jobs, cancelling, running workflows and reviewing deployments are Pro (US$1.50 a month, with a 30-day trial).

Get it on JetBrains Marketplace

GitHub and GitHub Actions are trademarks of GitHub, Inc.; IntelliJ IDEA is a trademark of JetBrains s.r.o. Other product names are trademarks of their owners. This page is not affiliated with, sponsored or endorsed by GitHub, Inc. or JetBrains.

More: GitHub Actions OIDC to Azure · GitHub Actions OIDC to AWS · "Resource not accessible by integration" · GitHub Actions plugins for IntelliJ IDEA compared · 日本語