[BUG] Status line stream.speed null-deref masks real generation stalls on pre-first-token streams

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?

The status line renderer accesses stream.speed without a null check. When a stream is open but has delivered zero tokens (pre-first-token phase), stream.speed is undefined and the access throws:

Cannot read properties of undefined (reading 'speed')

This is the same root TypeError as #40189 (Bedrock) and #40737 (direct API), but I'm filing separately because the user-facing impact is distinct and not covered in those issues:

The error masks real generation stalls. During extended thinking on large-context requests (100k+ tokens), the time-to-first-token can be 20-60 seconds. During this window, the status line crashes instead of showing "thinking..." or a spinner. The user sees an error that looks like a client crash, when the actual problem is just slow generation. This makes it impossible to distinguish between:

1. A genuinely stalled/hung stream (should ESC and retry)
2. A slow-but-progressing extended thinking phase (should wait)

Steps to Reproduce

1. Accumulate a large context window (100k+ tokens) - e.g., read several large source files in a session
2. Request a complex task that triggers extended thinking (e.g., "write a detailed implementation plan for X")
3. If using a corporate proxy or non-Anthropic backend (Bedrock, Azure via proxy), the TTFT is longer, making this more reliably reproducible
4. Observe the status line during the pre-first-token phase - it shows the stream.speed TypeError instead of a thinking indicator

The error fires on every render cycle during the pre-first-token window, not just once.

Root Cause

The stream object is created when the SSE connection opens, but the .speed property is only populated after the first content token arrives. The status line render function accesses stream.speed unconditionally. The fix is likely a single optional chaining change (stream?.speed or a guard).

Impact Beyond the Error Message

• Stall diagnosis is broken: Users cannot tell if a long pause is normal extended thinking or a hung stream, because both show the same error
• ESC-retry loop: Users preemptively kill streams that were actually progressing, wasting tokens and time
• Corporate proxy users hit this more: Azure/Bedrock backends have higher TTFT due to network hops, making the pre-first-token window longer and this error more frequent
• The 10 April incident: A session appeared to stall for ~1 hour on a large Write task. The stream.speed error was the only visible signal, making it look like a crash. The actual cause was a combination of extended thinking + uncached context replay + large output buffering. The error masked the real problem and delayed diagnosis by ~45 minutes

Related Issues

• #40189 - Same TypeError, Bedrock-specific, focuses on the error itself
• #40737 - Same TypeError on direct Anthropic API
• #45002 - Duplicate of above, about to be auto-closed

Claude Model

claude-opus-4-6 (via corporate proxy to Azure)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_Unknown - the status line speed display was added recently_

Claude Code Version

2.1.92

Platform

Third-party API (corporate proxy)

Operating System

macOS

Terminal/Shell

iTerm2

Additional Information

The pre-first-token window is especially long when:

• Extended thinking is enabled (thinking phase runs before any content tokens)
• Context is large (100k+) and prompt caching is unavailable (e.g., Azure backend strips cache_control)
• The request is for a large single output (e.g., a 500+ line file write)

A defensive fix (optional chaining on speed access) would restore the thinking indicator during this window, letting users distinguish slow-but-alive streams from genuinely hung ones.