Two concurrent unattended runs preceded a machine hang (Kernel-Power 41, no bugcheck) — original autorename diagnosis retracted, see correction

Start in adapters/tmux_base.py, where bmad-loop creates windows with an explicit name, and read the per-window option handling noted in adapters/psmux_backend.py. Verify the change with the two-project psmux reproduction and autorename.log; done means bmad-loop-created windows no longer perform automatic whole-machine renaming while unrelated interactive windows remain unaffected.

Description

bmad-loop creates its agent windows with an explicit -n <name> (adapters/tmux_base.py, new-window -t =session: -n name -c cwd), but never turns automatic-rename off on them. On the psmux backend that option defaults to on:

psmux --help
    automatic-rename    Bool Auto-rename from foreground process (default: on)

Its implementation walks the entire machine process table once per second, per pane, running a BFS over it to derive a name bmad-loop has already supplied. The cost is per-pane and machine-wide, so it is additive across projects — one psmux server per user hosts every project's sessions.

Running unattended runs in two projects at the same time put four such scanners on a process table that both runs were themselves churning. The machine hard-hung and needed a power-button reset.

I checked the v0.11.0 sources: automatic-rename is never set there either, so this is not fixed by the current release.

Why this is cross-project. bmad-loop's own isolation is correct and I verified it — sessions are tagged @bmad_project with a resolved-path digest, and prunable_sessions skips foreign tags. Nothing under .bmad-loop/ is shared. The coupling is entirely through the machine-global multiplexer server, which is invisible to per-project reasoning: project A cannot see that project B just added two more whole-machine scanners to the same server.

Steps to reproduce

1. Two projects on one Windows machine, both bmad-loop init'd with the claude adapter, psmux backend (win32 default), no ~/.psmux.conf so option defaults apply.
2. Start a long unattended run in project A (bmad-loop sweep), leave it working.
3. Start a long unattended run in project B (bmad-loop run) while A is still live.
4. Let both drive dev sessions for ~1.5 h.
5. Watch ~/.psmux/autorename.log and the machine's process count.

Observed timeline from my two projects:

time	event
14:18:07	project A starts a sweep run
14:27:26	A's bundle dev-1 session starts
15:21:14	project B starts a story run — both runs now live
15:21:20	B's dev-1 session starts; this is B's journal's last entry
15:58–15:59	autorename.log records snapshot_entries=754..785 per scan
16:02:07	A starts dev-2 after a failed verify
16:43:30	A's dev-2 pane log stops mid-frame
16:43:42	B's dev-1 pane log stops mid-frame — 12 s apart
17:00:11	Kernel-Power id 41, BugcheckCode=0, no minidump

Expected behavior

Windows that bmad-loop creates with an explicit -n <name> should not pay a recurring whole-machine process-table scan to compute a name that was already supplied, and concurrent runs in unrelated projects should not compound each other's load through the shared multiplexer server.

Actual behavior

Both panes stopped mid-spinner while the agents were actively working (Percolating…, still thinking with high effort). No error, no crash, no adapter fault in either journal. BugcheckCode=0 with no dump and no WER-SystemErrorReporting entry means this was a hang, not a bugcheck — the system stopped scheduling and I held the power button ~17 minutes later.

Measurements from that afternoon:

• Four distinct roots (panes) appear in autorename.log: 12032, 34668, 53064, 61828.
• They are concurrent, not serialized — e.g. 15:00:26.193 root=34668 and 15:00:26.227 root=53064, 34 ms apart.
• Cadence is 1 Hz per root: 14:58:46.160, :47.161, :48.164, :49.177, :50.187.
• snapshot_entries ranged 605–840. The same machine idles at 467 (Get-CimInstance Win32_Process), so the table each scanner walked was inflated 1.3–1.8× by the two runs themselves.
• A full process-table snapshot costs ~168 ms here via CIM. The native CreateToolhelp32Snapshot path is cheaper, but it is the same O(all processes) walk, it takes a system-wide lock, and it contends with the process creation the agent sessions do continuously.

That is the feedback loop: more concurrent runs → more panes → more whole-machine scanners → each walking a table the other runs are inflating and churning.

Suggested fix

Set automatic-rename off on the windows bmad-loop creates. It looks free and strictly correct here:

• bmad-loop already passes -n <name>, so the derived name is pure waste.
• adapters/psmux_backend.py already notes that automatic-rename is the one builtin window option with true per-window storage, so it can be set per window without touching the user's globals or other applications' windows.
• It also removes a live conflict: psmux #266 and #169 are automatic-rename overriding an explicit -n NAME, which is exactly what bmad-loop asks for.

Scoping it per window rather than per session or globally keeps it limited to bmad-loop's own panes and leaves interactive windows alone.

Which area is this for?

multiplexer / adapters

bmad-loop Version

0.10.0 (installed as uv tool install 'bmad-loop[tui] @ git+https://github.com/bmad-code-org/bmad-loop.git@v0.10.0'); v0.11.0 sources checked and unchanged in this respect

Which coding CLI are you using?

claude (dev and review, both projects)

Operating System

Windows 11 Pro 26200, 31 GB RAM, psmux 3.3.7 (win32 platform default backend), no ~/.psmux.conf

Relevant log output

~/.psmux/autorename.log, one scan per pane per second:

[14:58:58.956] root=53064 snapshot_entries=660
[14:58:58.956] root=53064 no_direct_children
[14:58:58.957] pid=53064 fg_child=None (BFS found nothing)
[14:58:59.957] root=53064 snapshot_entries=656
...
[15:59:11.229] root=61828 snapshot_entries=785
[15:59:11.229]   direct_child: pid=31788 name=bmad-loop.exe
[15:59:11.229] root=61828 immediate_child=31788 name=bmad-loop.exe
[15:59:11.230] pid=61828 fg_child=31788 name=Some("bmad-loop")

Windows event, ~17 min after both panes went silent:

Microsoft-Windows-Kernel-Power  id 41  Critical  2026-08-19 17:00:11
BugcheckCode=0, no minidump, no WER-SystemErrorReporting entry

Related

• psmux #459 — unbounded psmux.exe growth with multiple heavy TUI panes; closed not-reproducible, but the reporter's field case ("~400 processes, system extremely unresponsive, had to force-kill to recover") was never explained.
• psmux #266 / #169 — automatic-rename overriding explicit -n NAME.

Happy to test a patch — I can reproduce the two-project load on demand.