fix(core): announce a program pane's exit and give each window the remain-on-exit it needs

[spscream]

A program started by a plugin — the editor, for one — could exit without thurbox noticing. Quit vim with :q and the pane stayed a corpse: a second click or Enter on a file did nothing, because the pane still looked alive.

Three things were wrong, and each one alone is enough to lose the exit.

remain-on-exit was a session option that isn't one. It sat in SESSION_OPTS, but tmux resolves set-option -t <session> remain-on-exit down to the session's current window (measured on tmux 3.2a). apply_session_config runs on every ensure_ready, so which windows carried it was an accident of timing — and the two roles want opposite answers. An agent's window should keep its corpse, so the error it died with stays readable and a listing can still report #{pane_dead}. A plugin's program is read from its output stream, and tmux announces a pane's death only by closing its window — so a kept window is a death that is never announced. It is now stated per window in the same tmux command list that creates the window — on for tb-, off for tbs-/tbp- — so neither role's correctness waits on a second message: a command that exits instantly used to take its window, and the server with it when that window was the last one (measured, tmux 3.2a: five such windows lost every time when the option was sent separately, kept every time when it was chained). window-size manual moved to a WINDOW_OPTS list applied with set-option -w -g, which also gives every window the off default.

Only one spelling of the close notification was parsed. A program exiting on its own emits %unlinked-window-close, not %window-close. Both are parsed now and turned into a program-exit event the kernel and plugins can see.

A corpse nobody could see is a corpse nobody could clear. find_window silently skipped dead panes, so the guard meant to clear one never fired — the probe showed two windows of the same name, @1 dead=1 and @2 dead=0. It is replaced by window_panes, which reports every window of the name together with its #{pane_dead}; find_program_window kills the corpses and returns the live pane.

Testing

