`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

Update — error-layer calibration narrows this to request construction, not token validity:

• Deliberately invalid token (CLAUDE_CODE_OAUTH_TOKEN=sk-ant-oat01-garbage claude -p "hi") → Failed to authenticate. API Error: 401 OAuth access token is invalid.
• Freshly minted real token, same command → API Error: 400 status code (no body)

So freshly minted tokens are recognized as valid credentials (they do not hit the 401 invalid-token path) — the request built in env-token mode is then rejected with a bodyless 400 at some later validation layer. Interactive keychain auth on the same account/machine works, so whatever context the profile-aware path attaches (billing/beta headers?) appears to be missing or mismatched in the CLAUDE_CODE_OAUTH_TOKEN path.

Possibly relevant account detail: organizationType: claude_max, tier default_claude_max_20x, hasExtraUsageEnabled: true — if inference for extra-usage-enabled Max accounts requires billing context the env-token request path doesn't send, that would reproduce exactly this split (env-token 400 everywhere incl. CI; interactive fine).

Reproduced identically on 2.1.232 and 2.1.233 (local and CI, ubuntu-latest and Windows/Git Bash).

I can confirm this issue is still reproducible on Windows with a freshly generated long-lived OAuth token.

Environment

Claude Code: 2.1.252
Executable: C:\Users\AIWorkforceAgent\.local\bin\claude.exe
PowerShell: 5.1.26100.8875
OS: Microsoft Windows NT 10.0.26200.0
Authentication: freshly generated `claude setup-token`
Environment variable: `CLAUDE_CODE_OAUTH_TOKEN`

Reproduction

The token was generated successfully with:

claude setup-token

Claude Code reported:

Long-lived authentication token created successfully
OAuth token valid for 1 year

The actual OAuth token is not included here.

The token was then supplied to the Claude process through CLAUDE_CODE_OAUTH_TOKEN.

Minimal test:

claude -p "Reply exactly: CLAUDE_OAUTH_OK"

Result, consistently:

API Error: 400 status code (no body)

I also reproduced the same result when the environment variable was injected by a Windows launcher rather than set interactively.

Additional observations

• This is a newly minted token, not an expired /login session.
• Claude Code starts successfully and reaches the API request.
• The failure is repeatable.
• The token is passed without intentionally modifying its value.
• Windows filesystem/ACL access to the credential is working.
• No API key is being intentionally used instead of the OAuth token.
• Repeated calls fail with the same HTTP 400 / no-body response.

This reproduction is on Claude Code 2.1.252, so the issue appears to persist beyond the 2.1.232/2.1.233 versions mentioned in the original report.

It would be useful if Claude Code could surface a request/correlation ID or the backend error body for this authentication failure so affected users can distinguish token-format, account-policy, and server-side issuance failures.

Additional diagnostic from my reproduction:

Claude Code: 2.1.252
OS: Windows NT 10.0.26200.0
PowerShell: 5.1.26100.8875

With the freshly generated CLAUDE_CODE_OAUTH_TOKEN injected:

claude auth status

returns:

{
  "loggedIn": true,
  "authMethod": "oauth_token",
  "apiProvider": "firstParty"
}

Without the injected token, the same machine returns:

{
  "loggedIn": false,
  "authMethod": "none",
  "apiProvider": "firstParty"
}

Therefore Claude Code is definitely detecting and selecting the long-lived OAuth token, and there is no competing stored login credential.

However:

claude -p "Reply exactly: CLAUDE_OAUTH_OK"

still returns:

API Error: 400 status code (no body)

This appears to narrow the failure to the request/backend path after OAuth-token selection rather than local credential discovery or precedence.

No OAuth token or other credential is included in this report.