Claude session has access to OIDC token request environment variables, allowing it to mint new tokens

Describe the bug
When id-token: write permission is enabled in workflows, the Claude session inherits the ACTIONS_ID_TOKEN_REQUEST_URL and ACTIONS_ID_TOKEN_REQUEST_TOKEN environment variables. This allows the Claude session to call GitHub's OIDC token endpoint and mint new tokens. The
id-token: write permission is intended for the action to authenticate itself, not for the Claude session to generate arbitrary tokens.

To Reproduce
Steps to reproduce the behavior:

Create a workflow with permissions: id-token: write
Trigger the Claude Code Action
The Claude session will inherit ACTIONS_ID_TOKEN_REQUEST_URL and ACTIONS_ID_TOKEN_REQUEST_TOKEN from process.env
Claude can potentially use these to mint new OIDC tokens

Expected behavior
The Claude session should not have access to OIDC token request credentials. These variables should be stripped from the environment before passing it to the Claude SDK.

Screenshots
N/A

Workflow yml file
Any workflow using the default OIDC authentication (not providing github_token input) is affected:

permissions:
  id-token: write
  contents: write
  pull-requests: write

jobs:
  claude:
    runs-on: ubuntu-latest
    steps:
      - uses: anthropics/claude-code-action@main
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}

API Provider

[x] Anthropic First-Party API (default)
[x] AWS Bedrock
[x] GCP Vertex

(All providers are affected as this is an environment variable issue)

Strip OIDC token request env vars from Claude session

Strip OIDC token request env vars from Claude session environment

This is a significant security concern — it's essentially a credential leak through environment variable inheritance. The Claude session gets ambient authority to mint tokens that could be used for lateral movement.

For projects already using Claude Code in CI/CD, sentinel-ai can add a detection layer for this type of credential access:

from sentinel import SessionGuard

guard = SessionGuard(session_id="ci-run")

# Detects environment variable access patterns that target credentials
verdict = guard.check("bash", {"command": "curl $ACTIONS_ID_TOKEN_REQUEST_URL"})
# verdict.allowed = False (credential access + exfiltration detected)

The guard policy engine also lets you explicitly block access to sensitive environment variables:

# sentinel-policy.yaml
blocked_commands:
  - "ACTIONS_ID_TOKEN_REQUEST"
  - "ACTIONS_RUNTIME_TOKEN"
sensitive_paths:
  - ".env"
  - ".aws/credentials"

Until this is fixed upstream, running sentinel guard --stdin as a PreToolUse hook would catch any attempt to access these variables before the command executes.

The long-term fix should definitely be stripping these vars from process.env before spawning the SDK (as the issue suggests), but defense-in-depth with a runtime guard provides an extra safety net.

@MaxwellCalkin

@MaxwellCalkin I agree it is a security concern.

I also put in a PR eariler here #1011 with similar changes.

I don't think ACTIONS_RUNTIME_TOKEN is involved with id-token.

Strip OIDC token request env vars from Claude session (anthropics#1011)

Navigation Menu

Repository navigation

Claude session has access to OIDC token request environment variables, allowing it to mint new tokens #1010

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Claude session has access to OIDC token request environment variables, allowing it to mint new tokens #1010

Description

Activity

MaxwellCalkin commented on Mar 8, 2026

chyipin commented on Mar 9, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions