[BUG] Claude Code Cannot Handle API Requests >5 Minutes Long

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?

Using Claude Code with backends that are a little bit slow, I've been getting consistent timeouts once the context window causes responses from the v1/messages/ endpoint to take >=5 minutes.

It took me a little while to figure out how to fix this - at first I thought it was a bug in Ollama, but the same thing happens with other backends such as llama.cpp and LM Studio, and I didn't see any error responses over Wireshark - it looks like Claude is closing the connection after a preset timeout.

None of the environment variables I could find worked to adjust this timeout. I tried $BASH_DEFAULT_TIMEOUT_MS, $BASH_MAX_TIMEOUT_MS, $API_TIMEOUT_MS, $CLAUDE_CODE_STALL_TIMEOUT_MS_FOR_TESTING...nothing.

So I asked Claude to debug itself, and it was able to pick apart the claude binary and figure out what was going wrong.

It looks like there's a hardcoded timeout in the Bun middleware that can be disabled or configured, but Claude is calling it in a way that accepts the default. So for v2.1.84, I had to run the following patch to fix the issue:

sed -i 's/if\(H\?\.forAnthropicAPI\)\{let T=process\.env\.ANTHROPIC_UNIX_SOCKET;if\(T&&typeof Bun<"u"\)return\{unix:T\}\}/if(H?.forAnthropicAPI){return{timeout:!1} }/g' /path/to/claude

And that actually seems to work. It's minified code, but it should point you to where it could be fixed in the actual claude repo. This was also suggested, and I ran it first but it didn't actually fix things. Still, it might be a prereq?

sed -i 's/this\.requestTimeout = 300000/this.requestTimeout = 900000/' /path/to/claude

So anyways, I'd like to avoid needing to do this with a slightly different patch every time Claude updates, so if y'all could add a configurable timeout with an env var like $CLAUDE_SOCKET_TIMEOUT_MS or something, that would be greeeeat. Thank you!

What Should Happen?

Claude should be able to wait more than 5 minutes for its next thought to arrive.

I know the kids are all about instant gratification these days, but come on.

Error Messages/Logs

The most relevant error logs are just:

`Request timed out`

When I set `$API_TIMEOUT_MS` to a nondefault value, it prints this instead:

`Request timed out (API_TIMEOUT_MS=1800000ms, try...`

But that's about it. Even the debug logs don't provide much more info, so I had to dig into Wireshark and guess from the backend request logs (and ask an LLM) to figure out what was going on.

Steps to Reproduce

1. Run a local LLM backend, set it to CPU-only inference to slow things down and make the bug easier to trigger.
2. Talk with Claude for awhile to build up a non-trivial context window.
3. Eventually, when the chat API requests start taking 5 minutes to return, API request timeouts will start to occur. Progress becomes blocked until a new context window is started, but it happens for me around 2-10k tokens so...it's a tough bug to work around.

Claude Model

Other

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.84

Platform

Other

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

I did find a fix to patch the binary - it's one or both of these:

sed -i 's/this\.requestTimeout = 300000/this.requestTimeout = 900000/' /path/to/claude
(this was a first attempt that didn't work, probably isn't the culprit)

sed -i 's/if\(H\?\.forAnthropicAPI\)\{let T=process\.env\.ANTHROPIC_UNIX_SOCKET;if\(T&&typeof Bun<"u"\)return\{unix:T\}\}/if(H?.forAnthropicAPI){return{timeout:!1} }/g' /path/to/claude
(this fixed the issue, after the prior patch was run but I think it's probably unrelated. Not sure if the extra spaces are really needed to preserve file length/addresses)

You'd probably want a more comprehensive fix that doesn't break unix socket support and makes the timeout configurable, but that should at least point to where the problem _is_.

So hopefully this would be pretty quick to fix. Please and thank you!