Claude Code CLI reports "Truncated event message received" on Bedrock Opus 4.8 streams that are byte-complete

Summary

When anthropics/claude-code-action runs a review against us.anthropic.claude-opus-4-8 on AWS Bedrock (through our self-hosted API Gateway + Lambda SSE proxy), the bundled Claude Code CLI fails turn 1 with:

"subtype": "success", "is_error": true, "num_turns": 1,
"result": "API Error: Truncated event message received.", "stop_reason": "stop_sequence"

The job still exits "success", so the PR review comment is only the stub "I'll analyze this and get back to you." This is deterministic for opus-4-8 and does not happen for us.anthropic.claude-sonnet-4-6 (Sonnet reviews complete normally).

Environment

• anthropics/claude-code-action@v1 (via an internal reusable wrapper), no claude_code_version override. @v1 is a floating tag, so we track near-latest: @anthropic-ai/claude-agent-sdk ^0.3.202, Claude Code CLI ~2.1.197 observed on runners (latest 2.1.202). This is not a stale-version problem — see "Already on current, no fix in any release" below.
• Provider: AWS Bedrock, region us-west-2, use_bedrock: true.
• Between the CLI and Bedrock is our proxy: API Gateway REST with responseTransferMode=STREAM, a Lambda that forwards Bedrock's InvokeModelWithResponseStream chunks as SSE (text/event-stream).
• Model: us.anthropic.claude-opus-4-8. Config includes adaptive thinking (thinking.type=adaptive + output_config.effort) — opus-4-8 rejects thinking.type=enabled with a ValidationException, so it uses the newer schema.

The stream is NOT actually truncated on the wire

We captured the exact same prd endpoint / model / key with curl from the same allowlisted CI runner, across 9 request shapes:
plain prompt · adaptive-thinking · adaptive-thinking + tools (tool_use turn) · + betas (interleaved-thinking-2025-05-14, fine-grained-tool-streaming-2025-05-14) · + Accept-Encoding: gzip over HTTP/2.

Every capture is byte-perfect:

• Correct event sequence: message_start → N×content_block_delta → content_block_stop → message_delta → message_stop.
• Final bytes end with a clean SSE terminator ...}}\n\n (0x0a 0x0a).
• amazon-bedrock-invocationMetrics arrives inline in the message_stop data (identical framing to Sonnet).
• Response is not compressed (no Content-Encoding), HTTP/2, curl_exit=0.

Proxy-side logs for the failing SDK turns show request_completed HTTP 200 with full token usage (e.g. 699–706 output tokens) — no early close, no error. So the proxy delivered a complete, well-formed stream; the CLI nonetheless reported it as a truncated event.

This is not a Bedrock/AWS service defect — it's a client-side decode failure

The exact string "Truncated event message received" originates in the AWS binary event-stream (application/vnd.amazon.eventstream) deserializer that the CLI's Bedrock path uses — i.e. the client's own decoder rejecting what it was handed, not Bedrock reporting an error. Bedrock returns HTTP 200 with full usage; our proxy logs a clean completion. The same error string is produced when that decoder meets malformed/mis-framed event-stream bytes (see the analogous proxy case aws-samples/sample-OpenClaw-on-AWS-with-Bedrock#48). We are running with use_bedrock: true, so the CLI decodes this route via that AWS event-stream reader — which is where the failure surfaces, on opus-4-8 but not on Sonnet.

Already on current, no fix in any release

Because claude-code-action@v1 floats, we are already on near-latest (CLI ~2.1.197, agent-sdk ^0.3.202). We checked the CLI changelog through 2.1.202: opus-4-8 launched in 2.1.154; the only opus-4-8-specific fix — "thinking blocks were modified, leading to API errors" — shipped in 2.1.156 and is long included. No changelog entry through 2.1.202 addresses "Truncated event message received" for opus-4-8 streaming. So this does not appear resolved in any released version; bumping the pin does not help.

Related open issues (same model / same proxy-gateway topology)

• anthropics/claude-code#66095 — opus-4-8 slow-first-byte / idle-timeout stream aborts (open, many reports through 2.1.191).
• anthropics/claude-code#69759 — streaming aborts specific to a custom ANTHROPIC_BASE_URL proxy/gateway (open).

These are a different failure mode (timeout/abort, not decode) but the same model and gateway shape; this report may belong triaged alongside them.

Why this matters downstream

The CLI treats the (well-formed) opus-4-8 stream as a mid-stream failure → falls back to the non-streaming route (CLAUDE_CODE_DISABLE_NONSTREAMING_FALLBACK default path). On our gateway the buffered route is bounded, so the fallback 503s and the CLI retry-loops → reviews stub out or hit the CI job timeout. (Raising the buffered bound is the wrong fix; the trigger is this streaming failure.)

Questions / ask

1. On the Bedrock route, does opus-4-8's stream (adaptive thinking, output_config, new usage fields like output_tokens_details, service_tier, context_management) emit something the CLI's AWS event-stream decoder rejects that Sonnet does not? That decoder is where "Truncated event message received" comes from.
2. Is this known/tracked, and in which release would it be fixed? We are already on current (CLI ~2.1.197 / agent-sdk ^0.3.202) and find no changelog entry addressing it through 2.1.202, so bumping the pin does not appear to help.
3. We could not reproduce with curl (event stream consumed cleanly under 9 request shapes), so it appears specific to the CLI's decoder, not the bytes on the wire. Guidance on capturing the CLI's own decode-failure detail (which event/offset it deems truncated) would help — ANTHROPIC_LOG=debug goes to the CLI's stderr and is swallowed by the action's stdout capture.

Interim mitigation

Point reviews at us.anthropic.claude-sonnet-4-6 (streams cleanly end-to-end).