[BUG] [BUG] All new claude CLI processes return "API Error: Rate limit reached" for 8+ hours on WSL — existing VSCode session unaffected

[dbolas]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

Every new claude CLI process fails immediately with:
API Error: Rate limit reached

This has persisted for 8+ hours without any recovery.

Commands tested — all return the same error:

• /p/prompts:create-vitejs-app
• npx aiblueprint-cli claude-code pro setup
• cd ~/.claude/scripts && claude "/fix-on-my-computer"
• cd ~/.claude && claude "/debug-ccli"

Key observation: my current VSCode extension session works normally (full conversations, 8% context used). Only NEW CLI process spawning is broken.

This confirms the issue is NOT a usage-based rate limit — existing sessions are unaffected. The rate limit state appears stuck on the account, or new CLI processes on WSL are failing to authenticate properly and falling back to a rate limit error instead of an auth error.

Environment:

• OS: Windows 10 Pro + WSL (Ubuntu)
• Plan: Claude Max 5x (default_claude_max_5x)
• Model: claude-opus-4-6
• Mode: bypass permissions enabled
• Claude Code: VSCode extension

Expected: New CLI sessions should authenticate and work normally.
Actual: Every new CLI invocation fails with "API Error: Rate limit reached" immediately, for 8+ hours.

What Should Happen?

New claude CLI sessions should authenticate normally and execute commands.
The rate limit error should either not appear (if quota is available) or
reset after a reasonable time window — not persist for 8+ hours on a
Claude Max 5x plan.

Error Messages/Logs

API Error: Rate limit reached

Steps to Reproduce

1. Install Claude Code on WSL (Windows Subsystem for Linux)
2. Enable bypass permissions mode
3. Run any of the following commands:
   • /p/prompts:create-vitejs-app
   • npx aiblueprint-cli claude-code pro setup
   • claude "/fix-on-my-computer"
   • claude "/debug-ccli"
4. Observe: "API Error: Rate limit reached" immediately
5. Wait hours, retry — same error persists
6. Open VSCode extension → works normally

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

2.1.71 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

WSL (Windows Subsystem for Linux)

Additional Information

Account tier: Claude Max 5x (default_claude_max_5x)
The VSCode extension session works fine simultaneously —
proving quota is not genuinely exhausted. Only new CLI
process spawning is affected. Suspected cause: WSL
authentication token not refreshing properly for new
processes, falling back to a misleading rate limit error.

[github-actions]

Found 3 possible duplicate issues:

1. [BUG] CLI-only "API Error: Rate limit reached" on every request despite 97% quota remaining (Max 20x plan) #28096
2. CLI returns "API Error: Rate limit reached" on every command including logout (native binary, Max plan) #27336
3. Session permanently stuck on 'Rate limit reached' after transient rate limit #26699

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

[dbolas]

Update: This is not exactly a duplicate — my situation has one key distinction: my VSCode extension session works perfectly in parallel while new CLI processes fail immediately. This proves the quota is not exhausted and that the issue is isolated to new process authentication, not an actual rate limit.

I have voted 👍 on #28096 as the closest match.

Workaround attempted: Running claude logout && claude login from WSL — will report back whether this resolves the issue.

Keeping this ticket open because the specific behavior (VSCode session OK + CLI broken simultaneously) deserves to be documented separately, as it points to a token sharing/refresh bug between WSL and Windows rather than a genuine rate limit issue.

[shinertx]

This looks more like a runtime control problem than a model-choice problem. Worth tracing retries, fallback churn, and repeated context replay once 429s start. Disclosure: I build Agent Firewall by Vibe Billing, and if useful I can share the local scan I use to spot this pattern.

[github-actions]

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

[github-actions]

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.