Port 7788 returned a registry where every session was exited

My saved note said each turn is a fresh claude -p and nothing can interrupt it. On 2026-10-06 an audit checked that against the code. The note was true of one path and had stopped being true of the default.

What the note was right about

The one-shot path runs a fresh claude --resume per turn, and a message sent during that turn only queued. The comment above streamInputDefault() in bridgeEngine.ts records the complaint in the author’s own words: “sits in queued forever”. A mid-September commit, “a message to a busy session queues instead of failing”, confirms the behavior. For that path the note was an accurate description of the code.

What changed under it

The stream-input bridge merged on 2026-09-17. A turn became one long claude -p --input-format stream-json process with a stdin relay, so a message sent mid-turn lands at the next tool step. Stop became a real interrupt first, with a 20 s grace, and only then a kill. Mid-turn delivery became the default on 2026-09-22, and the note never caught up.

Building a replacement for a limit that was already gone

On 2026-09-25 and 09-26 we committed and pushed a session host: a long-lived claude process per session, driven over stdin/stdout stream-json, with its own window page. The commit history reads like a replacement engine. There was a prototype, then a hardening pass with a hard-kill interrupt and tree cleanup, then a flagged, off-by-default adapter, then a minimal Allow/Deny permission card. All of it landed days after the default had already flipped.

The audit priced it. This is the state of the replacement as of that day:

• The host process is up, started at 09:22, and GET :7788/sessions returns a registry where every session is exited.
• The global switch is on, but only one session has opted in. Every other session page still runs on bridgeEngine.
• The scheduled task that used to start the host is retired, and the task that replaced it was parked by a commit that same day. Nothing supervises the host. Which caller started this instance is, in the audit’s words, a hypothesis.
• The host path skips per-message delivery receipts and defaults the model to sonnet unless one is named. The adapter always runs with permission prompts switched off.

Verified, hypothesis, not verified

The audit labeled every line VERIFIED, HYPOTHESIS or NOT VERIFIED, and it checked the experiments ledger first so it would not repeat a recorded result. The ledger held entries on a secretary window, an agent dock and auto-management. It had nothing on the session host or interrupt.

Verified from code: the composer is hard-disabled only for host kind foreign (a live Cursor, terminal or SDK claude owns the session) or when claudeAvailable is false. The console and role hosts became typeable again on 2026-09-25. Other verified lines came with the command or file behind them, such as nssm get on the service environment, netstat -ano | grep :7788, and the line range in SessionChat.tsx.

Not verified: that stream-input mid-turn delivery works end to end on the live service for a real session. Unit tests exist, built on a fakeStreamClaude.cjs fixture, but no live demonstration is recorded.

The host has the same hole. It supports a soft interrupt (control_request, 5 s grace) and then a tree-kill, and acceptance tests 2 and 3 in test.js cover mid-turn message and interrupt. But “7 of 7 passed” has no pass log behind it. The only recorded live run is a streaming session from 2026-09-26 showing text_delta, message_complete, idle and reconnect replay. Nobody recorded interrupting a real session mid-turn through the page, and there is no respawn latency number either.

The “won’t let me send” symptom could not be reproduced. The audit listed three candidate explanations, picked none, and called all three hypotheses:

1. The pre-09-22 queued-forever behavior.
2. A foreign-locked mirror page.
3. A role or secretary window pointing at a broker page.

There is no transcript of the exact failure, so which one it was is unknown.

Where it ended

The audit closed with a list of gaps. The first is that only one session is opted in. The second is that there is no recorded live proof of an interrupt plus a mid-turn message through the page on a real session.

A note that was true when I saved it described the one-shot path correctly and the default path wrongly.

dxdev LESSON · paste into your AI coding agent
LESSON: Re-Verify a Remembered Premise Against the Code Before Building on It, and Label Every Claim as Verified, Hypothesis, or Not Verified
SOURCE: dxdev.com/blog/remembered-premise-partly-stale
WHAT HAPPENED: The note accurately described the one-shot path, where a mid-turn message only queued. The stream-input bridge merged on 2026-09-17 and became the default on 2026-09-22, giving mid-turn delivery and a real interrupt with a 20 s grace before a kill. On 2026-09-25 and 09-26 a separate session host was shipped as a replacement engine for a limit the default path no longer had. By the audit, the host was up but every session in its registry was `exited`, only one session had opted in, and nothing supervised it. The audit also found no recorded live proof of an interrupt or mid-turn message on a real session, and no pass log behind the '7 of 7 passed' claim.
THE RULE: Before building on a remembered limitation, re-check it against current code, because a note that was once accurate can go stale. Record each claim as verified with its evidence, as a hypothesis with candidates, or as not verified with the missing evidence named.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
      1. Every claim in a saved note about system behavior names the command or file and line range that verified it, or is explicitly marked as unverified.
      2. Before starting work meant to remove a limitation, someone has re-read the current default code path and the commit history since the note was written to confirm the limitation still exists.
      3. Test claims such as '7 of 7 passed' and features like interrupt or mid-turn delivery have a recorded pass log or live run output attached, not just unit tests against a fixture.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.