[Bug] Agent view caches terminal width at process start; split-pane repro needs no window resize (sharpens #80123)

Preflight Checklist

• [x] I have searched existing issues (closest is #80123, which this report sharpens - see below)
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code (2.1.229)

What's Wrong?

Agent view caches the terminal width at process start and never re-measures it. After any attach -> detach cycle (Enter into a session, <- back to the list), the list repaints at the cached width instead of the current one, so the render is clipped both horizontally and vertically inside an otherwise correctly-sized pane.

This does not require a window resize. #80123 reports the same stale-width symptom but its repro requires resizing the window mid-session, which led to it being framed as a missed/late ConPTY resize event. The narrower and more deterministic trigger is a geometry change that lands after claude boots - specifically, wt split-pane splitting the pane a running claude agents is already occupying.

Measured on my setup: healthy render is ~100 columns (full window), broken render is ~55 columns, and my launcher splits panes at --size 0.5. The broken width is exactly the pane width claude should have been using; the healthy-looking width is the pre-split full-window width it cached at startup and kept drawing at. The detach path is what stops papering over the stale value.

Confirmed by fixing it from the outside: delaying claude agents until after the split completes (Start-Sleep 6; claude agents in each pane) makes the cached width the correct one, and the bug disappears entirely. That is a launcher workaround, not a fix - it only works because the cached width happens to be right from then on.

What Should Happen?

Agent view should re-measure terminal dimensions on repaint - at minimum when returning from an attached session - rather than reusing a width cached at process start.

Steps to Reproduce

1. Open Windows Terminal, launch claude agents in a full-width pane, and let it render.
2. Split that pane: wt -w <window> split-pane -V --size 0.5 -- pwsh -NoExit -Command "claude agents". The original pane is now ~half as wide.
3. In the original (now-narrower) pane, press Enter on a session to attach.
4. Press <- to detach back to the list.
5. The list repaints clipped - rows cut off horizontally mid-word, the footer hint wrapping at the wrong column, and the list not filling the pane vertically.

The same thing reproduces on the window-resize path described in #80123; the split-pane path above just makes it deterministic and removes the "was the resize event delivered?" ambiguity, since the pane is never resized by the user at all.

Notes / workarounds

• Ctrl+L does not fix it (repaints at the stale width, as #80123 also reports).
• Only a genuine resize event recovers it. Dragging the window edge works, but two cheaper keystrokes do the same job: Ctrl+minus then Ctrl+0 (Windows Terminal adjustFontSize then resetFontSize) forces a real ConPTY resize and restores the exact original geometry. Alt+Shift+Left then Alt+Shift+Right (resizePane, bound by default) also works.
• Starting claude after the layout is final avoids it, which is the evidence that the cached value is captured at process start.

Environment

• Claude Code: 2.1.229 (native installer)
• OS: Windows 11 Pro, build 26200
• Terminal: Windows Terminal 1.24.11911.0
• Shell: PowerShell 7 (pwsh)
• Model: Opus

Is this a regression?

Unclear. #80123 was filed against 2.1.217 and I noticed it becoming routine around 2.1.226, but I do not have a clean last-known-good version to point at.