[BUG] awsAuthRefresh startup pre-check hangs indefinitely on SSO profiles behind a proxy (>2.1.187 regression — SSO-OIDC call bypasses HTTPS_PROXY)

Status Open
Reported on v2.1.187
Maintainer reply None cached
Activity 1 comment · opened Aug 7, 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?

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

  1. 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.
  2. In ~/.claude/settings.json, set:

"awsAuthRefresh": "aws sso login --profile my-sso-profile"

  1. Ensure Claude Code is configured to use this AWS profile for its model provider (Bedrock).
  2. Run claude (any version >2.1.187, confirmed on 2.1.223 and 2.1.224).
  3. 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.
  4. 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.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