[BUG] Persistent 120s API timeout on heavy requests - 24+ hours (March 19-20, 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?
Bug Description
Claude Code API requests consistently hang for 120 seconds then fail with 500 Internal Server Error. This has been ongoing for 24+ hours (since March 19, 2026 ~15:00 KST / 06:00 UTC).
Key observation: Light requests (tool calls, short responses) succeed in 3-7 seconds, but heavy requests (large context + content generation) always timeout at exactly 120 seconds. The server accepts the connection but never completes the response.
Environment
- Claude Code version: 2.1.80
- OS: Windows 11 (WSL2), Docker container (Ubuntu-based)
- Models tested:
claude-opus-4-latest,claude-sonnet-4-6— both fail identically - Setup: Claude Code inside Docker → claude-code-monitor proxy →
https://api.anthropic.com - Effort levels tested: high, max — no difference
Reproduction
- Run any Claude Code task that requires significant token generation (e.g., generating SRT subtitle timestamps from a speech analysis file)
- Request hangs for exactly 120 seconds
- Fails with: `Error forwarding to anthropic API: failed to forward request: Post
"https://api.anthropic.com/v1/messages?beta=true": context canceled`
What I've Verified
- Not a client-side issue: Direct (non-Docker) Claude Code also experiences extreme slowness (27 minutes for a simple file-read task that normally takes seconds)
- Not a rate limit: No 429 errors. The server accepts connections but hangs silently
- Not model-specific: Both Opus 4.6 and Sonnet 4.6 fail identically
- Not a config issue: Proxy timeouts are set to 10 minutes. The 120s cutoff comes from Claude Code's internal client timeout - Not an auth issue: API key is valid — light requests succeed fine
Expected Behavior
- Heavy requests should complete within a reasonable time, OR
- The server should return a proper 429/529 error immediately instead of accepting the connection and hanging for
120 seconds
Impact
All content-generation workflows are completely blocked. Only trivial tool-call responses work. This effectively makes Claude Code unusable for any real task.
Related Issues
- #35508 — March 17, Windows 500 errors
- #35484 — Persistent 500 across all models
- #28624 — Intermittent 500 on Opus 4.6
- anthropics/claude-code-action#1079 — OIDC 500 since March 18
What Should Happen?
Expected Behavior
- Heavy requests should complete within a reasonable time, OR
- The server should return a proper 429/529 error immediately instead of accepting the connection and hanging for
120 seconds
Error Messages/Logs
## Proxy Logs (UTC)
Pattern: light requests succeed, heavy requests always timeout
2026/03/20 12:29:05 POST /v1/messages 500 Internal Server Error (120.00s) ← heavy
2026/03/20 12:29:06 POST /v1/messages 200 OK (3.21s) ← light
2026/03/20 12:29:12 POST /v1/messages 200 OK (4.91s) ← light
2026/03/20 12:29:19 POST /v1/messages 200 OK (7.25s) ← light
2026/03/20 12:31:06 POST /v1/messages 500 Internal Server Error (120.00s) ← heavy
2026/03/20 12:33:08 POST /v1/messages 500 Internal Server Error (120.00s) ← heavy
This pattern has repeated every ~2 minutes for 24+ hours
Occasionally a streaming response starts but dies at 300s:
2026/03/20 12:25:05 Streaming error: context deadline exceeded (300.19s)
Steps to Reproduce
Reproduction
- Run any Claude Code task that requires significant token generation (e.g., generating SRT subtitle timestamps from a speech analysis file)
- Request hangs for exactly 120 seconds
- Fails with: `Error forwarding to anthropic API: failed to forward request: Post
"https://api.anthropic.com/v1/messages?beta=true": context canceled`
Claude Model
Opus
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
2.1.80
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
WSL (Windows Subsystem for Linux)
Additional Information
_No response_
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