[FEATURE] Re-run statusLine command on terminal resize (SIGWINCH)

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

The statusLine command re-runs only on: new assistant message, /compact completion, permission-mode change, vim-mode toggle, and the optional refreshInterval timer (per the "When it updates" section of the statusline docs). Terminal resize is not a trigger.

Since v2.1.153 Claude Code sets COLUMNS/LINES before running the script, which encourages width-adaptive status lines (progress bars, flex layouts, responsive tiers). But when the terminal or pane is resized, the previous render — sized for the old width — stays on screen until the next trigger fires. In an idle session with the default configuration (no refreshInterval), a resized status line stays truncated or wrapped indefinitely; with refreshInterval set, it stays stale for up to the full interval.

The only mitigation today is refreshInterval: 1, which trades a rare event (resize) for constant polling: one subprocess spawn per second per open session, multiplied across tmux/multi-pane fleets — while still leaving up to 1s of visibly broken layout.

Proposed Solution

Treat a terminal dimension change as a status line update trigger: on SIGWINCH (or the equivalent dimension-change detection already used to set COLUMNS/LINES), re-run the statusLine command with the updated values. The existing 300ms debounce and in-flight cancellation semantics can apply unchanged, so rapid drag-resizes batch into one execution.

With this, event-driven configurations (no refreshInterval) stay crisp on resize, and polling configurations can drop back to long intervals.

Alternative Solutions

• refreshInterval: 1 — works, but worst-case 1s of stale layout plus a ~40ms node spawn every second per open session (measured with a Node-based status line), i.e. continuous CPU churn to catch an event that happens a few times an hour.
• Detecting the size from inside the script is impossible by design: output is captured, so tput cols/ioctl report nothing (documented), and the script only runs when Claude Code invokes it.

Priority

Medium - Would be very helpful

Feature Category

Interactive mode (TUI)

Use Case Example

1. Run Claude Code in a tmux/Ghostty split with a width-adaptive status line that sizes meters from COLUMNS.
2. Resize the pane (e.g. zoom a split from 220 to 90 columns).
3. Today: the status line keeps its 220-column render — clipped or wrapped mid-meter — until the next assistant message or timer tick (10-30s in practice).
4. With a resize trigger: one debounced re-run, correct layout within ~350ms, no polling needed.

Additional Context

• Docs "When it updates" lists only new-assistant-message, /compact, permission-mode, vim-mode, and timer triggers; COLUMNS/LINES support (min-version 2.1.153) explicitly directs scripts to be width-aware — resize is the natural missing trigger for that contract.
• Observed on Claude Code 2.1.207, macOS (Ghostty + tmux panes).
• A resize-triggered run costs the same as any other trigger (~40ms for a typical Node renderer) and is strictly cheaper than the refreshInterval: 1 workaround it replaces.