Agent fleet on Windows: session attached at FleetView startup or after a worker spawn renders at a stale ConPTY size until a real window resize

Version: 2.1.251 (npm and native installs), Windows 11 Pro 26200 ARM64, Windows Terminal 1.24.11911, tui: "fullscreen", also reproduced with CLAUDE_CODE_ALT_SCREEN_FULL_REPAINT=1.

Symptom

In claude agents (two Windows Terminal panes side by side, one FleetView each), a pane renders its worker's transcript for a size that does not match the pane: lines cut on the left edge, tails of longer lines left over on the right, the prompt separator repeated up to 8 times, no status bar, content stopping ~8 rows above the pane bottom. The neighbouring pane, same window, same height, is perfect. It happens (a) when a session is resumed by the daemon while a pane shows it, and (b) after restarting Windows Terminal (new FleetView processes re-attach the sessions). It never happens on a session that the FleetView itself spawned in that pane and that received at least one resize since.

Evidence that it is a stale ConPTY size, not a renderer bug

• Resizing the window by -40 px height and back (two SetWindowPos calls 800 ms apart, no focus change) fixes the pane completely within 4 s: full height, status bar back, correct wrapping (screenshots before/after attached). Only a real terminal resize repairs it; a Windows Terminal restart does not.
• Full-repaint mode (CLAUDE_CODE_ALT_SCREEN_FULL_REPAINT=1) changes nothing: the worker repaints everything, for the wrong geometry.
• The pty-host command lines show the sizes the workers were spawned with (--bg-pty-host <pipe> 138 70 for the broken one, 113 61 for a healthy one), which are FleetView viewport sizes, not the pane size.

Reading of the bundled daemon code (2.1.251)

• case "attach" registers the attacher {cols, rows, caps, ...} and calls r.resizeForRepaint(d.cols, d.rows), so the pty is resized to whatever the FleetView declares at attach time.
• Afterwards the only path that resizes the pty is the resize op, which the client sends from its resize handler (Ht, 50 ms debounce) on the terminal stream's resize event. Nothing is sent when the FleetView's own layout changes the viewport without the terminal changing size.
• On Windows, resize() on a job that is not workerReady sets resizeDeferred and returns; the deferred size is replayed in the rendezvous ready callback. If the size declared at attach or at spawn is wrong, it is therefore replayed faithfully wrong, and nothing corrects it until the terminal itself resizes.

So the failing step appears to be the cols/rows the FleetView declares when it attaches at startup (and passes when it spawns a worker), rather than the resize plumbing itself.

Expected

After attach and after worker readiness, the worker should render at the pane's actual size, without needing an external window resize.

Screenshots (left pane only, the broken one)

Before the resize, 12:52 (the worker was resumed at 10:41:58, Windows Terminal restarted at 12:45):

!before

Four seconds after a -40 px / +40 px height resize of the window, nothing else changed:

!after

Workaround in use

A resident script that performs a -40/+40 px height resize of the Windows Terminal window a few seconds after any new claude.exe --bg-pty-host or claude.exe agents process appears.