#537 gave psmux a per-project registry root derived from (project, state root). It deliberately does not honour an ambient PSMUX_DATA_DIR — it overrides it and says so — because honouring it turned out to be ambiguous rather than merely tricky. This issue is that ambiguity, written down so it can be designed instead of guessed at.
The two horns. Two operators can produce byte-identical environments and need opposite answers:
- Transient pin. They typed
$env:PSMUX_DATA_DIR = R in one shell. A pane child that keeps R strands its session from every clean process on the machine, since a clean process has no pin and derives.
- Persistent pin. Their profile exports R into every shell. A pane child that drops R strands its session from every clean process, since a clean process does have the pin and honours it.
Measured on the #537 branch (both rows in one run, same code):
outer (S1, pinned) : R
pane child (moved to S2) : derived D2
clean S2 WITH the profile pin : R <- persistent horn
clean S2 with NO pin (transient) : derived D2 <- transient horn
The missing fact is whether the pin is persistent, and it is not in the process's environment. Four inherited-token designs were tried on #537 (bool($TMUX), a project-keyed token, project+root, derived+adopted); each closed one horn and opened the other, which is what motivated cutting the feature rather than shipping a fifth.
The mechanism that does close both, for whoever picks this up: move the fact out of the environment and into a stated preference — a [mux] policy boolean, read identically by the outer process and the pane child because it lives in a per-project file rather than in a shell. It must stay a whether and never a where: policy.toml is written by the sessions the orchestrator drives, so a policy-sourced root would let a driven session aim the cleanup path's kills at a registry of its choosing (the #498/#571 config-digest class of hole). A boolean cannot.
What exists today to build on: runs.export_psmux_registry_root is the one place the root is settled; cli._configure_mux is the one place it is reported; bmad-loop mux prints the derived root with a paste-ready export so an operator can point their own shell at it, which is the current answer to "one registry for both".
Related: #537 (the derived root), docs/multiplexer-backends.md (operator-facing statement of the current behaviour).
#537 gave psmux a per-project registry root derived from (project, state root). It deliberately does not honour an ambient
PSMUX_DATA_DIR— it overrides it and says so — because honouring it turned out to be ambiguous rather than merely tricky. This issue is that ambiguity, written down so it can be designed instead of guessed at.The two horns. Two operators can produce byte-identical environments and need opposite answers:
$env:PSMUX_DATA_DIR = Rin one shell. A pane child that keeps R strands its session from every clean process on the machine, since a clean process has no pin and derives.Measured on the #537 branch (both rows in one run, same code):
The missing fact is whether the pin is persistent, and it is not in the process's environment. Four inherited-token designs were tried on #537 (
bool($TMUX), a project-keyed token, project+root, derived+adopted); each closed one horn and opened the other, which is what motivated cutting the feature rather than shipping a fifth.The mechanism that does close both, for whoever picks this up: move the fact out of the environment and into a stated preference — a
[mux]policy boolean, read identically by the outer process and the pane child because it lives in a per-project file rather than in a shell. It must stay a whether and never a where:policy.tomlis written by the sessions the orchestrator drives, so a policy-sourced root would let a driven session aim the cleanup path's kills at a registry of its choosing (the#498/#571config-digest class of hole). A boolean cannot.What exists today to build on:
runs.export_psmux_registry_rootis the one place the root is settled;cli._configure_muxis the one place it is reported;bmad-loop muxprints the derived root with a paste-ready export so an operator can point their own shell at it, which is the current answer to "one registry for both".Related: #537 (the derived root),
docs/multiplexer-backends.md(operator-facing statement of the current behaviour).