[BUG] CLI hangs indefinitely on stuck streaming response — UI swallows input but redraws on SIGWINCH; only external kill recovers

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/37080
2. https://github.com/anthropics/claude-code/issues/25979
3. https://github.com/anthropics/claude-code/issues/33949

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Follow-up datapoint: I just confirmed that sending kill -INT <pid> from another terminal causes the wedged process to exit immediately and cleanly — no -TERM or -9 needed. The SIGINT handler is wired up and working.

This narrows down suggested fix #2: it's not about adding a SIGINT handler (already there), it's about making sure the in-TUI Ctrl+C reaches the same abort path. Today the keystroke is delivered as stdin byte 0x03 (raw mode, isig disabled) and gets stuck in the same wedged input pipeline as every other key. Routing Ctrl+C through a synchronous path that calls the existing SIGINT abort handler — instead of going through the awaiting state machine — should fully resolve the "unable to interrupt" half of the bug.

(The other half — "no inactivity timeout, so the stall happens at all" — still needs suggested fix #1.)

Root Cause

Event loop starvation during streaming:

1. Streaming read operation blocks the main event loop
2. Keyboard input handling is on a channel that's never read (reactor stuck in streaming read)
3. SIGWINCH works because signal handlers bypass the event loop
4. Only external kill can recover

Proposed Fix

1. Add streaming timeout

const STREAMING_TIMEOUT_MS = 300_000; // 5 minutes

async function* streamResponse(request: ApiRequest): AsyncIterable<Chunk> {
    const controller = new AbortController();
    const timeoutId = setTimeout(() => controller.abort(
        new Error('Streaming response timed out after 5 minutes')
    ), STREAMING_TIMEOUT_MS);
    try {
        const response = await fetch(request.url, { ...request.init, signal: controller.signal });
        for await (const chunk of response.body) yield chunk;
    } finally { clearTimeout(timeoutId); }
}

2. Never drop input during streaming

handleInput(key: string): void {
    if (this.isStreaming) {
        this.inputQueue.push(key);  // Queue instead of drop
        if (key === 'Ctrl+C') this.abortStreaming();
        return;
    }
    this.processInput(key);
}

Files to Modify

1. src/api/streaming.ts — Timeout + abort mechanism
2. src/cli/input.ts — Queue input during streaming
3. src/cli/tui.ts — Streaming state indicator

Full solution: solutions/claude-code-59913-streaming-hang-fix.md

Thanks for the duplicate-flag — I went through all three.

#37080 is already closed (consolidated into #33949 by the author, not fixed by maintainers).

#33949 and #25979 are open and they do cover suggested fix #1 (stream inactivity timeout). I'm happy to defer that half of this issue to #33949, which has the deeper repo-archaeology and a larger user signal.

What I believe is not covered by any of those:

1. In-TUI Ctrl+C / Esc completely swallowed. #33949 explicitly notes "ESC partially works around this by aborting the dead connection" — so over there ESC at least reaches the abort path. On 2.1.132 / macOS in this ces any effect at all** until theprocess is killed externally. That points to an input-routing failure separate from the streaming-timeout issue.

1. SIGWINCH-still-redraws dat"event loop starved by streamingread" hypothesis (re: @jshaofa-ui's comment above). The sample(1) trace I posted shows the main thread parked on kevent64 not blocked inside a stream read.SIGWINCH triggers a clean Ink re-render via the same event loop — so the loop isn't starved; only the input state machine is wmise.

1. **External SIGINT exits cleanl a SIGINT abort handler alreadyexists and works. The fix for the "can't interrupt" half is therefore not "add a SIGINT

handler" but "make the in-TUI Ctrisig off, so 0x03 arrives as a stdin byte and gets stuck in the same wedged input pipeline as every other key.

So I'd suggest keeping this issue open as the input-pipeline-wedge / Ctrl+C-can't-cancel angle, and treating the underlying SSE . Happy to split if maintainersprefer — let me know.

Update — I retract part of the previous follow-up. Tested in detail and the picture is more nuanced.

What's still true

claude-code's SIGINT exit path does not perform terminal teardown. Verified directly: after kill -INT <pid> cleanly exits the process, the hosting terminal is left with:

• termios in claude's raw-mode state (-icanon -echo) — the kernel side, no tcsetattr was called
• the alt screen buffer still active (the cursor visibly jumps when I send CSI ? 1049 l from outside)
• presumably other in-band modes still set (kitty keyboard / modifyOtherKeys / mouse tracking / bracketed paste)

So the signal-exit handler should restore the saved pre-launch termios and emit the matching disable sequences (CSI < u, CSI > 4 ; 0 m, CSI ? 1003 / 1002 / 1000 l, CSI ? 2004 l, CSI ? 1049 l). Same handler should apply to SIGINT, SIGTERM, and SIGHUP. This is just standard TUI hygiene and is independently worth fixing.

What's not true (correcting my previous comment)

I previously claimed that adding TUI teardown would resolve the "wedged window after external kill" symptom. It will not. I tested by injecting the full disable sequence — plus DECSTR, plus RIS — directly into the wedged pty's slave from outside. Ghostty visibly processed every sequence (alt screen exit, screen clear), but the window's keyboard input forwarding stayed dead. The corruption lives at a Ghostty per-surface level that's below in-band reset, and that's a separate bug (filed/added on the Ghostty side: ghostty-org/ghostty#12629).

So:

• Fix #1 (stream inactivity timeout) — still the most important. Without it the hang happens at all, external kill -INT remains the only escape hatch, and we hit the Ghostty surface bug every time.
• Fix #2 / signal-exit teardown — still worth doing on principle, but won't on its own recover the host window. Frame it as "be a good citizen TUI," not as "this fixes the post-kill window state."

Diagnostic detail (in case useful)

After external kill -INT: zsh foreground, tpgid == zsh.pgid, display direction works (writing to /dev/ttysN renders), but zsh's stdin read offset never advances on user keypresses — bytes don't reach the pty slave. Ghostty itself is idle (~2% CPU, no hot thread on sample), other tabs in the same process work fine.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.