WIF still fails with jti_reused when plugins are configured after #1407

[portswigger-jose]

Describe the bug

This appears to be the same externally visible failure reported in #1406, despite running a version of the action that includes the fix from #1407.

When Anthropic workload identity federation (WIF) is used together with the plugins and plugin_marketplaces inputs, Claude execution fails with a token-exchange authentication error. The plugin is installed from our own privately hosted Claude Code marketplace rather than a public marketplace.

API Error: Token exchange failed with status 401
{"error":{"type":"authentication_error","message":"Authentication failed"}}

The corresponding Anthropic authentication event reports:

jti_reused

After removing the plugin inputs while retaining WIF, a subsequent run completed successfully.

Version evidence

The failing run resolved anthropics/claude-code-action@v1 to be7b93b, which is three commits after the merged #1407 fix.

To reproduce

The relevant shape of the workflow is:

permissions:
  id-token: write
  contents: read

steps:
  - uses: actions/checkout@v4

  - uses: anthropics/claude-code-action@v1
    with:
      prompt: "Perform the requested task."
      anthropic_federation_rule_id: "fdrl_***"
      anthropic_organization_id: "***"
      anthropic_service_account_id: "svac_***"
      anthropic_workspace_id: "wrkspc_***"
      plugin_marketplaces: |
        <marketplace URL>
      plugins: |
        <plugin>@<marketplace>

Observed behaviour:

1. WIF and a plugin from a privately hosted custom Claude Code marketplace are configured.
2. The action starts but Claude execution subsequently fails with a token-exchange 401.
3. The Anthropic authentication event identifies the failure as jti_reused.
4. Removing the plugin configuration while retaining WIF allows a subsequent run to succeed.

The repository, plugin identity, marketplace URL, federation identifiers, request IDs, and workflow run URLs are intentionally omitted because they are private. The marketplace is supplied through the action's documented plugin_marketplaces input. We can provide additional redacted logs or identifying details privately if required.

Expected behaviour

WIF should continue to work when marketplace plugins are configured.

The identity token should not be exchanged more than once by the separate Claude processes involved in marketplace setup, plugin installation, and the main query.

Additional context

This report follows:

• WIF federation fails with 401 (jti_reused) when plugins are configured — each spawned claude process re-exchanges the single-use OIDC token #1406
• fix: share one exchanged WIF credential across spawned Claude processes #1407
• Fix commit: b00a341
• Action commit used by the failing run: be7b93b

We are not asserting that the internal cause is definitely identical to #1406. However, the observable conditions and failure are the same:

• WIF succeeds without plugin configuration.
• With plugin configuration, the run produces jti_reused.
• The failure occurs on a revision containing the intended shared-credential-cache fix.

[ashwin-ant]

Thanks for the detailed report. I looked into this and don't think it's #1406 coming back: on the CLI version your run used, the plugin install steps no longer do a token exchange at all, so a run with plugins performs a single exchange, same as one without. I was able to reproduce the same jti_reused failure with plugins removed entirely, which points at a transient failure of the first exchange rather than the plugin config. "Removing plugins fixed it" was most likely coincidence.

Could you check the Workload identity auth events for that run and tell me whether the first event for the jti is a success, and how long after it the first jti_reused shows up? And does the plugin from your marketplace include anything that itself invokes claude or calls the Anthropic API (a hook or MCP server)?

[portswigger-jose]

Thanks for digging in.

We just re-tested this today (2026-08-04) to be sure: temporarily re-added the same single plugin config to a workflow that had previously had it removed, triggered a real run, reverted a few minutes later. It reproduced the identical 401/token-exchange failure. Same shape as before: WIF configured → plugin installed with no token exchange logged during install → several minutes idle → first API call fails outright.

We also checked that plugin's source — it's a local hook that only shells out to our build tool to estimate test counts, no network calls, no claude/Anthropic invocation. So this isn't a specific-plugin or multiple-plugins thing, and it isn't limited to older runs — it reproduces today.

On the jti timing: we pulled the Workload Identity auth events. The first request in the chain succeeded, followed by a series of jti_reused errors — the first one appearing 1-2 seconds after the successful exchange.

Let me know if there's some more logs you want me to get out for you!