[Bug] Daemon spawns workers with a hardcoded 120x30 PTY when the client size is not yet known, then never resizes them (Windows)

Environment

• Claude Code 2.1.274 (BUILD_TIME 2026-09-16T21:39:42Z, GIT_SHA 1efcc1361e649ab98800b43a7df307043397a9ba)
• Windows 11 Pro 10.0.26200, Windows Terminal, ConPTY
• Backend: daemon (claude daemon run --origin transient), workers spawned by the supervisor

Summary

Workers that the daemon spawns before it knows the client's terminal size are created
with a hardcoded 120x30 PTY. Nothing corrects that size afterwards, so the TUI
paints a 120x30 image into the real (larger) window: content occupies only the
top-left, the rest of the window stays blank.

Symptoms

• Open a terminal window that is larger than 120x30 (e.g. 210x59), start claude,

and enter a session within the first seconds after the daemon starts.

• The session renders at 120x30 inside the 210x59 window — the input box separator

stops at ~57% width, the footer sits at ~51% height, bottom and right are black.

• Restarting the session does not help — every newly spawned worker is born at

120x30 again.

• Maximizing the window (or any real window-size change) fixes it.
• Closing the terminal and reopening it fixes it, even without resizing.

Evidence

~/.claude/daemon/roster.json records the size that each worker is created with,
and dispatch.createdAt records when that decision was made. Three workers from the
same supervisor process (2.1.274), same machine, same session:

| worker | dispatch.createdAt | dispatch.cols x rows | daemon knew the client size? |
|---|---|---|---|
| bad901d6 (spare) | 20:06:38.874 | 120 x 30 | no — daemon had not finished starting |
| 138b5e43 (fleet) | 20:06:46.091 | 120 x 30 | no — attach gesture started 9 ms earlier |
| ec131221 (fleet) | 20:22:25.009 | 210 x 59 | yes — daemon had been up 16 minutes |

The size is passed straight through to the pseudo-console host, whose command line
carries it literally:

--bg-pty-host \\.\pipe\cc-daemon-<id>-pty-bad901d6  120 30  -- claude.exe --session-id bad901d6-...
--bg-pty-host \\.\pipe\cc-daemon-<id>-pty-138b5e43  120 30  -- claude.exe --resume ...
--bg-pty-host \\.\pipe\cc-daemon-<id>-pty-ec131221  210 59  -- claude.exe --resume ...

Geometry check against a screenshot of the broken window: the window is 210 columns
wide, the rendered content stops at 54.3% of its width (120 / 210 = 57.1%), and the
footer row sits at 48% of its height (30 / 59 = 50.8%). That is consistent with a
120x30 buffer being painted into a 210x59 window.

Analysis

Two things combine:

1. The size is fixed at dispatch creation and never revisited. If the daemon does

not yet have the client's real size at that moment, it uses a 120x30 fallback, and
that value is baked into the worker's PTY for its whole lifetime.

1. Nothing re-sends the size after the attach completes. The client only emits a

resize op when its own size changes. Immediately after attaching, its size has
not changed, so no resize op is sent and the worker is never told the real size.
There is also no SIGWINCH fallback on Windows — signalPtyPgrp() returns early when
the platform is win32.

This is why a window resize fixes the problem but a restart does not: the resize
produces a genuine size change, which is the only thing that triggers the correction.

I am reasonably confident about (1) because the timestamps above line up with the
daemon's startup window. I have not pinned down exactly where the daemon learns the
client size, or why it does not have it by the time the first attach arrives — that
part is inference from the data above, not from reading the code.

Steps to reproduce (tentative)

1. Close all Claude Code windows so the transient daemon exits.
2. Open a terminal window larger than 120x30.
3. Start claude and enter a session immediately, before the daemon has been up long.
4. Observe the session laid out at 120x30 with the bottom/right of the window blank.
5. Wait a minute, then create or enter another session — that one comes out at the

correct size.

Step 5 is the part I am least sure reproduces consistently; steps 1-4 reproduce every
time on this machine.

Expected behavior

A worker's PTY should be created at the client's current terminal size, or resized as
soon as the client reports its size during attach — so the first entry is laid out
correctly and no workaround is needed.

Workaround

Change the terminal size once (maximize, or maximize and restore). That produces a real
size change, which resizes the PTY and reflows the TUI.