Repository navigation
retire the trailer's pinned psmux path once psmux releases the psmux#773 fix; the case-folding session key stays #879
Description
psmux fixed psmux/psmux#773, #774 and #775 on master (merges 691e39a2, 51c58756, 62026a80 + 69e355fb). No release carries them yet: git tag --contains is empty for all four. We retested on master 3b1c3ac6. This issue now tracks one retirement and records one decision.
1. Retire: the pinned psmux path in the parked-window trailer (#877, PR #878), behind psmux/psmux#773 (merge 691e39a2).
On master a pane inherits the server's start environment, and the registry only fills names it lacks. Measured 3 of 3 on 3b1c3ac6: the launcher's PATH entry and TEMP reach new-session, new-window and claimed warm-session panes. A bare psmux in the pane resolves to the build that started the server. bmad-loop starts the server by bare name, so that build is on the server's PATH. A server started by absolute path from a shell without that build on PATH still resolves another psmux, the same as tmux would. The pin also covers that case, so keeping it does no harm. Retire it only behind the _LAST_UNSUPPORTED bump to the first release whose tag contains 691e39a2, never on the strength of the closed issue: on 3.3.8 the pane PATH is still rebuilt from the registry.
2. Keep permanently: the case-folding session-name key (PsmuxMultiplexer.session_name_key). No longer a retirement item.
The maintainer refuses case-distinct sessions by design: the registry directory, the server mutex name and compatibility with older clients all fold case. Measured on master: =name targets are now exact (has-session -t =REPRO-CASE beside repro-case exits 1), and a case-only duplicate new-session is refused with duplicate session: X (differs only in case from session x, ...). A name that differs only in case still means the same registry slot, so the fold stays as defence in depth. bmad-loop creates every session name in lower case (bmad-loop-<run id>, bmad-loop-ctl[-<hex>]), so it never asks for a case-only duplicate. Behaviour against a case variant held by someone else, measured with the real backend:
- 3.3.8: psmux folds the target, so
has_sessionsays yes, and the existing-session path runs the ownership check (foreign_session_refusal). - master:
has_sessionsays no, andnew_sessionraisesTmuxError: psmux new-session failed: duplicate session: .... The launch fails loudly.
Either way bmad-loop never adopts the other session silently. kill_session through a case variant is a silent no-op on master, which is within its best-effort contract.
Tripwires (Windows psmux CI live gate, same style as #852):
test_premise_pane_path_is_rebuilt_from_the_registry: a launcher-onlyPATHentry is missing in a new pane on 3.3.8. It turns red on a release carrying 691e39a2, which triggers item 1.test_adopted_case_only_duplicate_session_is_refused: runs in the normal direction and holds on 3.3.8 and master. If it ever goes red, psmux lets case-distinct sessions coexist, and the fold becomes wrong rather than redundant.test_premise_show_environment_ignores_the_name: a namedshow-environmentquery returns the full listing on 3.3.8. It turns red on a release carrying 62026a80 and is the trigger for adoptinginherited_envon psmux (tracked in psmux 3.3.8 -> 3.3.9 adoption: umbrella for the floor bump, workaround retirement, and the follow-on tracks #660).
Tracked from #660.
Activity
[-]retire the trailer's pinned psmux path and the case-folding session key once psmux releases the psmux#773 and #774 fixes[/-][+]retire the trailer's pinned psmux path once psmux releases the psmux#773 fix; the case-folding session key stays[/+]test(psmux): add live-gate tripwires for psmux#773, bmad-code-org#774 …
dracic commentedon Oct 13, 2026
psmux floor raised to 3.4.0 (
_LAST_UNSUPPORTED = (3, 3, 8): 3.3.8 and older read as unavailable)._transportable's dash-leading clause (psmux/psmux#583): retired.set-option -t S @k -ustores-uon 3.4.0 (20aa1d7), on both the session channel and the id-keyed window channel.test_premise_a_dash_leading_option_value_unsets_the_keybecametest_adopted_a_dash_leading_option_value_is_stored. That row goes red against a_runthat turns the write intoset-option -u, which is the 3.3.8 behaviour.Item 1, the trailer's pinned psmux path (#877, PR #878): it stays, by decision. Measured on 3.4.0 from PowerShell with
SHELLunset:PATHentry (a junction onto psmux's directory, with the real directory removed). In the pane, that entry is onPATH, and a barepsmuxresolves through it.PATH. Each pane carries its own launcher's entry.PATHlacks psmux. The pane finds nopsmuxat all.A pane's
PATHcomes from the process that started the server, not from the launcher that opens the window. bmad-loop's control session is long-lived, so it can be served by a server that someone else started, in three ways:PATH;PATHfrom the registry;PATHentry, which stops resolving once the pane's working directory differs.In all three cases the pin holds and a bare name fails silently, because every trailer error goes to
$null. We found no case where the bare name holds and the pin fails, so the pin stays and its comment now says why.The psmux/psmux#773 tripwire became an ordinary-direction row,
test_adopted_a_pane_inherits_the_servers_start_path. It asserts the pane'sPATHand the in-pane resolution, and records the inheritance that a future retirement would rest on. It goes red against a pane that rebuildsPATHfrom the registry (the 3.3.8 behaviour, faked in-pane).Item 2, the case-folding session key, is unchanged and stays permanently.
Live gate on 3.4.0 (#900, from PowerShell): 28 passed. #900 also retires the psmux/psmux#599, psmux/psmux#622 and psmux/psmux#775 premises, so the pin and the floor move together.
Retirement lands in #900. This issue closes with it.