[BUG] /login → Third-party → Claude Platform for AWS re-auth loops back to the top-level login menu; underlying 401 retries ~10× before surfacing

Summary

When authenticating via the new /login → Third-party → Claude Platform for AWS flow (no Claude.ai subscription; AWS STS via OIDC with awsAuthRefresh configured), two coupled problems occur:

1. Menu re-entry loop (primary). Each time I complete authentication from the Third-party / Claude Platform for AWS path, Claude Code returns me to another top-level /login menu rather than to a signed-in session. Re-authenticating bounces back to the top-level menu again, and the cycle repeats. I have not been able to confirm whether this is finite or infinite — I bail out before it terminates on its own. (After bailing, it typically triggers one more time and then stops.)

1. 401 retry loop before the prompt (underlying). The Please run /login · API Error: 401 The security token included in the request is expired message is preceded by a burst of automatic retries against the expired AWS STS token. In my session transcripts this burst is finite and exponential-backoff-capped at ~10–11 attempts before the prompt is surfaced (see Evidence). This is likely the "~10 times" cap an operator perceives as a loop.

The net experience: the credential that actually applies here (awsAuthRefresh) is never exercised, and the menu flow can't reach a signed-in state, so the user is stuck cycling through login menus.

Environment

• Claude Code 2.1.187
• macOS (Darwin 25.4.0)
• Authentication: Claude Platform for AWS via OIDC — no Claude.ai / Anthropic API subscription
• ~/.claude/settings.json contains "awsAuthRefresh": "okta-aws-cli web" (plus CLAUDE_CODE_USE_ANTHROPIC_AWS=1, an ANTHROPIC_AWS_WORKSPACE_ID, region, and an AWS profile — org-specific values redacted)

Steps to reproduce

1. Configure Claude Code for Claude Platform for AWS (OIDC), with awsAuthRefresh set to your org's STS refresh command. No Claude.ai subscription.
2. Use Claude Code until the AWS STS session expires mid-session.
3. Observe the automatic retry burst, then Please run /login · API Error: 401 ... token expired.
4. Run /login → Third-party → Claude Platform for AWS, complete authentication.
5. Observe that you are returned to the top-level /login menu rather than a signed-in session.
6. Repeat step 4 → returns to the top-level menu again. The cycle repeats.

Evidence

Menu re-entry loop (this bug)

The top-level-menu re-entry after a successful Third-party → Claude Platform for AWS authentication is a /login TUI state-machine behavior and is not captured in conversation transcripts. It is reported here from direct observation on 2.1.187 (the refresh-credentials option itself shipped in 2.1.186 — see #70136). Whether it terminates after a fixed number of cycles or is unbounded is unclear — I exit before it resolves; after exiting it usually fires once more and then stops.

Underlying 401 retry burst (quantified in #67529)

The Please run /login prompt is preceded by a bounded retry burst against the expired STS token:

Please run /login · API Error: 401 The security token included in the request is expired

I've added the full data to #67529: across one session the error appears 82× in 11 bursts, steady-state ~10–11 retries over ~200s with exponential backoff before the prompt — finite, not infinite, and the configured awsAuthRefresh is never invoked on this path.

Expected behavior

• Completing authentication via /login → Third-party → Claude Platform for AWS should return to a signed-in session, not to the top-level login menu.
• When the expiring credential is the AWS STS token and awsAuthRefresh is configured, the 401 path should run the configured awsAuthRefresh command (transparently, or via the menu entry) rather than retry the expired token ~10× and then drop the user into a menu whose options don't apply to Claude Platform for AWS.

Relationship to my earlier reports

This bug sits exactly at the seam between two requests I filed:

• #67530 — [FEATURE] Add "Claude Platform for AWS" / awsAuthRefresh entry to /login Third-party menu. This is the menu path that now exists and that I'm exercising here. The feature is the right idea, but as currently wired it loops back to the top-level menu instead of completing sign-in — so the menu entry exists but doesn't close the loop it was meant to close.
• #67529 — [BUG] "Please run /login · API Error: 401 ... token expired" has no recovery path when using Claude Platform for AWS (awsAuthRefresh configured). This new report is the observed runtime manifestation of #67529: the recovery path still doesn't trigger awsAuthRefresh / the Claude Platform for AWS auth directly, and now additionally loops. The two should likely be fixed together — completing the menu action should invoke awsAuthRefresh and return to a signed-in state.

Suggested fixes

1. After a successful Third-party / Claude Platform for AWS authentication, transition to the signed-in state, not back to the top-level /login menu (fixes the re-entry loop).
2. On a 401 whose credential is the AWS STS token (i.e., awsAuthRefresh is configured), invoke awsAuthRefresh rather than retrying the expired token to the backoff cap (addresses #67529 and removes the ~10× retry burst).
3. If the retry-before-prompt behavior is kept, cap it lower and label it ("refreshing credentials…") so it doesn't read as a hang/loop.

Related

• #67530 (companion feature — the menu entry I requested)
• #67529 (companion bug — recovery path doesn't trigger awsAuthRefresh; full 401-retry data added there)
• #70136 (docs companion — the new 2.1.186 /login refresh-credentials option; docs contradict it)
• #28032 (closed, Bedrock — "ExpiredTokenException should fast-fail instead of retrying"; same anti-pattern)