[BUG] Auto-compact hangs indefinitely on Bedrock: post-compact CountTokens call has no timeout and cannot be interrupted

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?

On AWS Bedrock, auto-compact sometimes never finishes. The summary itself completes normally, but the session then hangs right after it, with no further log output, for 20+ minutes (previously observed stalls of ~16, ~32 and ~48 minutes before recovering on their own).

Pressing Esc does not recover: [onCancel] is logged, but a subsequent /compact is only queued as a plain user message and never runs. The only recovery is to exit and claude --continue, after which /compact completes in under 2 minutes.

From the --debug log, the hang happens exactly where a Bedrock CountTokens request is normally issued after compaction. In healthy compactions in the same session, this request returns within 0.7-2 s (always with ValidationException: The provided model doesn't support counting tokens, so the result is not used anyway). In the hung case, it never returns. The process is idle (near-zero CPU), with only old keep-alive HTTPS connections to Bedrock open, and no new connection is created.

Looking at the bundled JS in 2.1.285, the CLI's Bedrock token-count path (countTokens -> Bedrock branch -> BedrockRuntimeClient.send(new CountTokensCommand(...))) creates the client without a requestTimeout on the request handler and calls send() without an abortSignal. So nothing bounds this request. The gateway/upstream code path that calls the same helper passes { abortSignal: AbortSignal.timeout(1e4) }, but the CLI path does not. Stream watchdogs such as CLAUDE_STREAM_IDLE_TIMEOUT_MS do not cover this side request, and API_TIMEOUT_MS does not apply to it either.

Environment note: the network is behind a corporate TLS-inspecting proxy, which may silently drop idle keep-alive connections. That explains why the request can hang, but a hard timeout would make the client robust regardless.

What Should Happen?

The Bedrock CountTokens request should have a timeout (for example the same 10 s AbortSignal.timeout used on the gateway path) and fall back to the local estimate, so a dead connection cannot block compaction. Ideally it should also honor Esc.

It may also be worth skipping CountTokens for models where Bedrock returns "doesn't support counting tokens", since the call always fails for those.

Error Messages/Logs

Hung compaction (log stops here; nothing further for 20+ minutes):


[DEBUG] autocompact: tokens=[REDACTED] level=compact effectiveWindow=180000
[DEBUG] autocompact: routing through reactive (thresholdSource=model-default)
[DEBUG] [API REQUEST] /model/us.anthropic.claude-opus-5-5/invoke-with-response-stream source=compact
[DEBUG] [API:timing] first byte after 15242ms
[DEBUG] Forked agent [reactive-compact] finished: 1 messages, types=[assistant], totalUsage: input=2068 output=9729 cacheRead=164649 cacheCreate=707
[INFO] compact: kept tail holds 1 thinking block(s); strip=off (decided by flag; model=us.anthropic.claude-opus-5-5, thinking=adaptive)


Healthy compaction in the same session (next lines 0.7-2 s later):


[INFO] compact: kept tail holds 1 thinking block(s); strip=off (...)
[ERROR] Bedrock CountTokens failed: ValidationException: The provided model doesn't support counting tokens.


After Esc, then `/compact` (no engine turn or API request follows):


[DEBUG] [onCancel] source=local streamMode=requesting
[DEBUG] FileHistory: Making snapshot for message ...

Steps to Reproduce

Intermittent. Not deterministic.

1. Use Claude Code with CLAUDE_CODE_USE_BEDROCK=1 (Opus model, us-east-1) on a network that may drop idle HTTPS keep-alive connections.
2. Work in a long session until auto-compact triggers. Leaving the session idle for a while beforehand seems to increase the likelihood.
3. Occasionally, compaction never finishes after the summary is generated. Esc does not recover.

In about two weeks, 11 of 100 compactions stalled by 16 minutes or more, across 7 different projects.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.284 (hang observed). 2.1.285 source inspected, same code path.

Platform

AWS Bedrock

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

_No response_