[Windows] Window stuck at the smallest client's size after a client disconnects; window-size/aggressive-resize are no-op options and no hook fires on abnormal disconnect

[paceaitian]

Summary

When multiple clients are attached to a session at different sizes, the window is sized to the smallest client (expected). But after a client disconnects, the window never resizes back to the remaining client(s), and there is no way to fix it from config:

1. window-size (latest/largest/manual) and aggressive-resize have no effect. They are parsed, validated and stored, but nothing in the resize logic reads them — they are EFFECT_NONE stub options. So you cannot configure the window to follow the largest/latest client.
2. No hook fires on an abnormal disconnect. On a clean detach (detach-client / prefix+d) the client-detached hook fires, so a resize-window -A hook can recover. But on an abnormal disconnect (network drop, app/terminal killed), the dead client is pruned lazily with no event emitted and no resize, so a hook-based auto-resize can't cover the common case.
3. The hooks you would reach for are dead. client-resized, client-active, client-focus-in, client-focus-out are defined but never emitted.

Net effect on Windows: attach a small client (e.g. a phone over SSH), the desktop window shrinks to the phone's size; the phone drops abnormally; the desktop window is stuck small and even resizing the desktop terminal doesn't grow it. The only recovery is a manual resize-window -A.

Environment

• rmux 0.7.1, Windows 11 (10.0.26200), Windows Terminal + ConPTY, PowerShell 7.

Evidence (source, v0.7.1)

(1) window-size / aggressive-resize are no-op stubs:

• OptionName::WindowSize appears only at its own definition/declaration (option table crates/rmux-core/src/options/table.rs around the window-size entry, and crates/rmux-proto/src/types/options.rs) — no resize/geometry code reads it. (handler_window.rs's local window_size sort variable in resize-window -A is unrelated.)
• Both window-size and aggressive-resize are marked EFFECT_NONE in the option table → changing them triggers no recompute.
• aggressive-resize likewise appears only in definition/type/parse, with zero references in resize logic.
• Live: set -g window-size latest → exit 0; show -g window-size → window-size latest; set -g window-size bogus → unknown value: bogus. Fully parsed/validated, yet zero effect.

(2) No event on abnormal disconnect:

• client-detached is emitted only on the explicit detach-client path (crates/rmux-server/src/handler_client/detach.rs).
• Abnormal disconnects are pruned lazily in crates/rmux-server/src/handler_attach/refresh.rs (stale PIDs removed when an enqueue/write to the client fails) — no LifecycleEvent emitted, no window recompute.
• client-resized / client-active / client-focus-in / client-focus-out: only the enum definitions match a repo-wide search — zero emit sites (dead hooks). (Event→hook mapping: crates/rmux-core/src/lifecycle.rs.)

Repro

1. Attach two clients to one session at different sizes (e.g. a 175-col desktop + a 69-col phone over SSH). The window shrinks to 69 (expected).
2. set -g window-size largest (or latest) — no effect; window stays 69.
3. Kill the small client abnormally (drop its network / close the app). No client-detached fires; window stays 69.
4. Resize the desktop terminal — the window is still stuck at 69.
5. resize-window -A manually → the window finally grows to 175.

Ask (any one of these would fix it)

• Make window-size (at least largest / latest) actually drive window geometry; or
• Emit a lifecycle event and recompute the window size when a client is pruned on abnormal disconnect; or
• Implement the dead hooks (client-resized etc.) so a config-level auto-resize is possible.

Any one removes the need for an external polling watcher, which is currently the only reliable workaround on Windows (poll list-clients; when a session is down to one client whose width ≠ the window width, run resize-window -A).

Note

Works in tmux: window-size latest / aggressive-resize drive geometry, so the window follows the active client and recovers after a disconnect. Happy to provide more detail or test patches.

[shideneyu]

Thanks for the report — this has been addressed in RMUX 0.8.0.

RMUX now implements the missing multi-client resize behavior:

• window-size and aggressive-resize are no longer inert;
• stale/disconnected clients are pruned from resize decisions;
• detach/resize behavior was aligned with tmux-style multi-client sessions;
• hooks and tests were added around client resize/detach behavior.

Closing as fixed in 0.8.0. Feel free to reopen with a multi-client repro if a window still stays stuck at a disconnected client’s size.