Add Workload Identity Federation (OIDC) authentication support

[ashwin-ant]

What

Adds support for authenticating to the Claude API via Workload Identity Federation (WIF) instead of a static anthropic_api_key. The action exchanges the workflow's GitHub Actions OIDC token for a short-lived Anthropic access token using a federation rule configured in the Claude Console, so no API key secret needs to be stored in the repository.

New inputs:

Input	Description
anthropic_federation_rule_id	Federation rule ID (fdrl_...)
anthropic_organization_id	Anthropic organization UUID
anthropic_service_account_id	Service account ID (svac_...), optional
anthropic_workspace_id	Workspace ID (wrkspc_...), optional when the rule targets a single workspace
anthropic_oidc_audience	Audience to request on the GitHub OIDC token, optional

How it works

When anthropic_federation_rule_id and anthropic_organization_id are set (and no API key/OAuth token is provided), the action:

1. Fetches a GitHub Actions OIDC token via core.getIDToken() (requires id-token: write permission, which the default GitHub App auth path already needs)
2. Writes it to a file under RUNNER_TEMP and exports ANTHROPIC_IDENTITY_TOKEN_FILE along with the federation env vars
3. Refreshes the token file in the background so long-running executions can re-exchange with a fresh JWT

The Claude Code CLI performs the token exchange and refresh against the federation rule. base-action's env validation now accepts the federation variables as a third direct-API auth option alongside ANTHROPIC_API_KEY and CLAUDE_CODE_OAUTH_TOKEN.

Usage

permissions:
  contents: write
  pull-requests: write
  issues: write
  id-token: write
steps:
  - uses: anthropics/claude-code-action@v1
    with:
      anthropic_federation_rule_id: fdrl_xxxxxxxxxxxx
      anthropic_organization_id: 00000000-0000-0000-0000-000000000000
      anthropic_service_account_id: svac_xxxxxxxxxxxx

Console setup (issuer, service account, federation rule) is documented in docs/setup.md.

Notes

• Existing auth methods (anthropic_api_key, claude_code_oauth_token, Bedrock, Vertex, Foundry) are unchanged; federation is opt-in.
• If a static credential is set alongside the federation inputs, the static credential takes precedence and a warning is logged.
• Inline comment classification still requires anthropic_api_key; with federation it is skipped and unconfirmed inline comments are posted directly (documented in docs/setup.md).

Testing

• Unit tests for the new workload identity module and the updated env validation
• Verified end-to-end in a test repository: a workflow configured with only the federation inputs (no API key secret) authenticates via the OIDC exchange and completes successfully

[claude]

🟡 setupWorkloadIdentity() guards against ANTHROPIC_API_KEY/CLAUDE_CODE_OAUTH_TOKEN taking precedence, but not CLAUDE_CODE_USE_BEDROCK/VERTEX/FOUNDRY. If a cloud provider is enabled alongside leftover federation inputs and the workflow doesn't grant id-token: write (e.g. Bedrock with AWS_BEARER_TOKEN_BEDROCK), the run hard-fails with a federation-specific error even though the cloud provider is fully configured. Adding the three cloud-provider flags to the existing early-return guard would make federation consistent with the API-key/OAuth precedence rule above it.

Extended reasoning...

The gap. setupWorkloadIdentity() (src/auth/workload-identity.ts:64-72) implements an explicit precedence rule: if ANTHROPIC_API_KEY or CLAUDE_CODE_OAUTH_TOKEN is also set, it logs a warning and returns undefined without touching OIDC. That guard establishes the intended behavior — "do not run federation when a higher-precedence auth method is active." But the three cloud-provider flags (CLAUDE_CODE_USE_BEDROCK, CLAUDE_CODE_USE_VERTEX, CLAUDE_CODE_USE_FOUNDRY) are also higher-precedence routing flags, and they are not checked.

The code path. In src/entrypoints/run.ts, setupWorkloadIdentity() is called before validateEnvironmentVariables() (lines 237-241). validate-env.ts only validates federation inputs in the !useBedrock && !useVertex && !useFoundry branch — so when a cloud provider is enabled, the federation vars are silently ignored by validation. But setupWorkloadIdentity() has already run and acted on them.

Concrete failure proof. A user sets:

1. use_bedrock: true with AWS_BEARER_TOKEN_BEDROCK for auth — bearer-token Bedrock auth does not need id-token: write, so the workflow doesn't grant it.
2. Federation inputs (anthropic_federation_rule_id + anthropic_organization_id) are also present, e.g. copy-pasted from a template or left over from migration.
3. The workflow uses a custom github_token, so the GitHub-App auth path (which would have required id-token: write anyway) is also bypassed.

Walkthrough:

