[BUG] Bedrock "Session token not found or invalid" on interactive requests despite valid, confirmed-working credentials

Confirming this also reproduces on macOS (not just WSL2/Windows), so it's not platform-specific.

Environment:

• Claude Code 2.1.207 (native install, macOS)
• Auth: AWS SSO via AWS_PROFILE, region us-east-1
• Model: us.anthropic.claude-sonnet-5

Same "auth succeeds, dispatch fails" pattern, captured via claude --debug api --debug-file ...:

2026-07-11T17:40:33.881Z [DEBUG] [API:auth] AWS credential resolve start
2026-07-11T17:40:33.881Z [DEBUG] Fetching AWS caller identity for AWS auth refresh command
2026-07-11T17:40:36.185Z [DEBUG] Fetched AWS caller identity, skipping AWS auth refresh command
2026-07-11T17:40:36.185Z [DEBUG] [API:auth] AWS credential resolve done in 2304ms
2026-07-11T17:40:36.186Z [DEBUG] [API:auth] resolving default AWS provider chain (region: us-east-1)
2026-07-11T17:40:37.137Z [ERROR] Bedrock ListInferenceProfiles failed: UnauthorizedException: Session token not found or invalid
2026-07-11T17:40:37.138Z [ERROR] Failed to list Bedrock inference profiles, falling back to hardcoded models: UnauthorizedException: Session token not found or invalid
...
2026-07-11T17:40:38.573Z [DEBUG] [API:timing] dispatching to bedrock model=us.anthropic.claude-sonnet-5
2026-07-11T17:40:38.573Z [DEBUG] [API:auth] resolving default AWS provider chain (region: us-east-1)
2026-07-11T17:40:38.810Z [ERROR] API error (attempt 1/11): UnauthorizedException: Session token not found or invalid

Retries 3 times (each preceded by a successful credential resolve), then gives up.

Independently confirmed working outside Claude Code, same profile/region/model:

• aws sts get-caller-identity --profile <profile> — succeeds
• aws bedrock-runtime invoke-model --profile <profile> --region us-east-1 --model-id us.anthropic.claude-opus-4-8 ... — succeeds, returns a real response

Notably it's not limited to InvokeModel — ListInferenceProfiles fails with the identical error, which points at something in Claude Code's Bedrock SDK client itself (stale/mis-signed request object) rather than a permissions or region issue.

Workaround observed: an already-running/warm Claude Code session continues to work; only fresh/cold claude process starts hit this.

macOS repro: 2.1.207 fails, 2.1.206 works — identical env and credentials

Environment:

• Claude Code versions: 2.1.206 (works), 2.1.207 (fails)
• OS: macOS (Apple Silicon)
• Auth: AWS SSO profile (AIUsers), credentials confirmed valid via aws sts get-caller-identity
• Region: us-west-2
• Install method: native binary

Repro (clean env, same credentials, same machine):

# Fails:
env -i HOME=$HOME PATH=$PATH AWS_PROFILE=AIUsers AWS_DEFAULT_REGION=us-west-2 CLAUDE_CODE_USE_BEDROCK=1 \
  ~/.local/share/claude/versions/2.1.207 --print "say hi"
# API Error: UnauthorizedException: Session token not found or invalid

# Works:
env -i HOME=$HOME PATH=$PATH AWS_PROFILE=AIUsers AWS_DEFAULT_REGION=us-west-2 CLAUDE_CODE_USE_BEDROCK=1 \
  ~/.local/share/claude/versions/2.1.206 --print "say hi"
# Hi Adam! Ready to help...

The clean-env test rules out shell environment interference — the only variable is the binary version. aws sts get-caller-identity succeeds in both cases.

Workaround: symlink ~/.local/bin/claude to 2.1.206 (requires locking with chflags uchg to prevent Desktop app from updating it back).

