psmux: pipe_pane targets a bare @N window id — per-server ambiguity binds the sink to the wrong server's pane (empty run logs)

[dracic]

Summary

On the psmux backend, per-task pane logs stay empty even though the sink process spawns and the pipe delivers bytes — because pipe_pane targets the bare @N window id returned by new_window, and psmux window ids are per-server (one server per session). When the engine runs inside a bmad-loop-ctl pane (the normal TUI-launched case), its pipe-pane -t @N resolves against the control session's server, not the agent session's server — so the sink gets attached to whatever window happens to hold id @N there (typically the engine's own window), and the agent pane is never piped at all.

This is the same per-server bare-id ambiguity already root-caused for switch-client in #221 (psmux/psmux#483: "a bare pane or window id with no session prefix is only resolved within the current session"). The pipe-pane call path was missed.

Environment

• psmux 3.3.7 (stock crates release 05cc5d4, includes the #440 pipe-pane tee rewrite)
• bmad-loop 0.9.0, Windows 11, engine launched from the TUI (runs inside a bmad-loop-ctl window)

Evidence (live run forensics)

• Sink (<log>.sink.ps1, positional invocation from psmux pipe_pane sink captures nothing on 3.3.7: -EncodedCommand transport is stripped upstream, and the CopyTo sink can't flush incrementally #217) spawned at T+2s and held the log open for 16 minutes, capturing 0 bytes, while the agent CLI in the real dev pane repainted continuously (capture-pane showed the full TUI throughout).
• The only bytes ever captured — 16 bytes, ESC[?9001l ESC[?1004l — arrived at the exact moment the engine's own control-session pane was torn down (its ConPTY reset emission), after which the sink hit EOF and exited. That is only possible if the pipe was bound to the engine's own window, not the dev window.
• Both servers in a normal run have colliding ids (e.g. @1 exists on the ctl server and on the agent-session server), so the misbind is silent: pipe-pane exits 0.
• Bonus failure mode, reproduced from inside a pane: pipe-pane -t @1 -o 'pwsh "<sink>"' can also fail outright with psmux: no server running on session '-o' (the bare-id target derails argument parsing and -o is taken as a session name). The adapter's best-effort except turns that into a stderr warning that is lost with the parked pane, so the run log is just silently empty either way.
• Raw-mode gating was ruled out as the cause: on the same binary, piped panes capture fine during ?9001h (win32-input-mode), ?1049h (alt screen), and 57 KB output bursts.

Root cause

GenericCliAdapter.start_session passes new_window's return value (#{window_id}, a bare @N) straight to mux.pipe_pane. On tmux that id is server-global and unambiguous; on psmux it is only meaningful on the server that minted it, and the CLI resolves it against the caller's current-session server (or worse, see the -o parse derail above).

Proposed fix

Session-qualify the pipe-pane target in the psmux backend, mirroring the #221 resolution for the parked-trailer return target: pipe by session:window (verified working on 3.3.7) or =session:@N, composed by the backend that knows its own target grammar. Options:

1. PsmuxBackend.pipe_pane composes the qualified target itself (it already knows the session via the adapter's target() seam) — smallest diff, tmux path untouched.
2. new_window on psmux returns a session-qualified id so every downstream -t consumer is safe — broader, worth considering since any other bare-id consumer has the same latent bug (an audit of @N/%N uses on the psmux path is cheap while at it).

Impact

• Per-task run logs are empty on psmux for TUI-launched runs (engine inside the ctl session), which also blanks the TUI Log tab and starves the pane-log activity signal used by stall detection.
• Completion detection (Stop hook / result artifacts) is unaffected.

Related: #185 (3.3.7 live smoke), #217 (positional sink — still valid, the sink itself is fine), #221 (session-qualified switch-client target), psmux/psmux#483 (bare-id model boundary), psmux/psmux#482

[coderabbitai]

🔗 Related PRs

#137 - feat(mux): herdr TUI-launch surface [merged]
#175 - fix(adapters,engine): timely + observable session-timeout teardown [merged]
#181 - feat(adapters): add native-Windows psmux multiplexer backend [merged]
#218 - fix(adapters): pipe psmux pane logs through a positional sidecar sink [merged]
#225 - fix(tui): record session-qualified parked-window return target [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[dracic]

Scope update after tracing every consumer of the stored window id: this is not just the log pipe — it is the "engine lost" bug itself. Severity should be treated as critical, and the fix should cover the whole id contract, not only pipe_pane.

The id collision is exact, not hypothetical

In the run analyzed above, the agent session's windows were @1 (shell) and @2 (dev window), so SessionHandle.native_id = "@2". The control session's windows were @1 (shell) and @2 — the engine's own parked window (both servers mint ids from 1, and both sessions are created seconds apart with one extra window each, so the collision is essentially guaranteed for every TUI-launched run).

Every native_id consumer misroutes, not just pipe_pane

GenericCliAdapter reuses the bare id for all of these, and from inside the ctl pane each one resolves on the ctl server:

• pipe_pane(native_id, …) — sink binds to the engine's own window (the original report).
• send_text(native_id, …) — stop/stall nudges are typed into the engine's own pane, not the agent's. The agent never sees them.
• kill(handle) — the lethal one:
  1. window_pane_pids(native_id) harvests the pane-root pids of the engine's own window (its own wrapper + python tree) and stamps identities on them;
  2. kill_window(native_id) kills the engine's own window — the engine dies mid-kill(), silently (crashed: false, journal/state frozen, window gone, no traceback);
  3. had it survived step 2, the grace-escalation would force_kill the harvested pids — its own.
• Asymmetry that hides the bug: _window_alive uses list_window_ids(self.session_name) — session-qualified, so monitoring reads the correct server while the destructive verbs hit the wrong one. The engine "sees" a healthy dev window right up to the moment it decapitates itself.

This closes the "engine lost" mystery

Timeline from the same run: engine healthy for 16 min (heartbeat 10:04:43.85), 4th result-less Stop arrives 10:04:49.70 → stop-nudge budget exhausted → engine tears the session down → kill() → kill_window("@2") resolves on the ctl server → engine's own pane tree dies at 10:04:50.22. The 16-byte "death rattle" the sink captured (ESC[?9001l ESC[?1004l) is the ConPTY reset of the engine's own pane during that kill — captured because the sink was bound to that same wrong window. One bare-id bug, two observed symptoms.

It also retroactively explains the original showstopper report ("session finishes → engine dies before consuming the result → resume relaunches it → repeat"): normal end-of-session teardown calls kill() right when the session completes, so the engine reliably self-killed at exactly that moment — before advancing state. The earlier attribution to psmux's recycled-PID force-kill (psmux/psmux#404-class) was wrong; the installed 3.3.7 already contains that fix.

Fix recommendation

Prefer option 2 from the report — have the psmux backend return a session-qualified id from new_window (e.g. =<session>:@N / <session>:@N, whichever grammar every verb accepts on 3.3.7) so pipe_pane, send_text, kill_window, and window_pane_pids are all safe without touching the generic adapter or the tmux path. Option 1 (qualify only inside pipe_pane) would fix the log and leave the engine self-kill in place.

Repro note for the destructive path: any TUI-launched run on psmux whose per-task session reaches teardown (normal completion, timeout, or stop-nudge exhaustion) kills the engine instead of the agent window; runs launched from a plain shell (engine outside any psmux pane) resolve bare ids differently and may mask the bug.