[BUG] Long-running Bedrock sessions killed by SIGKILL (signal 9) due to no output during extended thinking

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?

When using Claude Code with AWS Bedrock (Opus 4.6) for complex tasks, the process produces no stdout/stderr output for extended periods (10-30+ minutes) while the model is thinking. This causes external process managers (systemd, CI/CD runners, orchestration tools) to interpret the silence as a hung process and send SIGKILL (signal 9).

We've observed this consistently across multiple sessions over several weeks:

1. Session delta-nexus (Feb 9): Large codebase refactoring task. ~15 minutes of silence during Bedrock thinking → killed by process manager
2. Session glow-lob (Feb 10): 50+ turn session, process grew to several GB RSS. No output during final thinking phase → SIGKILL
3. Multiple sessions (Feb 11): Discovered our orchestration tool's default 30-minute exec timeout was the killer. Extended to 2 hours, but the root cause remains — there's no way to distinguish "thinking deeply" from "actually hung"

The issue is specific to Bedrock provider with extended thinking enabled. The API response streaming doesn't begin until thinking completes, so there's a long gap with zero output.

What Should Happen?

During extended thinking periods, Claude Code should emit some form of keepalive or progress indication:

• A periodic heartbeat to stdout (e.g., a spinner, dots, or a "Still thinking..." message every 60s)
• Or at minimum, a machine-readable keepalive to stderr so process managers know the process is alive
• In -p (print/non-interactive) mode, this is especially critical since there's no terminal UI to show a spinner

Error Messages/Logs

# Typical observation from process manager:
Process claude (PID 12345) killed: signal 9 (SIGKILL)
# No preceding error output - just silence then death

# dmesg shows OOM killer in some cases (50+ turn sessions):
oom-kill:constraint=CONSTRAINT_NONE [...] task=claude pid=12345

Steps to Reproduce

1. Configure Claude Code with Bedrock provider (Opus 4.6, us.anthropic.claude-opus-4-6-v1)
2. Run a complex task that requires extended thinking:

``bash
claude -p --max-turns 30 "Refactor this entire module: analyze all files, create a plan, then implement changes across 10+ files"
``

1. Monitor stdout/stderr — observe periods of 10-30 minutes with zero output
2. Any process manager with a timeout shorter than the thinking period will kill the process

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

2.1.39

Platform

AWS Bedrock

Operating System

Amazon Linux 2023 (EC2, x86_64)

Terminal/Shell

bash (non-interactive, invoked from orchestration tool)

Additional Information

Workarounds we've applied:

• Increased process manager timeout from 30 min to 2 hours
• Split large tasks into smaller chunks (< 20 turns each) to avoid long thinking periods
• Avoid -p mode with | head or pipe consumers that close early (causes separate hang issue)

Environment:

• EC2 instance with IAM Role auth (no API keys)
• Bedrock region: us-east-1
• Extended thinking enabled
• Used both interactive (PTY) and non-interactive (-p) modes

Impact: This is a significant usability issue for anyone running Claude Code in automated/orchestrated environments (CI/CD, background agents, systemd services) with Bedrock. The process appears indistinguishable from a hung process during thinking periods.