Confirming the same regression and fix on WSL2/Ubuntu: 2.1.207 fails with identical "Session token not found or invalid" on every cold start, pinning to 2.1.206 (via curl -fsSL https://claude.ai/install.sh | bash -s -- 2.1.206) resolves it completely.

Note for anyone using the VS Code extension: pinning the CLI binary alone isn't enough the extension have a separate Claude Code install (probably also on 2.1.207) independent of whatever's on PATH. Had to separately downgrade via Extensions panel → gear icon → "Install Another Version" to a pre-2.1.207 release. Confirmed working after both were pinned.

Also hitting this exact issue — adding a data point from a different environment, since this report is currently labeled platform:wsl and mine isn't WSL at all.

Environment

• Claude Code version: 2.1.207
• OS: native Linux (remote/SSH host, not WSL)
• Auth method: AWS SSO profile (AWS_PROFILE), assumed role via IAM Identity Center, Administrator-level permission set
• Region: ap-southeast-1
• Model: Sonnet 5 (global.anthropic.claude-sonnet-5[1m])
• Provider: Amazon Bedrock (CLAUDE_CODE_USE_BEDROCK=1)

What's happening

Identical error — API Error: UnauthorizedException: Session token not found or invalid — on every interactive turn in a new Claude Code session, including /doctor, /model, and plain messages. Already-running sessions started before the problem began keep working fine.

What we've ruled out

• aws sso login --profile <profile> — succeeds, no change to the bug
• Cleared ~/.aws/sso/cache/ and re-logged in from scratch — no change
• env | grep AWS in the shell — clean, nothing exported (auth is configured via ~/.claude/settings.json's env block, not shell exports)
• Re-ran /setup-bedrock from scratch:
• Verification step succeeded (assumed-role authenticated, 14 Anthropic inference profiles found in-region)
• Per-model one-token test calls succeeded for Sonnet, Opus, and Haiku
• Saved config identical to what was already in place
• Immediately opened a new session and sent a message — failed instantly with the same error

That last sequence feels like the cleanest repro so far: the wizard's own live Bedrock test calls succeed using the exact same credentials, seconds before an interactive message using that just-verified, just-saved config fails. That points away from anything AWS-side (expired/invalid credentials, permissions, SSO session) — those were independently proven valid by Claude Code's own code moments earlier.

Version correlation (not a clean isolated test, but another data point)

A second, separate machine (macOS) still on 2.1.206, same AWS_PROFILE-based config shape, same region, same model — works fine. Only the Claude Code version differs (the Linux box auto-updated to 2.1.207; the Mac hasn't yet). OS also differs between the two machines, so this doesn't isolate version as the sole variable, but it's consistent with your finding that this isn't purely WSL-specific.

/status on the broken instance

Version:          2.1.207
API provider:     Amazon Bedrock
AWS region:       ap-southeast-1
Model:            sonnet (global.anthropic.claude-sonnet-5[1m])
Setting sources:  User settings, Project local settings

Reproduction sequence

[/setup-bedrock wizard]
✔ Authenticated as arn:aws:sts::<redacted-account-id>:assumed-role/AWSReservedSSO_AdministratorAccess_.../<redacted>
Found 14 Anthropic inference profiles in this region.

✔ Sonnet → global.anthropic.claude-sonnet-5[1m]
✔ Opus   → global.anthropic.claude-opus-4-8[1m]
✔ Haiku  → global.anthropic.claude-haiku-4-5-20251001-v1:0

✔ Verified as arn:aws:sts::<redacted-account-id>:assumed-role/AWSReservedSSO_AdministratorAccess_.../<redacted>
→ Saved.

[fresh session, immediately after]
 Claude Code v2.1.207
 Sonnet 5 · Amazon Bedrock

❯ ping
● API Error: UnauthorizedException: Session token not found or invalid

Happy to grab verbose/debug logs or run other diagnostics if that would help narrow it down — let me know what would be useful.

Got same issue.

Environment

• Claude Code: fails on 2.1.207, works on 2.1.206
• OS: Ubuntu on WSL2 (Windows)
• Auth: AWS SSO via Bedrock (CLAUDE_CODE_USE_BEDROCK=1, AWS_PROFILE only)
• Region: eu-west-2

Key data point — this is version-specific.
2.1.207 fails on every request with UnauthorizedException: Session token not found or invalid. Symlinking the claude binary back to 2.1.206 — same credentials, same profile, same shell/session, no re-auth — works immediately. So the credentials are valid; something in the 2.1.207 Bedrock auth path changed between 2.1.206 and 2.1.207.

This lines up with the original report ruling out SSO-token expiry (raw aws bedrock-runtime invoke-model succeeds with the same creds. Downgrading to 2.1.206 is a reliable workaround for now.

Same issue, downgrading to v2.1.202 and v2.1.206 fixes the issue. Also macOS based. Just adding another datapoint.

It seems this issue has been addressed and fixed by the latest release below. Great.

Fixed Bedrock auth failing with "Session token not found or invalid" for AWS SSO profiles whose sso_region differs from the Bedrock region (2.1.207 regression) https://github.com/anthropics/claude-code/releases/tag/v2.1.208

Confirming this also reproduces via a third client surface beyond the CLI/VS Code extension: Zed's external agent (@agentclientprotocol/claude-agent-acp, the ACP wrapper Zed uses to run Claude as an external agent). This wrapper doesn't shell out to the claude binary — it depends directly on @anthropic-ai/claude-agent-sdk.

My ~/.aws/config profile has sso_region = eu-west-1 while the Bedrock region is us-west-2 — an exact match for the root cause named in the fix note for v2.1.208 ("AWS SSO profiles whose sso_region differs from the Bedrock region").

Gap for anyone using Zed's Claude agent: @agentclientprotocol/claude-agent-acp@0.59.0 (published 2026-07-13, npm latest as of this comment) still depends on @anthropic-ai/claude-agent-sdk@0.3.207 — a pre-fix SDK version. So even though the CLI is fixed in 2.1.208, Zed users hit this until claude-agent-acp bumps its SDK dependency to 0.3.208+ and cuts a new release.

Workaround for Zed users in the meantime: in settings.json, switch the claude-acp entry under agent_servers from "type": "registry" to "type": "custom" with an explicit pinned command, since Zed's shared registry.json silently rewrites any version pin back to latest:

"agent_servers": {
  "claude-acp": {
    "type": "custom",
    "command": "npx",
    "args": ["-y", "@agentclientprotocol/claude-agent-acp@0.58.1"]
  }
}

Confirmed working on Claude Code v2.1.208