[devswha]

Problem

The attach handler added the client to the attachment and to client.data.attached only after await ensureAttachment(...). A frame from the same socket that arrived during that await found nothing to clean up. Bun doesn't serialize an async message handler per socket.

• Disconnect mid-attach: close walked an empty attached set, so the closed socket was added to attachment.clients afterwards. It was never removed, and the pty outlived every live client.
• Detach mid-attach: PaneTerminal sends detach(old) and then attach(new) on every pane switch, so this is the more common trigger. The detach was a no-op, and the client was added to the old pane anyway. It kept receiving that pane's bytes, and the pty stayed alive, until the socket closed.

Fix

• The pane goes into client.data.attached before the await. detach and close both clear it, and the attach checks it when it resumes. If the attach fails, the entry is removed again.
• A cancelled attach calls releaseUnclaimed. It closes the attachment only if it's still the current one, has no clients, and no other client has the pane in attached.
• That last check matters because of the pending-creation sharing from fix(server): share one pty when clients attach the same pane concurrently #2: a live client may be waiting on the same creation and not have resumed yet. Closing eagerly would leave it with a dead record and a blank terminal.

Follow-up commit: stale claims after a pty exits

With the intent scan in place, an entry left behind in attached counts as a live claim. When a pty exits while its herdr pane survives (e.g. herdr restarts), closeAttachment deleted the record but left the pane in each member's attached. Those members are on the "terminal ended" screen. Their stale entries then blocked releaseUnclaimed from closing a later cancelled attach on that pane, so the pty kept running with zero clients. It did recover on the member's next pane switch or disconnect. closeAttachment now removes the pane from its members' attached.

No contract test pins this: when a cancelled creation has no other joiner, a client can't observe when it has finished. An ad-hoc probe checked it instead. It kills the attach under a watching client, then attaches and detaches the pane in one tick, and waits 3s. With the change 0 attach processes remain; without it, 2 remain.

Tests

• WebSocket client leaving mid-attach has one test for each trigger, and each runs on its own workspace. The oracle is the leaked resource itself: once the last live client is gone, no herdr terminal attach <terminal_id> process may remain (pgrep -f, bounded wait). Each test first asserts that the process count is above 0, so the pgrep pattern can't pass vacuously.
• The observer-first test moved into its own describe with its own pane. It no longer relies on the previous roles test having released the shared qaPaneId. The test body is unchanged.

Check	Result
Mutation: server/index.ts fix reverted	both new tests fail 3/3 (attach … still running 5000ms after its last client left)
Mutation: only the intent scan in releaseUnclaimed removed	both new tests fail 3/3 (stayer pty-data not received), so the eager-close trap is pinned
bun test server/api.contract.test.ts ×4	24 pass / 0 fail each run
bun test	65 pass / 0 fail, 9 files
bun run typecheck / bun run build	clean
Failed lookup (w9999:p9999 ×2 racing, then again)	three pane_not_found frames, no hang
Leftovers after runs	no attach/sidecar processes, no herdr-web-ui-test* workspaces

The two new tests take about 1.5–2s each, because herdr terminal attach takes about 1.2s to exit after the sidecar kills it (measured separately). pushes pane-status … sometimes runs about 4.2s instead of 1.7s. That happens on main too: its status retry loop occasionally takes an extra round. This PR doesn't change it.

README: test count 63 → 65, and the coverage sentence now lists this case.

🤖 Generated with Claude Code