[BUG] awsAuthRefresh startup pre-check hangs indefinitely on SSO profiles behind a proxy (>2.1.187 regression — SSO-OIDC call bypasses HTTPS_PROXY)
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?
When ~/.claude/settings.json sets "awsAuthRefresh": "aws sso login --profile <sso-profile>" against an AWS SSO-based profile, Claude Code versions newer than 2.1.187 hang indefinitely on startup (10+ minutes, until manually killed) before ever reaching the model. There is no error and no output — it just hangs. Confirmed reproducible on 2.1.223 and 2.1.224, on both Windows and Linux dev machines behind a corporate proxy.
What Should Happen?
The startup credential pre-check should either respect HTTPS_PROXY/https_proxy for all AWS calls it makes (including the SSO-OIDC token validate/refresh call, not just the STS GetCallerIdentityCommand call), or it should apply a bounded timeout so a network that silently drops direct-to-internet egress fails fast instead of hanging forever.
Error Messages/Logs
No error is printed under normal operation — the process just hangs. Running with --debug shows the pre-check start but never a completion:
[API:auth] AWS credential resolve start
(process then hangs with no further output until killed)
strace comparison between the last-known-good version and the first-broken version shows the actual divergence:
- 2.1.187 (works): resolves the configured proxy host, CONNECTs through the corporate proxy (<proxy-ip>:8080, from HTTPS_PROXY), reaches sts.<region>.amazonaws.com in ~565ms.
- 2.1.223 (hangs): resolves oidc.<region>.amazonaws.com directly and connects straight to raw AWS IPs (observed: 16.58.206.166, 3.150.150.167, 3.151.142.82) on port 443, completely bypassing HTTPS_PROXY. On a network that silently black-holes direct-to-internet egress (no RST, no refusal — just silence), the connect() sits in EINPROGRESS forever.
Binary string-diffing the two releases' embedded Bun runtime:
- 2.1.187's Bun build has no setGlobalProxyFromEnv function.
- 2.1.223's Bun build has one (with a literal proxyEnv: env field) — but empirically it is not applied to the AWS SDK's NodeHttpHandler call path for the SSO-OIDC client. The STS client's proxy support appears to be wired correctly; the SSO-OIDC client's is not.
Steps to Reproduce
- Configure an AWS profile backed by SSO (e.g. aws configure sso --profile my-sso-profile), on a network that requires a proxy (HTTPS_PROXY/https_proxy set) to reach *.amazonaws.com and that drops (does not reject) direct-to-internet traffic.
- In ~/.claude/settings.json, set:
"awsAuthRefresh": "aws sso login --profile my-sso-profile"
- Ensure Claude Code is configured to use this AWS profile for its model provider (Bedrock).
- Run claude (any version >2.1.187, confirmed on 2.1.223 and 2.1.224).
- Observe: process hangs indefinitely at startup, never reaches a prompt. Confirmed via --debug that it stalls right after [API:auth] AWS credential resolve start, and via strace/tcpdump that the process is attempting a direct connection to oidc.<region>.amazonaws.com IPs rather than tunneling through the configured proxy.
- Downgrade to Claude Code 2.1.187 with the same settings/profile — startup completes normally in <1s for the credential check.
Claude Model
Other
Is this a regression?
Yes, this worked in a previous version
Last Working Version
2.1.187
Claude Code Version
2.1.223
Platform
AWS Bedrock
Operating System
Windows
Terminal/Shell
PowerShell
Additional Information
- Confirmed on two independent environments — a Windows dev machine and a Linux (CentOS Stream 9) dev machine — both behind the same corporate proxy infrastructure, both using an AWS SSO profile for Bedrock access.
- The Claude Code CLI binary is a compiled Bun executable (confirmed via Bun.version/Bun.serve/JavaScriptCore strings), not a plain Node.js script. Claude Code's own proxy-awareness code (configureGlobalAgents) appears to only patch its internal axios instance and the undici fetch dispatcher used for its own API/model calls — it does not patch the raw Node-compatible http/https global agent that the AWS SDK's default NodeHttpHandler uses. Whether that global agent respects proxy env vars is apparently controlled by Bun's own compiled-in http/https reimplementation for that specific release, not by anything in Claude Code's JS/TS
layer or its settings/env vars.
- Things tried that did NOT fix it (to save reviewers time re-suggesting these):
- CLAUDE_CODE_HTTPS_PROXY / CLAUDE_CODE_HTTP_PROXY env vars — no effect.
- GLOBAL_AGENT_HTTP_PROXY / GLOBAL_AGENT_HTTPS_PROXY — no effect (unrelated npm package convention; was a false lead from string-matching the binary).
- NODE_USE_ENV_PROXY=1 — no effect.
- CLAUDE_CODE_AWS_CHAIN_RESOLVE_TIMEOUT_MS=3000 — no effect; this timeout does not wrap the specific hanging pre-check, only a later credential-chain resolution step.
- Unsetting AWS_PROFILE for the invocation — still hangs, just against the default us-east-1 STS/OIDC endpoints instead — same underlying bug.
- --settings '{"awsAuthRefresh":false}' CLI override — does not actually take effect (setting still shows as active in debug logs).
- Proxy-side allowlist/ACL changes (allowing oidc..amazonaws.com, sts..amazonaws.com) — no effect, and can't have one: strace shows 2.1.223 never attempts a CONNECT to the proxy for the OIDC call at all, so the proxy never sees this traffic to allow or deny.
- Working workarounds (for anyone hitting this before a fix ships):
a. Remove/comment out "awsAuthRefresh" from ~/.claude/settings.json — skips the pre-check entirely; run aws sso login --profile <profile> manually when the session expires.
b. Pin affected machines to Claude Code ≤2.1.187 until this is fixed.
- Regression window: changelog shows several AWS SSO credential-handling changes in the 2.1.206–2.1.217 range, though none explicitly name the OIDC endpoint — happy to help bisect further if useful.
- Environment: claude --version → 2.1.224 (also reproduced on 2.1.223); network is a corporate proxy environment that requires HTTPS_PROXY for all internet-bound traffic and silently drops (no TCP reset) any direct egress attempt.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