One bug, and a bad one: a session could stop answering permanently, with every
tool reporting Transport closed — including the one you would call to find out
why. Reported from a Codex session and reproduced here.
What happened. A client that pipes a server's stderr and stops reading it
leaves a 64 KB kernel buffer and no more. The write that fills it blocks, and it
blocks inside the event loop, so the session stops answering anything at all.
Measured: 3000 warnings wedged a real server for good. logging.shutdown flushes
handlers at interpreter exit, so a wedged stream also stops the process from ever
exiting — the same fault met on the way out, and what hung two attempts at a test
for it.
Claude Code is exactly such a client: it captures a server's stderr only while it
connects. And the flood needs no bad luck. A hat logs an operator message it does
not recognise, and a Codex hook asks the rendezvous point who is running on every
tool call, so any net holding one older session and one newer hook produces a
warning per tool call until the buffer fills.
What changed. The rule that nothing may block the session now covers the
diagnostics too. A bounded queue and a writer thread sit between the logger and
the stream, and a full queue drops the line rather than waiting on it: a radio
that stops relaying because nobody read its log has failed at the only job it
has. Separately the hat names an unknown operator message once instead of once
per message, since a newer peer questioning an older one is ordinary rather than
alarming.
Anyone running a mixed-version net should take this one. A session already wedged
cannot be recovered — the process has to be restarted, after which join_channel
with the same channel and name hands the membership back, secret included.