[BUG] "Please run /login · API Error: 401 ... token expired" has no recovery path when using Claude Platform for AWS (awsAuthRefresh configured)

Companion feature request filed: #67530 — adding a /login Third-party menu entry that triggers awsAuthRefresh would give Claude Platform for AWS users a working recovery path from this 401.

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/60938
2. https://github.com/anthropics/claude-code/issues/2280
3. https://github.com/anthropics/claude-code/issues/41064

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

Hey @arcaven, this is a data integrity / trust boundary issue and it's worth treating it as one regardless of root cause.

Quick diagnostic that separates "bug" from "model behavior" from "tool side-effect":

1. Reproduce with tool output logging: Run Claude Code with --debug and capture the tool call sequence. Check whether the delete/corruption happens during a Write, Edit, or Bash tool call — each has a different trust model
2. Permission scope audit: claude config list → check permissions.allow and permissions.deny. If Bash is allowed without dangerouslySkipPermissions, the model can execute destructive commands. The default is increasingly permissive as sessions accumulate
3. Workspace trust boundary: Is this happening inside ~/.claude/ or your project directory? If it's deleting outside the workspace, that's a sandboxing issue — Claude Code's workspace isolation is path-based, not syscall-based
4. Recovery test: Before relying on .claude/backups/, verify they actually contain the files you expect. I've seen backup mechanisms silently skip files when the session crashes mid-write

If you're running this in a team/dev environment, I'd strongly recommend a trust-scope hardening pass — the defaults are optimized for solo use and get risky at team scale. Happy to share what's worked for me.

Hey @arcaven, this is a data integrity / trust boundary issue and it's worth treating it as one regardless of root cause. Quick diagnostic that separates "bug" from "model behavior" from "tool side-effect": 1. Reproduce with tool output logging: Run Claude Code with --debug and capture the tool call sequence. Check whether the delete/corruption happens during a Write, Edit, or Bash tool call — each has a different trust model 2. Permission scope audit: claude config list → check permissions.allow and permissions.deny. If Bash is allowed without dangerouslySkipPermissions, the model can execute destructive commands. The default is increasingly permissive as sessions accumulate 3. Workspace trust boundary: Is this happening inside ~/.claude/ or your project directory? If it's deleting outside the workspace, that's a sandboxing issue — Claude Code's workspace isolation is path-based, not syscall-based 4. Recovery test: Before relying on .claude/backups/, verify they actually contain the files you expect. I've seen backup mechanisms silently skip files when the session crashes mid-write If you're running this in a team/dev environment, I'd strongly recommend a trust-scope hardening pass — the defaults are optimized for solo use and get risky at team scale. Happy to share what's worked for me.

I don't believe so, although I might not be understanding. I believe this is simply some error handling that assumes too much, probably from a time earlier when /login handled all cases, while another execution branch should be triggering a refresh of the Claude Platform awsAuthRefresh, it instead triggers a generic/general/legacy error handling and the incorrect (for this edge case) user prompting to use /login

But then, it could be me who is misunderstanding and you might have a deeper understanding here than I can integrate, and I may have a blocking prejudice. I didn't read the Claude Code code. It's black box and I'm making assumptions on observed/expected behavoir.

Adding quantified technical data for this on Claude Code 2.1.187 (macOS, Claude Platform for AWS via OIDC, awsAuthRefresh = okta-aws-cli web, no subscription).

The "no recovery path" here is preceded by a bounded retry burst against the already-expired AWS STS token before Please run /login is surfaced. Pulled from my session transcripts, the error API Error: 401 The security token included in the request is expired appears 82 times across 11 distinct bursts in one session, with a consistent shape:

| Burst | Retries | Span | Interval shape |
|------:|--------:|------|----------------|
| 2 | 9 | 114s | ~1.3 → 1.9 → 2.9 → 5 → 9 → 20 → 37s |
| 4 | 11 | 205s | exponential backoff |
| 5 | 11 | 198s | exponential backoff |
| 6 | 11 | 200s | exponential backoff |
| 7 | 11 | 196s | exponential backoff |
| 9 | 10 | 164s | exponential backoff |

So steady-state it's ~10–11 retries over ~200s against the expired token before the prompt appears — the configured awsAuthRefresh is never invoked on the 401 path. This matches the "fast-fail / refresh instead of retry" point raised for Bedrock in #28032; the same applies to Claude Platform for AWS.

Update: as of v2.1.186 a "Claude Platform on AWS – refresh credentials" option was added to /login (see #70136). On 2.1.187 that option does not close the loop — completing it returns to the top-level /login menu and repeats. Filed separately as #70642 since it's a distinct /login state-machine issue layered on top of this 401 path.

Hey @arcaven, this is a data integrity / trust boundary issue and it's worth treating it as one regardless of root cause. Quick diagnostic that separates "bug" from "model behavior" from "tool side-effect": 1. Reproduce with tool output logging: Run Claude Code with --debug and capture the tool call sequence. Check whether the delete/corruption happens during a Write, Edit, or Bash tool call — each has a different trust model 2. Permission scope audit: claude config list → check permissions.allow and permissions.deny. If Bash is allowed without dangerouslySkipPermissions, the model can execute destructive commands. The default is increasingly permissive as sessions accumulate 3. Workspace trust boundary: Is this happening inside ~/.claude/ or your project directory? If it's deleting outside the workspace, that's a sandboxing issue — Claude Code's workspace isolation is path-based, not syscall-based 4. Recovery test: Before relying on .claude/backups/, verify they actually contain the files you expect. I've seen backup mechanisms silently skip files when the session crashes mid-write If you're running this in a team/dev environment, I'd strongly recommend a trust-scope hardening pass — the defaults are optimized for solo use and get risky at team scale. Happy to share what's worked for me.

@abhinas90 I did misunderstand, thank you! Where can I find information on what's worked for you? I am reflecting on this as a trust boundary issue even within the solo operator at this point.