[BUG] `"awsAuthRefresh":` setting causes constant repeated auth attempts

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/9027
2. https://github.com/anthropics/claude-code/issues/10594
3. https://github.com/anthropics/claude-code/issues/9473

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Possible regression of #9027 although possibly unrelated.

This appears to be fixed in 2.0.56

Reopening as it was not fixed in 2.0.56

Is there a fix or workaround for this???

Still happening on 2.0.76. Is there any solution for this?

Hate to be a "me too", but this is breaking the flow for dozens of people here at my org.

Still seeing this issue in 2.1.2 and also causing issues for many in my org

Still broken in v2.1.7. Claude Code keeps opening AWS login pages in every 2 seconds.

I was hitting this problem until I noticed the role name was not the same as the one I had access to in AWS.

so, double check the values - account number, role name, and IAM configs.

edit: actually, nevermind.. it came back when I prompted something..

edit2: changed to Administrator role and it's working now, then I realized the account did not have the necessary IAM configuration set!

https://code.claude.com/docs/en/amazon-bedrock?search=autoUpdatesChannel#iam-configuration

edit2: changed to Administrator role and it's working now, then I realized the account did not have the necessary IAM configuration set! https://code.claude.com/docs/en/amazon-bedrock?search=autoUpdatesChannel#iam-configuration

Updated our IAM policy to match what the documentation says exactly and we're still getting the loop.

Still seeing this as of v2.1.23 Very annoying!

Noticed in debug logs (~/.claude/debug/latest) that it was looping on AWS login. We have a corporate VPN that MITM's our SSL traffic.

Running with env var NODE_TLS_REJECT_UNAUTHORIZED=0 solved my issue.

2026-01-29T18:33:13.970Z [DEBUG] [API:request] Creating client, ANTHROPIC_CUSTOM_HEADERS present: false, has Authorization header: false
2026-01-29T18:33:13.970Z [DEBUG] [API:auth] OAuth token check starting
2026-01-29T18:33:13.970Z [DEBUG] [API:auth] OAuth token check complete
2026-01-29T18:33:13.971Z [DEBUG] Fetching AWS caller identity for AWS auth refresh command
2026-01-29T18:33:14.039Z [DEBUG] Running AWS auth refresh command
2026-01-29T18:33:14.434Z [DEBUG] Attempting to open your default browser.
If the browser does not open, open the following URL:

https://oidc.us-east-1.amazonaws.com/<redacted>
2026-01-29T18:33:15.587Z [DEBUG] Successfully logged into Start URL: https://<redacted>
2026-01-29T18:33:15.645Z [DEBUG] AWS auth refresh completed successfully
2026-01-29T18:33:15.645Z [DEBUG] Clearing AWS credential provider cache
2026-01-29T18:33:15.698Z [DEBUG] Failed to clear AWS credential cache (this is expected if no credentials are configured)
2026-01-29T18:33:15.745Z [ERROR] API error (attempt 4/11): Error: self signed certificate in certificate chain

Can we get this fixed? This is extremely annoying.

This was happening to me with the latest version from Homebrew (2.1.31), and at least in my case, the following change solved the endless sso loop:

In ~/.aws/config, replace role_arn which had the full arn to the role I wanted claude code to use with sso_role_name.

In ~/.aws/config, replace role_arn which had the full arn to the role I wanted claude code to use with sso_role_name.

Unfortunately this was already set for me. Still having this issue.

Bump — I’m experiencing the exact same issue. Does anyone have a workaround?

Please provide a fix for this. :-)

I also had this issue, when I removed my ~/.aws/credentials file, it was resolved.
I don't need it because we're using aws sso login.
Good luck!

I also had this issue, when I removed my ~/.aws/credentials file, it was resolved.

That did it for me! Well technically I moved the file elsewhere just in case I do need it, but worked nonetheless.

I also had this issue, when I removed my ~/.aws/credentials file, it was resolved.

Wow this finally solved it for me! Thanks so much!

Workaround: Prevent the refresh loop with a smart wrapper

We hit this same issue (we needed to use the credentials approach) and debugged it thoroughly. The root cause for me was AWS credential propagation delay: after the awsAuthRefresh command writes new credentials, they take ~3-5 seconds to become valid on AWS's side. Claude Code retries immediately, gets another 403, triggers another refresh — which writes new credentials, resetting the propagation clock. This creates the loop.

The fix is to make your refresh command smarter with three guards:

1. Skip if credentials are fresh — if ~/.aws/credentials was written < 120 seconds ago, exit 0 immediately without refreshing. This prevents re-generating credentials that are still propagating.

1. Lock file — if multiple 403s fire (e.g. from concurrent sessions), only one instance runs the actual refresh. Others wait for it to finish, then exit cleanly.

1. Poll for validity after refresh — after writing credentials, poll aws sts get-caller-identity every 1s (up to 30s) before returning. This ensures Claude Code only retries once the credentials are confirmed working.

Create ~/.claude/scripts/aws-refresh.sh:

#!/bin/bash
CREDS_FILE="$HOME/.aws/credentials"
LOCKFILE="/tmp/aws-refresh.lock"
SKIP_IF_NEWER_THAN=120

# Skip if credentials were recently written (propagation delay, not actually expired)
if [ -f "$CREDS_FILE" ]; then
  if [[ "$OSTYPE" == "darwin"* ]]; then
    CREDS_AGE=$(( $(date +%s) - $(stat -f %m "$CREDS_FILE") ))
  else
    CREDS_AGE=$(( $(date +%s) - $(stat -c %Y "$CREDS_FILE") ))
  fi
  if [ "$CREDS_AGE" -lt "$SKIP_IF_NEWER_THAN" ]; then
    exit 0
  fi
fi

# Lock to prevent concurrent refreshes across sessions
if [ -f "$LOCKFILE" ]; then
  while [ -f "$LOCKFILE" ]; do
    sleep 1
  done
  exit 0
fi
trap "rm -f $LOCKFILE" EXIT
touch "$LOCKFILE"

# Run your actual refresh command here
[command]

# Poll until credentials are valid before returning
ELAPSED=0
while [ "$ELAPSED" -lt 30 ]; do
  if aws sts get-caller-identity --profile YOUR_PROFILE &>/dev/null; then
    exit 0
  fi
  sleep 1
  ELAPSED=$((ELAPSED + 1))
done
exit 0

Then chmod +x ~/.claude/scripts/aws-refresh.sh and update settings:

{
  "awsAuthRefresh": "~/.claude/scripts/aws-refresh.sh"
}

Replace [command] with what you're doing to get your token.

This completely eliminates the loop. The first refresh runs, polls until valid (~4s), and Claude recovers cleanly.

In our case, after getting this working I moved the guards code into the [command] js script that we run to refreash the token, for neatness, but this shell script approach works just fine.

This behaviour could probably be built into claude at some point, but until then this should get you going too.

On my side I'm using okta-aws-cli and I've managed to fix it by adding -e -x to the command line:

  - -e (--cache-access-token): Caches the Okta OIDC token to disk so subsequent runs don't need browser re-authentication within the token's validity period.
  - -x (--expiry-aws-variables): Writes x_security_token_expires into ~/.aws/credentials, so Claude Code can read the expiry time and know the credentials are still valid — skipping the refresh call entirely until they actually expire.

  Next time you run the refresh, it'll cache both the Okta token and the expiry timestamp. After that, Claude should stop prompting on every startup.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.