You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
claude setup-token tokens rejected with "API Error: 400 status code (no body)" on first request — Max 20x account, fresh mints, reproduces locally and in CI #86986
Every long-lived OAuth token minted by claude setup-token (correct sk-ant-oat01- prefix) is rejected by the API with API Error: 400 status code (no body) on the very first request — while interactive Claude Code on the same machine, same account, works perfectly. Reproduces identically in GitHub Actions (claude-code-action@v1, claude_code_oauth_token input) and locally (CLAUDE_CODE_OAUTH_TOKEN=<token> claude -p "..."). Multiple fresh mints over several hours on 2026-08-15 (~18:00–20:00 UTC) all fail the same way.
Environment
Account: Claude Max 20x (organizationType: claude_max, billingType: stripe_subscription, subscription active since 2026-02)
Local: Claude Code 2.1.232 on Windows 11 (Git Bash) — interactive use works
CI: ubuntu-latest, anthropics/claude-code-action@v1 (also reproduced with the CLI pinned to 2.1.232 via path_to_claude_code_executable)
Timing note: mints occurred hours after the Aug 14 20:00 – Aug 15 00:11 UTC OAuth incident on status.claude.com was marked resolved
Failure signature
{"type":"system","subtype":"init","message":"Claude Code initialized","model":"claude-sonnet-5"}
{"type":"result","subtype":"success","is_error":true,"duration_api_ms":0,"num_turns":1,
"total_cost_usd":0,"input_tokens":0,"api_error_status":400,
"result":"API Error: 400 status code (no body)"}
Assistant message model is <synthetic>, is_api_error_message: true, error: "unknown". Fails in ~250 ms at zero cost — the first request never gets a body back.
Ruled out (each tested)
Token value corruption — token piped via stdin with CR/whitespace stripping; multiple careful re-pastes; same result.
Wrong token type — confirmed sk-ant-oat01- prefix (not sk-ant-api03/sk-ant-sid01).
CI environment — reproduces locally with only CLAUDE_CODE_OAUTH_TOKEN set; action debug logs show the token delivered to the execute phase, no Bedrock/Vertex/base-URL overrides, anthropic_api_key empty.
Model — identical 400 with default claude-sonnet-5 and explicit --model claude-haiku-4-5-20251001.
CLI version — identical 400 on 2.1.233 (CI default) and 2.1.232 (pinned; the exact version that works interactively on the same machine).
Account mismatch — setup-token browser approval performed in the same claude.ai account the CLI is logged into (verified via oauthAccount metadata).
Stale mint / revocation by newer mints — every attempt used the newest mint, pasted immediately.
The Aug 14–15 OAuth incident — is token issuance fully recovered?
Ask
Is long-lived token issuance currently degraded for Max accounts, and is there server-side logging for the 400-no-body path that can identify what the request is missing?
Summary
Every long-lived OAuth token minted by
claude setup-token(correctsk-ant-oat01-prefix) is rejected by the API withAPI Error: 400 status code (no body)on the very first request — while interactive Claude Code on the same machine, same account, works perfectly. Reproduces identically in GitHub Actions (claude-code-action@v1,claude_code_oauth_tokeninput) and locally (CLAUDE_CODE_OAUTH_TOKEN=<token> claude -p "..."). Multiple fresh mints over several hours on 2026-08-15 (~18:00–20:00 UTC) all fail the same way.Environment
organizationType: claude_max,billingType: stripe_subscription, subscription active since 2026-02)anthropics/claude-code-action@v1(also reproduced with the CLI pinned to 2.1.232 viapath_to_claude_code_executable)Failure signature
Assistant message model is
<synthetic>,is_api_error_message: true,error: "unknown". Fails in ~250 ms at zero cost — the first request never gets a body back.Ruled out (each tested)
sk-ant-oat01-prefix (notsk-ant-api03/sk-ant-sid01).CLAUDE_CODE_OAUTH_TOKENset; action debug logs show the token delivered to the execute phase, no Bedrock/Vertex/base-URL overrides,anthropic_api_keyempty.claude-sonnet-5and explicit--model claude-haiku-4-5-20251001.setup-tokenbrowser approval performed in the sameclaude.aiaccount the CLI is logged into (verified viaoauthAccountmetadata).claude_maxorg, the workspace setting does not exist.Expected
A freshly minted
setup-tokentoken authenticates foruser:inferenceon a Max account, as documented for CI use.Possibly related
validateHeadersfailure with Max-plan OAuth tokens after Pro→Max upgrade claude-code-action#1281 (Max-plan OAuth token failures)Ask
Is long-lived token issuance currently degraded for Max accounts, and is there server-side logging for the 400-no-body path that can identify what the request is missing?