[BUG] Stall in "Clearing AWS credential provider cache" at session start (Bedrock provider)

Resolved 💬 0 comments Opened Jul 7, 2026 by mjramer Closed Jul 8, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Every Claude Code session started against AWS Bedrock stalls for several minutes during startup before the first user prompt is dispatched to the model. The stall consistently occurs between two log lines emitted by Claude Code's own credential resolution path:

[DEBUG] Clearing AWS credential provider cache
... ~228,000 ms of silence ...
[DEBUG] Failed to clear AWS credential cache (this is expected if no credentials are configured)
[DEBUG] [API:auth] AWS credential resolve done in 228537ms (or 229359ms)

Immediately after the stall, Claude Code emits:

[ERROR] Bedrock ListInferenceProfiles failed: JSON Parse error: Unrecognized token '<'
[ERROR] Failed to list Bedrock inference profiles, falling back to hardcoded models

After the stall completes, the actual Bedrock invoke-with-response-stream call is fast (~2 seconds to first byte). The stall is entirely in the pre-request credential resolution phase.

The trailing "expected if no credentials are configured" message is misleading - credentials are configured (SSO), and they resolve successfully once the ~4 minute stall finishes.

What Should Happen?

Credential cache clearing should complete in milliseconds. Session startup should be under ~5 seconds end-to-end, matching the behavior seen on subsequent turns within the same process (where the resolve reports AWS credential resolve done in 0ms).

Error Messages/Logs

Relevant slice of the debug log (timestamps preserved, values redacted):


[DEBUG] [API:auth] AWS credential resolve start
[DEBUG] Running AWS credential export command
[DEBUG] AWS credentials retrieved from awsCredentialExport         <-- ~1s after start
[DEBUG] Clearing AWS credential provider cache                     <-- stall begins here
                                                                   <-- ~228 seconds elapse
[DEBUG] Failed to clear AWS credential cache (this is expected if no credentials are configured)
[DEBUG] [API:auth] AWS credential resolve done in 228537ms
[DEBUG] [API:timing] dispatching to bedrock model=<inference-profile-arn>
[ERROR] Bedrock ListInferenceProfiles failed: JSON Parse error: Unrecognized token '<'
  Deserialization error: to see the raw response, inspect the hidden field {error}.$response on this object.
[ERROR] Failed to list Bedrock inference profiles, falling back to hardcoded models: JSON Parse error: Unrecognized token '<'
[DEBUG] Stream started - received first chunk
[DEBUG] [API:timing] first byte after 2004ms                       <-- actual API call is fast


The `Unrecognized token '<'` from `ListInferenceProfiles` is a separate issue but co-occurs 100% of the time with the stall.

Steps to Reproduce

  1. Configure Claude Code to use AWS Bedrock with an SSO-based profile:
  • ~/.aws/config contains an [sso-session ...] block and a profile referencing it
  • Credentials are minted via an awsCredentialExport helper (custom shim that returns temporary STS creds from SSO)
  • Bedrock model is a regular inference-profile ARN or an application-inference-profile ARN (reproduced with both)
  1. Ensure no cached temporary credentials exist in the SDK's in-process cache (a fresh claude invocation always qualifies).
  2. Run claude --debug (any working directory).
  3. Type any message (e.g. hello) and hit enter.
  4. Observe:
  • ~228 seconds pass with no visible activity
  • The [API:auth] AWS credential resolve done in 228XXXms line appears
  • The message finally begins streaming from Bedrock
  • Bedrock ListInferenceProfiles failed appears in the log

Reproduces 100% of the time on cold start. Subsequent prompts in the same process return AWS credential resolve done in 0ms (credentials are cached in-process).

Reproduced by two independent users on two different macOS machines, both with similar minutes-long duration (228,537ms and 229,359ms). Different projects, different Bedrock inference profile types, different awsCredentialExport helper invocations.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

Unknown

Claude Code Version

2.1.202 (also reproduced on 2.1.195)

Platform

AWS Bedrock

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Investigation already performed

Extensive diagnostics were run to rule out common causes. Every AWS network path was verified fast and correct.

  1. Not IMDS. tcpdump capture during the stall shows zero packets to/from 169.254.169.254 for the full 228s window.
  2. Not the corporate proxy. A curl reproduction of the exact SSO GetRoleCredentials call that Claude Code makes at startup completes in 686ms through the same corporate proxy Claude Code uses. All other AWS API calls tested (sts:GetCallerIdentity, bedrock:ListInferenceProfiles, raw Bedrock endpoint, VPC endpoint) return in <1.1s through the proxy and return valid JSON/XML - no HTML mangling.
  3. Not DNS. All hostnames resolve in <100ms.
  4. Not the credential export shim. Log shows AWS credentials retrieved from awsCredentialExport within ~1s of AWS credential resolve start.
  5. No network activity during the stall window. tcpdump ran for the full 228s stall on the primary interface and captured no traffic to any AWS endpoint during that window. The stall is not blocked on a socket - it's blocked on something in-process.

Environment specifics

  • macOS (Darwin 25.5.0)
  • Corporate network with mandatory outbound proxy: HTTP_PROXY, HTTPS_PROXY, ALL_PROXY all set to a corporate proxy URL (Zscaler-style)
  • NO_PROXY contains internal DNS suffixes and two Bedrock VPC endpoints (vpce-*.bedrock-runtime.us-east-1.vpce.amazonaws.com)
  • TLS MITM: corporate root CA bundle appended via NODE_EXTRA_CA_CERTS
  • Claude Code loads this at startup: [DEBUG] CA certs: Appended extra certificates from NODE_EXTRA_CA_CERTS
  • AWS credentials sourced from AWS IAM Identity Center (SSO) with temporary STS credentials refreshed via SSO GetRoleCredentials
  • Bedrock accessed via a VPC endpoint (in NO_PROXY), not the public Bedrock endpoint

Hypothesis

Given zero network activity during the 228s window and identical duration on two separate machines, the stall is likely inside the SDK provider chain being walked by Clearing AWS credential provider cache. Candidates:

  • A promise inside the credential-clear path awaiting a resolver whose default timeout is ~228s
  • A file-lock or async barrier that only releases after a hardcoded timer
  • A subprocess or child process spawned during credential clearing that is being awaited

The consistent, near-identical duration (228,537ms vs 229,359ms) strongly suggests a hardcoded timeout somewhere, not a network-dependent stall.

The ListInferenceProfiles HTML response

The JSON Parse error: Unrecognized token '<' immediately following the stall is a separate issue that a direct curl to bedrock:ListInferenceProfiles through the same proxy could not reproduce (curl received a clean JSON {"Message":"Authorization header is missing"} response). The IAM role used lacks bedrock:ListInferenceProfiles permission, so AWS legitimately returns AccessDeniedException (JSON). It is unclear what path or endpoint Claude Code is calling that returns HTML/<; the response body is not logged, only the parse error.

Suggested improvement independent of the stall bug: log the raw response body (with credentials redacted) when the inference-profile fetch fails, so the actual response causing the parse error can be diagnosed by users.

Impact

  • Every cold claude startup takes ~4 minutes before the first prompt returns
  • Affects all users of AWS Bedrock behind a corporate proxy at the reporter's organization
  • Workaround: none identified - the stall is inside Claude Code's own credential-clearing path, not something users can bypass with env vars or config

View original on GitHub ↗