1. run() calls setupWorkloadIdentity().
2. isWorkloadIdentityConfigured() returns true (federation vars are present).
3. The ANTHROPIC_API_KEY/CLAUDE_CODE_OAUTH_TOKEN guard at line 64 does not match — neither is set.
4. writeIdentityToken() calls core.getIDToken(), which throws because id-token: write is not in the workflow permissions.
5. The catch block re-throws Failed to fetch a GitHub Actions OIDC token for workload identity federation: ... Did you remember to add \id-token: write` to your workflow permissions?`
6. The whole action fails, even though Bedrock is correctly configured and federation should never have been attempted.

The error message actively misleads the user toward adding id-token: write, when the real fix is to remove the stray federation inputs.

Addressing the refutation. It's true this requires a double misconfiguration and that the CLI itself would route to Bedrock and ignore ANTHROPIC_IDENTITY_TOKEN_FILE even if the token fetch succeeded. But the failure happens before the CLI runs — getIDToken() throws inside the action itself. So "the CLI would ignore it anyway" doesn't help. And while ANTHROPIC_API_KEY alongside CLAUDE_CODE_USE_BEDROCK has always been silently tolerated, that's a no-op; this is a thrown error. The asymmetry matters.

The fix. Extend the existing guard to also early-return when a cloud provider is selected, e.g.:

if (
  process.env.CLAUDE_CODE_USE_BEDROCK === "1" ||
  process.env.CLAUDE_CODE_USE_VERTEX === "1" ||
  process.env.CLAUDE_CODE_USE_FOUNDRY === "1"
) {
  core.warning(
    "Workload identity federation inputs are set alongside a cloud provider (Bedrock/Vertex/Foundry). The cloud provider takes precedence, so federation will not be used.",
  );
  return undefined;
}

Because the trigger requires explicit conflicting inputs, this is a nit / defense-in-depth improvement rather than a blocking bug, but it's a one-clause addition that mirrors the pattern this PR already established.

[claude]

🟡 writeIdentityToken() refreshes the token file with writeFileSync() directly on the live path, which truncates before writing — so the Claude Code CLI (which re-reads ANTHROPIC_IDENTITY_TOKEN_FILE on each access-token refresh) could observe an empty or partial JWT during the 4-minute background refresh. Writing to a sibling temp file in the same directory and renameSync()-ing over the target makes the replacement atomic.

Extended reasoning...

The bug. writeIdentityToken() (src/auth/workload-identity.ts:82-87) refreshes the OIDC token file by calling writeFileSync(tokenFile, identityToken, { mode: 0o600 }) on the live token path. Node's writeFileSync opens with flag 'w' (O_WRONLY | O_CREAT | O_TRUNC), which truncates the file to zero bytes and then writes. That two-step sequence is not atomic — there is a window where the file on disk is empty or only partially written.

Why it matters here. This module's own doc comment says it precisely: "the CLI re-reads the token file every time it refreshes its Anthropic access token, so the action keeps the file fresh in the background for long-running executions." So we have a writer (the setInterval rewriting the file every 4 minutes) and an out-of-process reader (the Claude Code CLI re-reading ANTHROPIC_IDENTITY_TOKEN_FILE whenever it needs to re-exchange for a fresh Anthropic access token), both pointed at the same path with no coordination.

Concrete sequence that hits the race.

1. setupWorkloadIdentity() writes the initial token and exports ANTHROPIC_IDENTITY_TOKEN_FILE.
2. A long-running session is in progress; the CLI's Anthropic access token approaches expiry and it schedules a re-exchange.
3. At T+4m the setInterval fires; writeFileSync opens the file with O_TRUNC (the file is now 0 bytes).
4. The CLI's refresh path reads the file before the subsequent write() lands.
5. The CLI sends an empty/partial JWT to the federation exchange endpoint, which rejects it — a transient auth failure on a request that should have succeeded.

Why nothing in the current code prevents it. There is no flock, no temp-file dance, and no signal to the CLI to defer reads. The whole design (env var pointing at a file path that's silently rewritten in the background) assumes atomic replacement, but writeFileSync doesn't provide it.

Likelihood and impact. To be fair, the practical odds are low: the JWT is ~1–2 KB, so the truncate→write window is microseconds; the file is rewritten only every 4 minutes; and the CLI only re-reads it when its Anthropic access token expires. Most runs will never hit it. When it does hit, the result is a single transient exchange failure, and the next refresh self-heals. So this is a robustness/correctness nit, not a blocker — but it's exactly the kind of intermittent, unreproducible auth flake that costs an afternoon when someone finally hits it.

Fix. Use the standard atomic-replace pattern — write to a sibling temp file in the same directory (so the rename stays on the same filesystem) and renameSync over the target. POSIX guarantees rename(2) atomically replaces the destination, so a reader sees either the old content or the new content, never an empty file:

const tmpFile = tokenFile + ".tmp";
writeFileSync(tmpFile, identityToken, { mode: 0o600 });
renameSync(tmpFile, tokenFile);

This is the same pattern AWS web-identity token files, Vault Agent, and kubelet projected token mounts use for exactly this reason.