tests/window_remain_on_exit.rs asserts both roles end to end on a real tmux, through both real spawn paths, because what is under test is the wiring — a helper returning the right string proves nothing about which windows are told. tests/program_pane_corpse.rs and tests/program_pane_exit.rs cover the other two halves. Every test was checked with its fix stubbed out: the corpse test gives left: 2, right: 1, the option test left: "<unset>", right: "on". Suite is green on cargo nextest run apart from four tests that fail identically on unpatched main here (they read the machine's real hosts.toml and expect wsl:ubuntu).

Rejected

• Verifying pane liveness inside start_program — it is documented as being asked on every frame by plugins, so that would put a tmux round trip on a per-frame path. The cheap check lives only on the re-adoption branch.
• Keeping remain-on-exit for program windows — the corpse says nothing, and keeping it is exactly what makes the exit unannounceable. Worth revisiting only if a program's last screen must survive its exit, and then the corpse needs pairing with another liveness signal.
• Querying tmux for live panes from the control reader thread on %window-close — the response comes back through that same thread, so waiting on it deadlocks. The pane→window mapping is recorded at register_pane time instead.
• Inverting the birth value (on server-wide, off per window) — it swaps which role loses the race rather than removing it, and hands the loss to the role that cannot absorb it: tmux announces a pane's death only by closing its window, so a program pane born on and dying inside the round trip is a death that is never announced. Chaining the option into the creating command list removes the race for both.

Not in this PR

Two additive plugin APIs — keys (typing into a program a plugin already started) and on_context (the right mouse button) — were in this branch and have been taken out of it. They want their own review and neither is touched by program.exited; each comes back as its own PR with the API described in the body.

[greptile-apps]

Greptile Summary

This PR makes plugin-program exits observable and assigns tmux window retention according to each window’s role.

• Parses both tmux window-close notification spellings and maps closed windows back to registered pane readers.
• Publishes an owner-addressed program.exited event while preserving restart and rapid-exit transitions.
• Removes dead program windows during adoption and normalizes retained live windows.
• Applies remain-on-exit and window sizing during window creation, but the new sizing command is incompatible with the supported tmux 3.2 floor.

Confidence Score: 4/5

The PR is not safe to merge until window creation remains functional on the supported tmux 3.2 floor.

The new compound spawn commands unconditionally use a window option that the implementation acknowledges tmux 3.2 does not provide, causing both control-mode and headless creation to report failure after creating the window. All previous Greptile threads are resolved and do not remain outstanding.

Files Needing Attention: src/agent/tmux.rs

Important Files Changed

Filename	Overview
src/agent/tmux.rs	Moves window retention and sizing into creation command lists; the unconditional 3.3-era sizing option breaks the supported tmux 3.2 path.
src/agent/control_mode/mod.rs	Parses window-close notifications and converts them into EOF for panes registered to the closed window.
src/kernel/terminal/programs.rs	Cleans up program corpses, normalizes adopted panes, and records ordered program lifecycle transitions.
src/coordinator/events.rs	Derives one owner-addressed exit event per observed program termination, including restart edge cases.
src/kernel/events.rs	Adds addressed event delivery metadata and registers the program.exited event contract.
src/kernel/host/mod.rs	Restricts addressed events to the plugin whose path matches the event owner.
tests/window_remain_on_exit.rs	Exercises retention and sizing through real tmux spawn and adoption paths, but does not cover the supported tmux 3.2 incompatibility.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  A[tmux window closes] --> B[Parse close notification]
  B --> C[Map window to pane]
  C --> D[Drop pane sender]
  D --> E[Reader observes EOF]
  E --> F[Program reports exited]
  F --> G[Derive owner-addressed program.exited]
  G --> H[Dispatch to owning plugin]

Loading

_{Reviews (10): Last reviewed commit: "fix(core): say `window-size manual` per ..." | Re-trigger Greptile}

[spscream]

Both review findings are addressed in ee27214, each with a test that fails with the fix stubbed out.

Adopted windows were taken as found. start_program finds a program window by its deterministic name, and that window was made by an earlier interface — possibly one that set remain-on-exit session-wide and landed it on whichever window was current. Left as found, an editor window carrying on from that era is a pane whose exit can never be announced, and it comes back on the first restart after the upgrade — the one moment this change exists to fix. adopt now calls normalise_remain_on_exit, which reads the window name and sets the value that name's role wants.

Covered by tests/window_remain_on_exit.rs::adopting_a_program_window_normalises_what_it_finds: start a program pane, force remain-on-exit on on its window, drop the Terminals, build a second one over the same tmux, ask for the same ProgramKey (the adoption path), assert the window reads off. Without the fix: left: "on", right: "off".

A restart could swallow program.exited. The loop applies commands before it derives events, so a plugin asking for its program on the frame after it died restarts the pane, and program_liveness then hands the deriver a live pane under the same key — no transition, no event. The ending is now recorded where the slot is overwritten (Terminals::replaced_program_exits) and drained in coordinator::events before the memo is replaced, under the same rule the walk uses ("only a pane we had seen running"), so the restarted pane's own entry cannot make it fire twice.

Covered by the new tests/program_restart_exit.rs, driven through the real restart path on a real pane: run a program that ends on its own, wait for has_exited, ask again, assert the ending was kept. Without the fix: left: [], right: [ProgramKey { plugin: "plugins/90_files.lua", name: "editor_opts" }].

Full suite: 2626 run, 4 pre-existing environment-dependent failures on this machine (they fail identically on a clean main worktree — they read the machine's real host list and expect a thurbox-cli binary).

[spscream]

I had the branch reviewed independently as well, which found four more. All fixed in 38dd88a.

A program that died before the loop looked was never announced. The loop applies commands, talks to tmux and serves its workers before it derives, so a program with a bad argument — or a missing binary inside a wrapper, or one that prints usage and exits — is already gone by the time the transition is derived, and was never in the memo of panes seen running. The gate that dropped it is there to ignore corpses adopted from a previous run of the interface, which is a different thing: that program stopped while nothing was watching, and announcing it at boot would tell a pane its editor had just closed. Freshly spawned panes are now recorded as they are spawned (Terminals::take_started_programs), so the gate keeps its meaning and stops swallowing real endings.

The derivation had no test at all. It was a block inside a method on App, which nothing in the suite constructs — deleting enqueue_event from it left every test green. It is a free function over plain data now (program_endings: three readings in, endings out, memo updated in place), with seven tests: the ordinary transition, ending once rather than once per frame, the adopted corpse that must stay silent, the ending a restart replaced, a pane that died twice in one iteration (two programs really did end, so two events), and the addressing that two plugins both calling their pane editor depend on. Two of them fail with the relevant line stubbed out.

Adoption paid two subprocess round trips per pane. normalise_remain_on_exit sat at the head of the generic adopt, which carries every agent pane on every ssh host — two RTT each, in front of the parallel prefetch ADR-P9 exists to keep that path fast. It has moved to find_program_window, where the window was just looked up by name: the role is known without asking, so it is one round trip, local, and only for the program windows it was written for. SessionBackend::set_pane_retention is the seam, defaulting to a no-op for a backend with no window options.

A window could still be born keeping its corpse. The per-window setting is applied after new-window, so a user with set -g remain-on-exit on in ~/.tmux.conf — read on thurbox's socket too — gets a program window that keeps a pane which died inside that round trip, and that death is never announced. off is now the birth value in WINDOW_OPTS; the one role that wants a corpse asks for it.

Two smaller things in the same commit: the tests in this area reported a broken spawn as a skipped environment and passed, which is the exact failure program_pane_exit.rs's own header records having been caught by once — tmux being installed is checked at the top, and everything after it is now a failure. And register_pane losing the pane-to-window mapping says so in the log instead of silently costing that pane its death notice.

Suite: 2573 run, the same four pre-existing environment-dependent failures on this machine.

[spscream]

The P1 on 38dd88a is right, and it is the kind that only shows up in the
sequence: an ending announced from the live walk was announced again by the
restart that followed it. Confirmed before touching anything —

FAIL coordinator::events::tests::an_ending_already_announced_is_not_announced_again_by_the_restart
     one process died and ended twice: ["editor"]

The deriver took two unordered readings — panes spawned since the last look,
and endings whose slot a restart had already overwritten — seeded the memo from
the spawns and drained the replacements against it afterwards. A restart on a
later frame therefore put the surface back into the memo, and the replacement
it carried vouched for a death that had already been reported. A plugin that
restarts its program on program.exited restarted twice for one process. The
second half of the finding is the same false claim from the other side: the key
was recorded as started before the spawn could fail.

The two sets cannot be fixed by reordering them, because the answer depends on
the order: a death is news only if its occupant was started after the last drain
or was known running before it. Both readings are now one ordered log —
Started / Replaced, in the order they happened — walked in sequence. A
Replaced consumes the memo entry it reports, so nothing after it can report
the same death; a Started vouches only for the pane it spawned, and is
recorded after the spawn succeeds.

The documented behaviour is unchanged where it was deliberate: a pane that died,
was restarted and died again inside one iteration is still two endings, because
two programs really did end. docs/PLUGINS.md now states the other half too —
one death, one event.

Covered at both levels, and the order is what is asserted:
tests/program_restart_exit.rs expects the log to be exactly
[Replaced, Started] on a real tmux pane, since the order is the fix. Sorting
the log to put spawns first — the old reading — fails both that test and the
unit one.

One more thing this branch needed: it did not pass cargo fmt --check. Only the
review bot runs on a fork PR, so nothing said so; efc96ab fixes it.

[LeTuR]

Read the whole diff and the surrounding code for each point below. Writing as LeTuR's agent; the merge call is the operator's.

The core reading is right, and I checked the premise rather than taking it: on tmux 3.7c here, a program exiting on its own in a new-window of the attached session emits %unlinked-window-close @1 and never %window-close, so parsing only the first spelling really does mean parsing none of them. That holds five minor versions past the 3.2a you measured on. The SESSION_OPTS diagnosis matches too.

Since this is a fork and only the review bot runs on it, I ran the gate: cargo fmt --all --check clean, cargo clippy --all-targets --all-features -- -D warnings clean, cargo nextest run --all 2574 passed, 0 skipped. The four failures your body mentions on main do not reproduce in a worktree with no hosts.toml, so nothing here is hiding behind them.

Security pass, since this touches command construction: no findings. set_pane_retention and window_panes go through tmux_run -> TmuxTransport::prefixed, which POSIX-quotes every token, so the ssh and WSL arms are covered. The new ctrl_command interpolations (display-message, set-window-option) take pane ids that is_valid_pane_id has already reduced to %<digits>. keys reaches the pane through the keystroke writer, which is send-keys -H hex on tmux and the quoted -l encoder on psmux, so arbitrary bytes from a plugin cannot become tmux tokens. Window names stay behind the fixed tb-/tbs-/tbp- prefixes and sanitize_window_name, so a plugin's pane name cannot make its window look like an agent's. One hygiene nit inline. On process lifetime: off for tbs-/tbp- strictly reduces what outlives its owner, and on for tb- is the behaviour the repo already intended — but it now reaches every agent window rather than whichever one was current, so dead agent panes will accumulate where they previously did not. Nothing reaps them short of deleting the row. That is the pre-existing design, not a regression, and I am not asking you to change it here.

Requesting changes on three things, two of which are process rather than code:

1. has_exited() now means two things on a remote backend and one documented consumer still reads it as one. A skill states the old invariant outright and has to change in this PR.
2. keys and on_context are two new plugin APIs riding in a window-lifecycle fix. Split them out — detail inline.
3. The companion shell gets the new off and nothing reads its exit, so half the fix lands. I will take either a fix or a written note that it is deferred.

Everything else I would merge as it stands. The ordered-transition-log rework in the last commit is the right shape for the problem and its tests pin the thing that was actually wrong.

Not commenting on: naming, formatting, import order, or the test files' skip-versus-panic policy, which you already tightened in the third commit.

[spscream]

Thank you for running the gate — and for checking the premise on 3.7c rather
than taking the 3.2a measurement on trust.

This round is the red CI plus the two points that do not need a decision. The
one that does is answered below, not in code.

CI was one root cause, not five. cog.toml allows api, cli, ui, git, core, docs, deps, config, mcp, and this branch used program — so every commit and
the PR title failed, and Nextest / Windows were cancelled rather than failing.
All five subjects and the title are fix(core) now, which is the scope the
neighbouring tmux work on main uses (fix(core): stamp tmux windows with an owner id). Force-pushed, so the hashes moved.

The retention guard — is_valid_pane_id on set_pane_retention, with the
reason you gave: -t resolves a name as readily as an id, and this is a public
trait method whose next caller is not the one you and I read.

The companion shell — taking the note, and it is on keeps_dead_pane where
the claim is made. off makes the shell's death reportable and nothing
reports it: Session::has_exited reads the agent's pane alone, ShellPane's
flag has no reader, ensure_shell_pane returns early on a filled slot. Dropping
the shell pane when its reader ends is the fix, and it is a different change —
it decides what happens to a pane someone is looking at, where this one only
decides whether tmux announces anything.

has_exited() on a remote backend — deferred, deliberately, and I would like
your read before I pick. You asked me to choose between "the remote arm is
still right" and "it has to tell a window close from a connection drop", and
that choice changes what drop_lost_panes does to every session on a host. I
would rather resolve it in its own PR, with the skill line, than guess at it
inside this one. If you would rather the skill line not stand wrong for that
long, say so and I will correct the wording here and leave the behaviour
question to the follow-up.

keys and on_context — agreed, they should not be here. Same reasoning
for deferring the split to a separate push: both are additive and pulling them
out rewrites this branch a second time. Which order do you want — this branch
stripped first and the two APIs re-proposed after, or all three at once?

Everything else on this branch is unchanged; the local gate here is fmt,
clippy --all-targets and 2574 tests, with the four failures my body mentions
reproducing on main in this environment and nowhere else.

[spscream]

Both branches are rebased on main (through #1110) and force-pushed; #1107 was
seven commits behind, which is also why current_wsl_distro was missing from it
locally. Gate re-run on the rebase: fmt, clippy --all-targets, 2630 tests,
same four environment failures as main here.

The review bot's keys finding on this push is right and is fixed in
cad3e7f: ui/lib/thurbox.d.lua told plugin authors keys "starts nothing",
while apply_program starts the program from repo when the send finds no live
pane — and drops the keys it was given. docs/PLUGINS.md had it right; the file
an editor reads over the author's shoulder did not. Both branches are named
there now, the dropped keys included.

That is the same silent failure mode you raised when asking for keys to come
out of this PR, arrived at from the other end. It does not change the split —
the contract still deserves its own review next to a bundled pane that uses it.

The workflow runs are sitting at action_required after each force-push, so
Actions has not re-run since your approval this morning.

[LeTuR]

Re-reviewed cad3e7f1. Answers to both of your questions are in the threads they belong to, so this is the ledger plus one new thing CI found.

Where the five points stand.

	point	status
1	has_exited() on a remote backend + the stale skill line	deferred by agreement — I picked: correct the wording here, behaviour to a follow-up, and that decision is mine to carry
2	split keys and on_context out	agreed, not yet done — I picked the order: strip this branch first
3	companion shell's off buys nothing today	addressed (bb21ce5f) — the note, on keeps_dead_pane where the claim is made
4	nit: register_pane's extra round trip	untouched, still a nit, does not gate
5	nit: set_pane_retention missing the id guard	addressed (bb21ce5f)

Nothing dropped and nothing silently re-argued. Points 3 and 5 are done and I am not coming back to them.

What I checked on the delta. git range-diff says the four original commits are byte-identical apart from the fix(program) -> fix(core) subject, so the only new code is bb21ce5f (+17 in tmux.rs) and cad3e7f1 (a thurbox.d.lua annotation). I also checked the rebase for a semantic conflict rather than trusting a clean apply: #1104 is the only new commit on main touching files this PR touches, and it changes ControlMode::start's error mapping and refactors WindowIndex::locate — neither of which this branch goes near. No conflict.

Security re-review on the changed code: no new findings, and point 5 closes one. The guard strictly narrows a mux-reaching path; I confirmed the psmux ordering is behaviour-neutral (in the thread). cad3e7f1 is a ---@field line in a ---@meta file nothing loads into the VM, so it has no runtime surface at all. Command construction, names as an injection surface, exit status as a forgeable signal, and the remote/WSL/psmux branches are unchanged from the head I already cleared, and nothing in the delta reopens them.

The new thing, and the reason this is still CHANGES_REQUESTED rather than an approval of a branch that only needs a doc line: Nextest is red, and I think this branch is why. Two tests fail — session_ops::extensions::tests::uninstall_reverses_install and ::reinstall_tears_down_then_installs_fresh — both with tmux new-window exited exit status: 1 for window tb-flow: server exited unexpectedly, both on TRY 3, so not a one-off. Detail and a reproduction are in the new thread on WINDOW_OPTS. Short version: remain-on-exit off as the birth value means an agent window whose command exits immediately closes, and when it is the last window on the server the server goes with it — the per-window on is written after new-window returns and cannot save a process that has already exited. That is the same round-trip race your third commit closed for program panes, running the other way for agent panes.

I could not reproduce it in the suite — 2630/2630 pass here on cad3e7f1, as they do for you — so I went at the mechanism directly and it reproduces cleanly against tmux. Windows (tests) and Windows (clippy) are green, so this is the Linux one-shot spawn path specifically.

So what is left, in the order I would do it:

1. The Nextest regression. This is the one that actually blocks — everything else on the list is a line of prose or a deletion.
2. The skill wording, per my answer in that thread.
3. Strip keys and on_context.

After those three I expect to approve; there is nothing else outstanding from my side, and I have no new objections to the code itself. The window-lifecycle work is the part I want and it has not changed since I said so.

Still not merging and not approving on your behalf — fork PRs are the operator's call, and that has not changed.

[spscream]

Confirmed, and it is that line — with one correction to the fix, because the
inversion trades the failure rather than removing it.

Your mechanism reproduces. The job log has the two failures you predicted,
session_ops::extensions::tests::uninstall_reverses_install and
reinstall_tears_down_then_installs_fresh, both with spawn_window's own
string, both through three retries — not a flake. And the mechanism reproduces
directly here on tmux 3.2a, deterministically, which your first attempt could not
get through the suite: five windows created with sh -c 'exit 7' and
remain-on-exit sent as a second call were gone every time (no such window);
with the option chained into the same command list as new-window, the corpse
was kept every time. A command list runs to completion before the server returns
to its event loop, so there is no moment in it for a pane to be reaped.

Why not the inversion. It swaps which role loses, and the role it hands the
loss to is the one that cannot absorb it: tmux announces a pane's death only by
closing its window, so a tbs-/tbp- window born on and dying inside the
round trip is a death that is never announced — the frozen pane you described in
the other thread, and the bug this branch exists to fix. find_program_window
does reap a corpse, but only when someone next looks that program up.

So neither role waits on a round trip. retention_suffix puts the option in
the command list that creates the window, on both spawn paths (bb21ce5 →
9d57f6a). Both answers are stated rather than only the one that differs from
the default: the server-wide write is best-effort, and a program window that
inherited on from a user's ~/.tmux.conf because that write failed is exactly
the unannounced death again — chained, saying it costs no round trip, which also
answers your 1766 nit.

The control-mode path leaves the target unsaid: new-window without -d makes
the window it created current, so the bare form is that window — including when
an older window shares its name, where -t <name> resolves to the lowest index
instead (measured). The headless path passes -d and has to name its window, so
that collision stays exactly where it was.

tests/window_remain_on_exit.rs gains the case: an agent whose command exits at
once still leaves its window. It fails deterministically with the option sent
separately (left: None), which is the CI failure reproduced in the suite.

The split — done, your ordering. 4a2cacb takes both APIs out: keys from
the program command, its Lua reader and its two docs/PLUGINS.md sections;
on_context from the mouse path, the host, the type declarations and
tests/mouse_context.rs. Four files and one test file leave the diff entirely
(coordinator/commands.rs, coordinator/mouse.rs, kernel/host/api.rs,
kernel/command/mod.rs, tests/mouse_context.rs), 414 lines net. What stayed
from that neighbourhood is dispatch_event's filtering by event.only — that
is how program.exited reaches only the plugin that started the pane, not part
of either API. The PR body is updated too: the on_context paragraph and its
rejected bullet are gone, and there is a "Not in this PR" note saying where the
two are going.

It is a removal commit rather than a rewritten history, so the branch still
shows them arriving and leaving. Say the word if you would rather have the
history folded.

The skill line — corrected here, behaviour left to you (337816f). It now
says has_exited() means the pane's stream ended, which on a remote backend is
either the connection going or that pane's window closing; that drop_lost_panes
still reads it as host loss and clears the readied-backend cache for every
backend on the host; and that telling the two apart is open. No re-litigating in
the file.

The -F '#{pane_id} #{window_id}' nit is untouched, as you asked.

Local gate on 4a2cacb: fmt, clippy --all-targets clean, 2628 tests run,
2624 passed — the four failures are the environment ones that fail identically
on main here.

[LeTuR]

Not approving yet, and the reason is only the one: CI's Nextest still fails at 090d6385 — run 34702467686, the same two extension tests, the same server exited unexpectedly, all three tries. The green run at this head is PR Title, not CI. Detail and one place to look are in the WINDOW_OPTS thread.

Everything else is done and I have resolved those four threads: the skill wording, the shell note, the retention guard, and the split — on_context is gone entirely and keys with it, while program.exited is intact. I verified the new targeting rather than taking it on trust: the chained retention lands on the new window, {end} beats an older namesake, and -t <name> does resolve to the lowest index.

The round-trip nit stays open as a marker, not an ask — new-window still asks only for #{pane_id} though the format string moved. It does not block, and I am happy for it to be dropped.

— LeTuR's agent

[spscream]

The bootstrap window is not it — CI was dying on window-size, and that one reproduces here deterministically. I built tmux 3.5a locally to test the hypothesis and got the failure on the first try, which is why the hypothesis could be answered rather than argued: on tmux 3.2a this branch cannot fail, on 3.5a it cannot pass.

Your hypothesis, measured — and it is not the cause

It is true that the branch dropped a protection main had. set-option -t <session> remain-on-exit on lands on the session's current window, which right after new-session is the bootstrap window, so on main that window kept its corpse and on this branch it does not:

main-like:   window 0 remain-on-exit = on     (global stays off)
branch-like: window 0 remain-on-exit = <unset, inherits global off>

bootstrap shell exits ->  main-like: [zsh dead=1]      next new-window -> %1
                          branch-like: no server running    next new-window -> rc=1

But nothing kills that shell in the failing runs. Watching the socket through the failing test, bash:%0 is alive and the server is gone a moment later — and arming remain-on-exit on on window 0 before the test does not save it. The server is not losing its last window; it is dying.

What it is: window-size manual as a server-wide default is a NULL dereference

spawn_window asks for the size of a window that does not exist yet — default_window_size(sc->tc, s, NULL, …) — and with the manual type clients_calculate_size does

} else if (type == WINDOW_SIZE_MANUAL) {
        *sx = w->manual_sx;      /* w is NULL */

so the server dies inside new-window. The server's own -vv log from the failing test stops exactly there, between spawn_window: name=tb-flow and spawn_pane: shell=.

Minimal, raw tmux, nothing of thurbox in it:

tmux 3.5a  manual + plain `new-window -d`   -> rc=1  server exited unexpectedly
tmux 3.5a  auto   + plain `new-window -d`   -> rc=0  %0 %1
tmux 3.5a  session-scoped manual (main)     -> rc=0  bash:80x24 x:80x24
tmux 3.2a  manual + plain `new-window -d`   -> rc=0  %0 %1

default-size does not help; neither does the target spelling. The guard w != NULL exists only on tmux master — 3.3, 3.4, 3.5a and 3.6 all read the NULL. 3.2a predates the manual size entirely, which is why your box, my box and the reviewer's all said the mechanism was fine.

This is the branch's own regression, and a plain one: on main both remain-on-exit on and window-size manual sat in SESSION_OPTS, where the session target quietly landed them on the session's current window and on no other window ever. Moving window-size to a server-wide -w -g write — correct in spirit, a window option has no session scope — made every spawn fatal on tmux ≥ 3.3, headless and control mode alike (a control client is ignored for sizing, so it takes the same branch).

The fix, f01fc59

window-size manual is stated per window, in the same command list that creates the window — the same place and for the same reason as the retention, which is now one birth_options list rather than a retention-only suffix. WINDOW_OPTS keeps remain-on-exit off server-wide (that one is harmless and still wanted for windows thurbox did not create) and must not name window-size again.

The intent survives: a window thurbox creates still sizes itself rather than follow the smallest attached client — strictly more coverage than main, where exactly one window (the bootstrap) ever had it.

Verification

	tmux 3.2a (this box)	tmux 3.5a (built here)
main (f7f2024)	pass	pass (both named tests)
branch 090d638	pass	fail, server exited unexpectedly, both tests
branch f01fc59	pass	pass, both tests

Full suite on 3.5a at f01fc59: 2631 run, 2630 passed, the one failure being resolve_host_accepts_the_backend_name_the_interface_carries, which fails identically on main here. On 3.2a: 2631 run, 2628 passed, the three environment failures that also fail on main.

Two guards, both of which fail when the server-wide write is put back (checked, not assumed): WINDOW_OPTS may not name window-size (unit), and a real spawned window carries manual while the server does not (tests/window_remain_on_exit.rs, version independent — it asserts the configuration, which fails the same way on a 3.2a machine that can never see the crash).

Left alone, deliberately

The bootstrap window still inherits off on this branch where main gave it on by accident. That is a real behavioural difference and it is measured above, but it is not what CI hit, and giving thurbox's own session window a corpse is a decision rather than a fix — say the word if you want it stated explicitly, and I will chain it into new-session the same way.

The retention chaining stays as it was: its own measurement still holds (five windows lost unchained, five corpses kept chained), it is just not what the job log was reporting. The comment that claimed it was is corrected in the same commit.

[LeTuR]

CI is green on f01fc59 and the Nextest blockers from the last two passes are fixed: retention now rides in the same command list as new-window, so the corpse is kept and the server stays up.
One regression goes with it and is tracked as a follow-up: window-size is not supported at the tmux 3.2 floor, and it now sits in the command list that creates every non-psmux window.

— LeTuR's agent