Typed input queued mid-turn is silently dropped at turn end (end_turn, no Escape involved) -- interactive TUI

Environment

• Claude Code 2.1.220 and 2.1.226, macOS (darwin 25.3), interactive TUI

inside tmux panes; both symptom shapes (turn-end unfed and idle-pane
no-turn-starts) observed on both builds

• Long-running agent sessions; input typed while a turn is running

What happens

Text typed into the composer while a turn is running, submitted with Enter (it
leaves the visible composer and enters the internal prompt queue), is sometimes
never delivered to the model after the running turn ends normally. No error is
shown; the input is simply gone from both the composer and the conversation.

Evidence chain (one fully-instrumented occurrence, 2026-08-08)

External automation owns this pane's composer and records every write, which is
what closes the chain:

1. 17:48:15 -- composer verified empty (an automated injection delivered and

submitted cleanly; the delivery ledger records the pane state after it).

1. During the running turn, the user typed a short line and pressed Enter

(the line is absent from the composer afterwards, so it entered the queue).

1. 17:49:01 -- the turn ended with stop_reason: end_turn; Stop hooks fired

normally (their output is in the session transcript). Not an interrupt, not
a crash, not an Escape.

1. 16 seconds of idle: no next turn began, as expected for an empty queue --

except the queue should not have been empty.

1. 17:49:18 -- a scripted probe read the TUI buffer: composer empty, no queued

line rendered, and the typed text never appeared as a user message in the
transcript JSONL.

So the input passed into the internal queue and the queue was not fed at turn
end. A separate, previously-known class exists where Escape/kill pops the queue
(reproduced under control on 2026-08-05); this occurrence is distinct -- the
turn ended honestly.

Second occurrence, rendered-but-unfed variant (2026-08-09)

Same honest-end gap, different rendering: here the unfed line stays VISIBLE as
a rendered queue head in the idle composer box instead of vanishing.

1. A turn ran 12:29:56-12:38:09 and ended normally (end_turn; Stop hooks

fired -- their structured output is in the transcript).

1. During that turn the user typed a short line at the physical keyboard and

pressed Enter (no automation wrote to this pane in the window; the line is
absent from the transcript JSONL as a user message).

1. 12:38:09 onward -- the pane sat idle 4.8 minutes. No next turn began. The

machine was not loaded in this window (independent load telemetry; a
saturation incident began only at 12:44:31, after detection).

1. 12:42:57 -- an automated delivery attempt found the line rendered inside

the composer box. A discrimination probe (type one char, observe, BSpace)
proved the edit buffer EMPTY behind the render, and the head re-rendered
after BSpace: the text lives in the internal prompt queue, not the buffer.

1. The queue was never fed. Our tooling force-submitted the pane at 12:44:59

and the queued line finally rode that turn into the model.

The two variants bound the symptom: the queue survives an honest end_turn
unfed, and afterwards either renders in the idle box (recoverable by a probe)
or is gone entirely (specimen 1).

Third occurrence, rendered-but-unfed, on 2.1.226 (2026-08-09)

Same variant as the second occurrence, on a NEWER build -- the gap persists
across 2.1.220 -> 2.1.226:

1. A turn ended normally at 22:37:50Z (stop_reason: end_turn; Stop hooks

fired and turn_duration was stamped -- transcript rows are consecutive
and complete).

1. The pane sat idle 4 minutes 42 seconds. No next turn began, though the

queue held a line ("build the iOS app and ship it to TestFlight" -- typed
into the pane; it never appears as a user message anywhere in the
transcript JSONL before recovery).

1. 22:42:32Z -- our recovery probe found the line rendered as a queue head in

the idle composer (edit buffer proven empty behind the render) and
force-submitted it; the line finally rode that turn into the model.

The idle-gap length matches the second occurrence (4.7 vs 4.8 minutes),
consistent with detection latency of our sweep, not with any internal retry.

Fourth occurrence, rendered-but-unfed, submit window overlapping a Stop-hook continuation (2026-08-10)

Same rendered-but-unfed variant, again on 2.1.220. The new datum: the submit
window overlaps a Stop-hook continuation turn, so the queue survived TWO
consecutive honest ends unfed.

1. A turn ended normally at 22:34:23Z (end_turn). The Stop hook fired at

22:34:24Z (its hook_success row is in the transcript) and its continuation
turn ran 22:34:33-22:34:35Z, itself ending with end_turn. No Escape, no
interrupt, no API error anywhere in the window.

1. The user foregrounded the controlling phone client at 22:34:22Z (WebSocket

resync logged server-side) and submitted a short reply. The exact keystroke
instant is unrecorded (submitted terminal keystrokes are not ledgered),
bounded 22:34:22Z-22:40:04Z.

1. The pane sat idle from 22:34:35Z. No next turn began, though the queue held

the line ("I opened the Encore drawer, check the stor[e]"). It appears
nowhere in the transcript JSONL as a user message before recovery; its only
occurrence in the entire file is inside the recovery turn's banner.

1. 22:40:04Z -- a pane probe (a boot pass after a controller-process respawn)

grew the squashed 20-row viewport to 45 rows, found the line rendered as a
queue head in the idle composer box, and stamped a sighting.

1. 22:42:10Z -- the follow-up probe 126s later found it still rendered and

unfed, proved the edit buffer empty behind the render, and force-submitted;
the line rode that turn and the agent answered it at 22:43:19Z.

The turn-end probe that runs at every Stop logged no sighting at the 22:34:35Z
end (a first contact logs unconditionally), consistent with the line entering
the queue after that probe's capture -- during the Stop-hook continuation or
the idle window that followed; a probe skip on the then-squashed 20-row
viewport cannot be fully excluded. In the idle-window case Enter should have
started a turn immediately, which would make this a third symptom shape.

Fifth occurrence, same pane as the fourth, 19 minutes later (2026-08-10)

The same tmux pane as the fourth occurrence, the same conversational shape,
19 minutes apart -- the first observed per-pane repetition:

1. The recovery turn from the fourth occurrence ended normally at 22:43:51Z

(end_turn, Stop hook + its continuation completed, same as before).

1. The user replied from the same phone client ("I tapped the update banner

and reopened th[e app]"). The line appears nowhere in the transcript JSONL
as a user message before recovery.

1. The pane sat idle from 22:43:51Z; no next turn began. The turn-end probe at

the 22:43:52Z Stop again logged no sighting, again bounding the submit
after that capture.

1. 22:53:30Z -- the sweep found the line rendered as a queue head (edit buffer

empty behind it), force-submitted, and the agent answered it.

Two consecutive user replies into the same idle pane both entered the queue
and were both never fed. This suggests a persistent per-pane TUI state in
which the queue feed reliably fails, rather than a race that strikes at
random -- consistent with an earlier pane we observed (2026-08-04) where a
submitted turn repeatedly failed to consume the rendered queue at all.

Sixth occurrence, rendered-but-unfed, queue observed alive mid-window (2026-08-10)

Same rendered-but-unfed variant, on 2.1.220, in a different session's pane than
occurrences four/five. Two new data: the unfed queue was OBSERVED alive partway
through the idle window (every prior specimen has only first-contact at
recovery), and this pane is the second showing per-pane repetition.

1. A turn ended normally at 22:45:44Z (stop_reason: end_turn; Stop hook

summary and turn_duration rows are consecutive and complete). No Escape,
no interrupt, no API error anywhere in the window.

1. A short line entered the internal prompt queue. No automation door recorded

writing it (entry bounded to direct keystrokes at the terminal); it appears
nowhere in the transcript JSONL as a user message before recovery -- its
first occurrence in the entire file is inside the recovery turn's banner.

1. 22:48:14Z -- an automated delivery attempt into the pane read the composer

and classified the content as a rendered queue head with the edit buffer
empty behind it: a live queued line awaiting its next turn. The delivery
deliberately deferred, granting the TUI a grace window to feed it.

1. The pane stayed idle; no next turn began. 22:50:21Z -- the delivery retry

found the head still rendered and still unfed, 4 minutes 37 seconds after
the honest end (gap length again matching sweep detection latency, 4.7/4.8
min in occurrences two/three), and force-submitted; the queued line rode
that turn into the model and the agent processed it.

1. This was the pane's FIFTH queue recovery in 15 hours (09:29, 19:46, 21:32,

00:43, 00:50 local) -- the 00:43 recovery's own turn ended honestly at
22:45:44Z and the very next queued line was again unfed, the same
recover-then-restrand shape as occurrence five. Per-pane repetition now
holds on two independent panes, strengthening the persistent per-pane TUI
state hypothesis over a random race.

The mid-window sighting closes an alternative reading of the rendered variant:
the line was not typed post-turn into a dead composer -- it was held by the TUI
as a queue render, observed awaiting feed 2.5 minutes after the honest end, and
still unfed 2 minutes later.

Seventh occurrence, both sides of one conversation, desk-typed, saturation present (2026-08-10)

Same rendered-but-unfed variant on 2.1.220, striking twice within four
minutes -- and the two stranded lines were the two sides of ONE live user
conversation held across two sessions (the user adjudicating an earlier
deletion). Both chains are closed with server-side log stamps:

1. Session A: a turn ended normally at 22:41:46Z (end_turn; Stop-hook

summary and turn_duration stamped). The user's reply was typed at the
physical keyboard; no automation, phone client, or recorded delivery door
wrote to this pane in the window, and the line appears nowhere in the
transcript JSONL before recovery. 22:41:51Z -- five seconds after the end,
the turn-end check logged the head rendered at the live edge
("consumption expected"). 22:43:54Z -- still rendered, still unfed, edit
buffer proven empty behind the render; force-submitted ("yes the delete
was the accident, tell ym-identity-acce[ss]").

1. Session B, four minutes later: two consecutive turns ended normally at

22:45:13Z and 22:45:31Z (both end_turn, Stop hooks fired,
turn_duration stamped). 22:45:37Z -- five seconds after the last end,
the same live-edge sighting ("the delete was intentional, no need to
restore it"). 22:47:47Z -- still unfed, force-submitted. A third line of
the same exchange stranded on the same pane (sighted 22:49:05Z, recovered
22:51:34Z by a boot pass).

Both sightings landing ~5 seconds AFTER an honest end is the tightest bound
yet: the queue carried the line across the end and the TUI re-rendered it at
the idle edge instead of feeding it -- twice, on two different panes.

The consequence datum: recovery dates detection, never typing, so when both
sides of one conversation strand, the true order of the user's statements
becomes unknowable -- and here the two recovered lines carried OPPOSITE
rulings ("the delete was the accident" / "the delete was intentional"). The
receiving agent could not act and had to flag the contradiction back to the
user. The gap does not merely delay input; it re-sequences a human decision
stream across sessions.

Both panes in this occurrence also re-stranded within minutes -- session A's
pane at 22:50:21Z (the sixth occurrence documents that recovery in full),
session B's at 22:49:05Z -- so per-pane repetition now holds on session B's
pane as well. Unlike the
second occurrence's calm window, this burst sat inside machine saturation
(15-minute load average 17.6 on 10 cores at 22:53Z) -- the second occurrence
shows load is not necessary, but the burst is consistent with load
amplifying the firing rate.

Eighth occurrence: a completed turn mid-window does not consume the rendered queue (2026-08-10)

The seventh occurrence's session-B pane, the third stranded line of that same
user exchange (the re-typed fuller confirmation, after the recovery of the
second line). Same rendered-but-unfed variant on 2.1.220. The new datum: a
turn STARTED, RAN, AND COMPLETED between sighting and recovery, and the
rendered queue survived it unfed -- the first specimen with a completed turn
inside the window (occurrence four's window held only a Stop-hook
continuation; five/six held no turn at all).

1. The recovery turn from the seventh occurrence's session-B flush ran

22:47:47-22:48:59Z and ended normally (stop_reason: end_turn; Stop-hook
summary and turn_duration stamped, a post-Stop hook continuation ran and
itself ended end_turn). No Escape, no interrupt, no API error anywhere in
the window; the process stayed alive (the same conversation received the
later recovery banner).

1. The user re-typed the confirmation at the physical keyboard ("yes, the

delete was intentional -- confirming from the [...]"). No automation,
phone client, or recorded delivery door wrote to the pane in the window;
the line appears nowhere in the transcript JSONL as a user message before
recovery -- its only occurrence in the entire file is inside the recovery
turn's banner.

1. 22:49:05Z -- six seconds after the honest end, the turn-end check sighted

the line rendered at the live edge as a ring-backed queue head and
deferred ("consumption expected", 120s grace).

1. 22:50:23Z -- a task-notification (background-task completion, a

non-composer entry path) started a turn in the same conversation. It ran
nine seconds and ended normally at 22:50:32Z (end_turn, Stop hooks
fired). The queued line did not ride it and stayed rendered.

1. The 120s graduation was due ~22:51:05Z; the controlling server happened to

restart at 22:51:04Z (an unrelated auto-restart), and its boot pass found
the sighting matured across the boot and flushed at once at 22:51:34Z
(head captured clipped at pane width). The line rode the flush turn into
the model; the agent cross-checked the decision-shaped text against its
own answered-steer record and confirmed consistency before standing down.

So the queue carried the line across one honest end, one full completed turn,
and that turn's honest end -- observed rendered before and after the
mid-window turn. Whether the task-notification path shares the typed-input
queue internally is not observable from outside; the observable bound is that
a turn CAN complete while the rendered head sits unfed, which turns the
"persistent per-pane state where the feed reliably fails" hypothesis
(occurrences five and six) into a directly instrumented fact on this pane.
The human cost is also now measured: the gap swallowed the user's answer to
the same question twice in four minutes, forcing him to type the same
decision a third time.

Ninth occurrence: idle-pane submit -- the queue accepts the line and no turn starts (2026-08-10)

The eighth occurrence's pane again, its third stranding of the night, the same
user adjudication answer swallowed a third time. This one isolates the "third
symptom shape" that occurrence four could not exclude: the submit happened on
a fully IDLE pane, so no turn-end race is available as an explanation.

1. The eighth occurrence's recovery turn ended normally at 22:52:16Z

(end_turn, Stop-hook summary and turn_duration stamped). From there the
transcript is EMPTY until the next recovery banner at 23:15:31Z -- no turn,
no task notification, no continuation, nothing. 23 minutes of idle.

1. During that idle window the user typed the line at the physical keyboard

("yes, confirming from the laptop -- the delete was inte[ntional]") and
submitted. No automation or recorded delivery door wrote to the pane; the
line appears nowhere in the transcript JSONL before the recovery banner.
The exact submit instant is unrecorded (the idle pane generates no events,
so nothing looked until the next watcher pass), bounded 22:52:17Z-23:13:17Z.

1. On an idle pane, Enter should start a turn immediately. No turn started.

The line went into the internal prompt queue and stayed there, rendered as
a queue head in the composer box.

1. 23:13:17Z -- a watcher pass sighted the head rendered at the live edge,

classified it ring-backed (a queue render, edit buffer empty behind it) and
deferred 120s expecting consumption. The classifier's discrimination is
demonstrated the same night: on another pane it held a genuine
in-progress draft with verdict "draft" and refused to flush it.

1. 23:15:31Z -- still rendered, still no turn; the graduation probe

force-submitted, the line rode the flush turn into the model, and the agent
again cross-checked the decision text against its answered-steer record
before standing down (23:16:27Z).

The programmatic recovery submit two minutes later DID start a turn and DID
carry the queued line in -- so the pane can still run turns; what fails is
specifically the consumption of composer-entered input at its own submit.
With occurrences five, six, and eight this completes the picture of a
persistent per-pane state: typed input reliably enters the queue and the
queue is reliably not fed, whether a turn ends (two/three/seven), a turn
completes mid-window (eight), or no turn exists at all (this one). The same
user answer has now been typed four times across the two panes of this
exchange -- the practical effect is a conversation where every reply arrives
minutes late through recovery tooling, or not at all without it.

Tenth occurrence: third strand on the fourth occurrence's pane -- every reply on it now strands (2026-08-10)

The fourth/fifth occurrences' pane, its third stranding in 45 minutes. Every
reply the user has submitted to this pane tonight entered the queue and none
was fed; the conversation advances only when recovery tooling force-submits.

1. The fifth occurrence's recovery turn ended normally at 22:54:32Z

(end_turn, Stop hook complete), the agent again explicitly waiting for
the user's next answer. From there the transcript is empty until the
recovery banner at 23:19:54Z -- 25.4 minutes of idle, no turn of any kind.

1. During that window the user submitted the awaited answer ("The chips say

needs login") from the phone client. It appears nowhere in the transcript
JSONL as a user message before the recovery banner. Submit instant
unrecorded, bounded 22:54:33Z-23:17:54Z.

1. No turn started (idle-pane shape, as isolated by occurrence nine). The

line sat rendered as a queue head until a watcher pass sighted it, deferred
120s, and the graduation probe force-submitted at 23:19:54Z; the agent
consumed it and answered within 33 seconds.

Three consecutive strandings on one pane (occurrences four, five, ten) with
zero successfully-fed composer submits between them: on an affected pane the
failure rate is 100%, and it persists across 45+ minutes and multiple healthy
programmatic submits (each recovery turn ran fine). Whatever state the TUI is
in, its own recovery submits do not clear it.

Eleventh occurrence: third pane with repetition -- a fully working pane that strands only keyboard input (2026-08-10)

The third occurrence's pane, 38 minutes later -- per-pane repetition now holds
on a THIRD independent pane. The new bound: between its two strands this pane
was fully functional.

1. After the third occurrence's recovery (22:42:32Z force-submit), the pane

ran agent-driven work normally for ~35 minutes: tool-use turns, task
updates, an archive/export pipeline, several honest end_turns -- turns
start, run, and complete without issue.

1. The last of those turns ended normally at 23:18:02Z (end_turn, Stop-hook

summary and turn_duration stamped). The user's reply ("keep
respond-first, it was accidental but I actually like it") was typed at the
physical keyboard; no recorded door wrote to the pane, and the line appears
nowhere in the transcript JSONL before recovery.

1. 23:18:05Z -- three seconds after the honest end, the turn-end check sighted

the line rendered at the live edge as a ring-backed queue head (edit
buffer empty behind it) and deferred 120s expecting consumption.

1. The queue was never fed. 23:20:12Z -- the graduation probe force-submitted;

the line rode the flush turn in. The receiving agent treated the recovered
decision-shaped text per our strand contract: it did NOT let bare composer
text close its pending decision record, adjusted only its safe default, and
left the decision to the authenticated channel.

1. No Escape, no interrupt, no API error, no process death anywhere in the

window.

Combined with occurrence ten (same night, different pane: three strands in 45
minutes, zero fed submits between them), the affected-pane behavior is now
bounded from both sides: agent-driven and programmatic entries keep working
indefinitely, while keyboard-entered lines strand at a 100% observed rate --
on this pane the first typed line after 35 clean minutes stranded within
seconds of its submit window. The failure is specific to the composer's own
input path, not to the pane's ability to run turns.

Follow-up, third strand on this pane (23:30:51Z): the recovery turn above and
its Stop-hook continuation both ended honestly (last end_turn at 23:20:50Z,
Stop-hook summary and turn_duration stamped). The user's next keyboard reply
("check if build 75 showed up yet") stranded again -- no fed user message in
the 10-minute idle window, the graduation probe force-submitted at 23:30:51Z,
and the agent answered within 15 seconds. A fourth strand followed on the
identical shape (honest end_turn at 23:31:06Z, then 10.4 minutes of PURE
idle -- no turns of any kind in the window, zero fed user messages -- flush
at 23:41:27Z, answered in 15 seconds). Keyboard replies on this pane are now
0-for-4 tonight while every machinery turn (recovery flushes, Stop-hook
continuations, task updates) feeds normally, matching the twelfth occurrence's
pane at 0-for-4. Note the conversational lock-in this produces: each strand is
the user REPLYING to the answer of the previous flush, so on an affected pane
the human half of the dialogue survives only through our recovery tooling.

Twelfth occurrence: a task-notification turn runs OVER the queued line and ends without feeding it (2026-08-10)

The tenth occurrence's pane, its fourth stranding in under an hour -- and the
cleanest capture yet of the eighth occurrence's shape, with server-side stamps
at every hop:

1. After the previous recovery turn (23:20:33Z end), the user followed the

agent's own instruction ("log in once"), then replied "I logged in, did the
notes arrive now?". Submit bounded 23:20:34Z-23:28:02Z.

1. 23:28:02Z -- a task-notification turn started NORMALLY (background-poll

notification; automation-fed input still works), ran 12 seconds, and ended
with end_turn at 23:28:14Z. It did not consume the user's queued line.

1. 23:28:14Z, the same second the turn ended -- the turn-end probe sighted the

line rendered as a queue head and stamped it (server log, INFO). So the
queue was already rendered when the turn ended, a whole turn had run over
it, and the end fed nothing.

1. 23:30:20Z -- still rendered after the 120s consumption window; the

graduation probe force-submitted, and the agent answered within 25 seconds.

Four consecutive keyboard replies on this pane, 0 of 4 fed. Between them the
pane ran recovery turns, a bounded watch, and task-notification turns without
a hitch -- the failure isolates to composer-entered input exactly as on the
eleventh occurrence's pane. Two panes now show this isolation independently.

Follow-up, the pane's fifth strand (2026-08-10): ten minutes after the
recovery above, the user RE-TYPED his still-unanswered question ("did the
notes arrive now?") -- fresh keystrokes, first sighted 23:40:24Z. The line
queued, a turn ran over it and ended without feeding it (the same shape as
steps 2-3 above), and recovery force-submitted it at 23:42:30Z. Keyboard
0-for-5 on this pane, including the user's manual retry of a line our tooling
had already rescued once: on a locked pane even the human's own workaround
(type it again) re-strands.

Thirteenth occurrence: door-fed and keyboard input contrasted inside one reply cycle -- the same pane's fifth, sixth, and seventh strands (2026-08-10)

The seventh occurrence's session-B pane again. Its night now totals SEVEN
stranded keyboard lines with zero fed, and this occurrence captures the
cleanest composer-path isolation yet: a programmatic delivery and a keyboard
submit into the SAME conversation, minutes apart, one fed and one stranded.

1. The pane's fourth recovery turn ended honestly at 23:23:18Z (end_turn,

Stop-hook continuation complete). 23:25:41Z -- a server-held dictated
message was delivered into the pane by the automation door and FED
normally, starting a working turn that ran 9.4 minutes (file edits and a
git commit inside it) and ended honestly at 23:35:05Z (end_turn, Stop
hooks fired, completion card posted in-turn).

1. During that turn the user typed the follow-up at the keyboard ("did the

auto-boot land and the slower poll verify?"). No recorded door wrote to
the pane; the line appears nowhere in the transcript JSONL before its
recovery banner. Submit bounded 23:25:42Z-23:35:05Z.

1. 23:35:10Z -- five seconds after the honest end, the turn-end check sighted

the line rendered as a ring-backed queue head at the live edge (edit
buffer empty behind it) and deferred 120s ("consumption expected") --
the second ~5-second post-end sighting after occurrence seven, now on a
submit known to predate the end.

1. 23:37:16Z -- still unfed; the graduation probe force-submitted. The line

rode the flush turn and the agent answered within 22 seconds (by voice)
and armed a verification watch. The recovery turn ended honestly at
23:37:53Z, its Stop-hook continuation at 23:38:02Z.

1. The user re-typed the same question ("did the boot land and the slower

poll verify?") before the answer reached him. 23:38:08Z -- six seconds
after the continuation's honest end, the same live-edge sighting; never
fed; force-submitted at 23:40:52Z. The agent recognized it as already
answered. A third keyboard line ("commit and push the statusline script
changes too") stranded the same way and was force-submitted at 23:43:15Z.

Seven keyboard lines entered this pane's queue tonight (recoveries at
22:47:47, 22:51:34, 23:15:31, 23:22:50, 23:37:16, 23:40:52, 23:43:15Z); the
TUI fed none. Between them, door deliveries, task notifications, and every
recovery turn ran normally -- so a third pane now shows the keyboard-only
isolation, here demonstrated within a single reply cycle: the door-delivered
message at 23:25:41Z fed instantly into the very conversation whose
keyboard-typed follow-up stranded minutes later. The re-type at step 5 also
shows the lock-in cost compounding: the user's answer to a recovery turn
strands across that recovery's own honest end (sighted +6s), so without the
sweep every exchange degrades into re-typed duplicates arriving out of order.

Follow-up, eighth strand on this pane (23:46:19Z): the seventh strand's
recovery turn ended honestly and the user's next keyboard line ("verify the
passive floor logged zero probes during wor[k]") was sighted ring-backed at
23:44:04Z, seconds after that end -- the fourth consecutive reply-to-a-
recovery to strand on this pane. Never fed; force-submitted at 23:46:19Z.
Keyboard input on this pane is now 0-for-8 tonight; the same minute a second
pane's strand was flushed (23:46:20Z), the night's fleet count passing 21.

Ninth strand, same cycle (23:49:44Z): the eighth strand's recovery turn ended
honestly and the user's next line ("did the working window verify zero
probes?") was sighted ring-backed at 23:47:35Z, seconds after that end -- the
fifth consecutive reply-to-a-recovery on this pane, 0-for-9 keyboard, healed
in 2m09s. The pane has not been restarted; its stuck state now spans three
hours of otherwise flawless turns.

Tenth strand (23:52:18Z): "report the final count when the window closes",
sighted ring-backed at 23:50:09Z -- 25 seconds after the ninth's recovery
flush -- and force-submitted after the 120s window. Sixth consecutive
reply-to-a-recovery, 0-for-10 keyboard; the recovery cadence is now the
conversation's only transport.

Eleventh strand (23:56:38Z): "bump the login banner snooze to 60 minutes" --
the first stranded WORK ORDER on this pane after ten questions and rulings --
sighted ring-backed at 23:54:32Z after the tenth's recovery turn ended,
force-submitted after the 120s window. 0-for-11 keyboard, seventh
consecutive reply-to-a-recovery.

Twelfth strand, morning after (07:19:12Z 2026-08-10): the pane sat quiet 7.4
hours (same Claude Code process, same conversation transcript -- no restart).
At 07:14:10Z a deferred-send door delivery fed instantly and its turn ended
honestly at 07:16:34Z; the user's typed reply ("yes, check castle.80 and
labour-inland too") was sighted ring-backed at 07:16:40Z -- six seconds after
the end -- never fed, force-submitted at 07:19:12Z. So the stuck state is not
time-decaying: it survived the idle night and ate the first keyboard line of
the morning while the door path kept working. 0-for-12 keyboard on this pane.

Thirteenth strand (07:22:36Z): "drop them from the roster, I ended both
subscriptions" -- sighted ring-backed at 07:20:21Z seconds after the
twelfth's recovery turn ended, force-submitted after the 120s window,
0-for-13. The consequence sharpens: an account-removal decision now reaches
its agent only as recovered composer text, whose authorship and age the
receiving side must treat as unverified (our recovery contract forces a
cross-check against the authenticated decision record before acting) -- the
gap is routing destructive rulings through the least-trustworthy channel.

Fourteenth strand (08:29:26Z): the idle-pane shape appears on this pane too.
The thirteenth's recovery turn ended honestly at 07:23:44Z and the pane sat
idle over an hour; the user's line ("did the reset-timed reads boot and
verify?") was submitted into that fully idle pane and no turn started. A
watcher pass sighted it ring-backed at 08:27:21Z, the graduation probe
force-submitted at 08:29:26Z. 0-for-14 keyboard; this pane now shows BOTH
symptom shapes (turn-end unfed and idle-pane no-turn-starts), matching the
bound already established fleet-wide in Environment.

Fourteenth occurrence: fifth strand on one pane, a dismiss turn cycles cleanly inside the window (2026-08-10)

The fourth/fifth/tenth/twelfth occurrences' pane, its fifth stranding of the
night -- keyboard input on it is now 0 for 5 while every automated turn keeps
executing:

1. 23:40:23Z -- the previous recovery turn ended normally (end_turn), the

agent again explicitly waiting for the user's rate-bucket answer.

1. 23:42:30Z -- an automation-delivered dismiss turn (our machinery cleaning

its own residue) started, ran, and ended normally at 23:42:38Z. The pane's
turn pipeline is fully healthy.

1. The user's awaited reply ("what did the rate buckets show?") was submitted

in the window, bounded 23:40:24Z-23:44:10Z; it appears nowhere in the
transcript before the recovery banner. If it preceded the dismiss turn,
that is another completed turn running over a rendered queue.

1. 23:44:10Z -- watcher pass sighted the rendered queue head (server-stamped);

23:46:20Z -- graduation probe force-submitted after the 120s window; the
agent consumed the line and worked it immediately.

Between this pane's five strands it ran recovery turns, background polls, a
bounded watch, and a residue dismissal without one failure. Nothing typed into
its composer has been fed all night; the pane has not been restarted (same
conversation transcript throughout), so the state has persisted 70+ minutes.

Fifteenth occurrence: sixth strand on the same pane, idle-pane shape, tightly bounded (2026-08-10)

The fourth/fifth/tenth/twelfth/fourteenth occurrences' pane, its sixth
ledgered strand of the night, and the tightest submit bound yet for the
idle-pane shape:

1. 23:52:19Z -- a task-notification turn started normally (the TUI's queue

machinery visibly active: two queue-operation rows precede it in the
transcript), ran 7 seconds, ended end_turn at 23:52:26Z.

1. The turn-end probe at that Stop logged no sighting, so the composer was

clean at ~23:52:27Z.

1. The user's reply ("Build 102 is live, I read the error line n[ow]")

was submitted into the idle pane inside the next 99 seconds -- bounded
23:52:27Z-23:54:06Z, when a watcher pass sighted it rendered as a queue
head. Enter on an idle pane started no turn.

1. 23:56:12Z -- graduation probe force-submitted after the 120s window; the

agent consumed the line and answered within 4 seconds.

Six ledgered strands on this pane in 74 minutes, 0 of 6 keyboard submits fed,
against a night of flawless automation-fed turns on the same pane -- including
one 100 seconds before this strand landed.

Sixteenth occurrence: the stuck pane state survives a six-hour idle night (2026-08-10)

The same pane as occurrences four/five/ten/twelve/fourteen/fifteen, its
seventh keyboard strand -- and the first proof the state is not time-bound:

1. 23:56:16Z -- the previous recovery turn ended normally (end_turn), the

agent explicitly noting the user's next message would carry the error line
it asked for.

1. The transcript is then EMPTY for six hours (the user was away overnight);

no turn, no notification, nothing.

1. The user's first morning reply ("The error line says TypeError: Failed to

f[etch]") was submitted into the idle pane and started no turn. Sighted
rendered as a queue head at 06:00:03Z; force-submitted at 06:02:08Z; the
agent consumed it and was debugging within 30 seconds.

1. A second session's pane stranded the user's other morning reply the same

way; one sweep pass healed both. That strand is detailed as the
seventeenth occurrence -- one specimen, counted once.

Seven keyboard submits on this pane since 22:40Z, zero fed, spanning 7.3
hours and an idle night. The state neither self-heals with time nor decays
with inactivity; the pane was never restarted (one conversation transcript
throughout).

Seventeenth occurrence: the sweep's other half -- one conversation re-strands across a pane replacement and the binary roll (2026-08-10)

The second pane healed by the sixteenth occurrence's 06:02Z sweep pass, and a
bound the single-pane lineages cannot give: this conversation had already
stranded four times the previous evening on a DIFFERENT tmux pane.

1. One conversation (transcript begins 2026-08-07, five recovery banners in

it) stranded four keyboard replies on its original pane between 18:31 and
19:16 local on 2026-08-09. That evening's fleet-wide binary roll
(2.1.220 -> 2.1.226, ~19:18, every terminal restarted and resumed into its
exact conversation) moved the session to a new pane id; the SAME
conversation then stranded again at 01:51 and overnight (inferred pairing
of roll and pane change -- the timestamps bracket it).

1. 23:56:20Z -- the last turn ended normally (end_turn, Stop hooks fired);

the agent explicitly parked awaiting the user's reading of an error line.

1. Six hours of idle transcript follow. The user's morning reply ("The grey

line says the request body is already used") was submitted into the idle
pane and started no turn -- the idle-pane shape. The line appears nowhere
in the transcript before its recovery banner.

1. 06:02:07Z -- the sweep force-submitted; the agent was acting on the reply

within 20 seconds.

Six keyboard strands on one conversation across two panes and a client
restart: whatever carries the condition, it is not tmux pane identity, and it
either survives a process restart-and-resume or redevelops readily inside the
same resumed conversation.

Eighteenth occurrence: the intermittent form -- a fed keyboard submit between strands on one pane (2026-08-10)

A pane with three ledgered strands across two days (21:18Z and 23:20Z on
2026-08-09/10 night, then this one at 10:40Z) -- and the first documented
case of keyboard input FEEDING NORMALLY between strands on the same pane and
the same conversation:

1. 07:55:46Z -- the user's typed prompt fed normally and started a turn (it

is a regular user message in the transcript). 08:05Z -- two typed slash
commands also fed normally. The composer input path was demonstrably
healthy 33 minutes before the strand.

1. A long turn ran from ~08:05Z and ended normally at 10:38:15Z (end_turn,

Stop-hook summary and turn_duration stamped). During it the user typed
the next instruction ("sideload it into PowerPoint and push the VTTI
deck") -- the classic mid-turn queue.

1. 10:38:32Z, 17 seconds after the honest end -- an automated model-flip

attempt on the pane observed the line rendered as a ring-backed queue head,
refused to act over a live queue, and deferred 900s (the reconciler's own
log carries the observation).

1. The queue was never fed. 10:40:37Z -- the graduation probe force-submitted;

the line rode the flush turn in and the agent acted on it. No Escape, no
interrupt, no API error; CC 2.1.226; the head appears nowhere in the
transcript before the banner.

This bounds the per-pane condition from the other side: alongside panes that
lock hard (0-for-14 keyboard, surviving idle nights), a pane can strand, later
feed typed input normally, and then strand again within one conversation and
one process. The condition is therefore not a permanent one-way latch in every
case -- it either clears and re-arms, or strikes per-submit with high but not
total probability on affected panes. Any internal state hypothesis needs to
accommodate both the hard-locked and the intermittent presentation.

Continuation, same day: after the fed window the pane re-armed and stranded
the user's next three replies (recoveries 10:40:37Z, 10:47:10Z, 11:05:03Z) --
a live testing dialogue where every user leg now takes the recovery detour,
while the agent's own turns (including a monitor arming for exactly the event
the user was typing about) run normally. Lifetime on this pane: one fed typed
prompt against five strands. The intermittent presentation is thus a phase,
not a milder variant -- the pane oscillates into the same reply-cycle the
hard-locked panes show.

Seven minutes after that force-submit the same pane stranded again: the user's
completion report answering the rescued instruction ("I sideloaded it, the
pane is open") was typed at 10:44-10:47Z into a pane whose turn had ended
honestly three minutes earlier, started no turn, and rode the next probe flush
in at 10:47:10Z -- the pane's third strand, and the second consecutive
exchange on it to need the rescue detour on both legs.

The pane then hard-locked. Strands four and five followed within 35 minutes
(11:05:03Z and 11:21:13Z, both after honest turn ends, both idle-pane shape):
a bug report ("the pane shows an error when I tap push") and, sixteen minutes
later, the error text the agent needed ("The error says 'enter a deck id from
the canvas'"). The intermittent pane of the eighteenth occurrence thus
converged to the hard-locked presentation within the hour: a live debugging
dialogue -- report, question, answer -- proceeding entirely at the recovery
probe's cadence, roughly one leg per quarter hour against a user answering in
seconds.

The pane's sixth strand closed the arc at 13:34:49Z: the user's SUCCESS
confirmation ("it works, all slides came in"), typed 93 idle minutes after an
honest turn end, queued dead and additionally blocked two incoming voice
deliveries that refused to overwrite the live-looking queue head. Every leg of
the feature's entire delivery conversation -- work order, completion report,
bug report, error text, success confirmation -- reached the agent only through
external rescue. Not one keyboard submit on this pane has fed normally since
10:38Z. The lock also survived the feature boundary: the NEXT feature's work
order ("build the readback so the canvas knows the slide ids"), typed into
the pane after the success confirmation's rescue turn ended honestly, stranded
the same way and rode the probe in at 14:01:26Z -- the pane's seventh, keyboard
0-for-7.

The pane's eighth strand followed the next recovery cycle, idle-pane shape:
the seventh strand's recovery turn ended honestly at 14:03:54Z (end_turn,
Stop-hook summary and turn_duration stamped) and the transcript is then
empty for 14.1 minutes -- no turn of any kind. The user's typed reply to that
recovery's output ("I reloaded the pane and pushed again, the mapping works")
started no turn; a watcher pass sighted it rendered as a ring-backed queue
head at 14:15:57Z, deferred 120s expecting consumption, and the graduation
probe force-submitted at 14:18:00Z. The recovery contract then earned its
keep on the head's CONTENT: the receiving agent checked the recovered claim
against its receipts and found it unsupported (zero bridge requests since the
feature shipped, no mapping file on disk) -- a live testing report had aged
into an unverifiable claim during its strand, and the agent had to re-open
the question instead of building on it. Keyboard 0-for-8 on this pane since
10:38Z; every machinery turn continues to feed.

The ninth strand closed that re-opened question's loop the same way it was
opened. The eighth strand's recovery turn ended honestly at 14:19:49Z with an
explicit retest instruction to the user (reopen the pane, push into a fresh
presentation); the user performed the retest and typed the report ("I pushed
again from a fresh presentation, check the mapping"). Enter started no turn;
a watcher pass sighted the ring-backed head at 14:26:12Z, deferred expecting
consumption, and the graduation probe force-submitted at 14:28:34Z, whole,
no clip. The verification duty the previous rescue created was thus itself
serviced through a rescue: on a locked pane, a claim invalidated by stranding
gets re-asked, and the re-ask's answer strands too -- the question cannot
close at conversational speed at all, only at probe cadence. (The recovery
turn again verified before trusting: the retest had replayed from the
client's cache, so the agent shipped a version stamp to make staleness
self-identifying rather than counting the claim.) Keyboard 0-for-9 on this
pane since 10:38Z.

A twelfth session joined the pattern the same hour: the user's typed answer to
an agent's posted decision question stranded on its pane after an honest turn
end (ring-probe rescue; the recovery tooling initially mis-ruled the exactly
tile-width line as clipped, a defect in our own instrumentation since fixed --
noted here only so the specimen's provenance is complete). Answers to decision
prompts are among the highest-cost losses: the asking agent sits blocked on
the assumption lane until the verdict arrives. Within the same hour a
thirteenth pane stranded another such decision answer ("Knowledge fidelity is
fine, keep the graph pure") the identical way.

The eleventh session's pane re-stranded five hours later (20:59:42 local):
the agent had shipped a feature and correctly instructed the user to tap the
update banner; the user complied and typed his live-testing report ("Okay I
tapped the banner, testing the hold on card 21 now") two minutes after the
honest turn end -- queued dead, probe-rescued. A user actively following the
agent's own just-given instruction still cannot reach it by keyboard.

Nineteenth occurrence: the sixth occurrence's pane returns in the afternoon -- idle-pane shape, a 28-second submit bound from a window-focus stamp (2026-08-10)

The sixth/seventh(A) occurrences' pane, quiet since its 22:50:21Z recovery,
stranded twice more in the afternoon -- its seventh and eighth ledgered
flushes. The new datum is the tightest idle-pane submit bound yet: every
prior idle-pane specimen bounds the submit in tens of minutes; here a
server-stamped window-focus event dates the user's arrival at the pane, and
the queue render was sighted 28 seconds later.

1. Seventh flush, the lead-in: the pane sat idle for hours (no transcript

activity in the window); a typed line ("also apply the session colors to
the history rows") was sighted rendered as a ring-backed queue head at
13:59:24Z, never fed, and force-submitted at 14:01:27Z. The agent worked
it and ended honestly at 14:03:53Z (end_turn; Stop-hook rows stamped
14:03:54Z, completion card and voice ack posted in-turn).

1. The recovered head's authorship being unverified under our recovery

contract, the user replied to that recovery's output: "yes I typed that,
and also color the expanded cards themselves" -- an authorship
confirmation plus a follow-on instruction, the reply-to-a-recovery shape
again.

1. The transcript is empty from the 14:03:53Z end until the recovery banner.

14:09:36Z -- the user's push-to-talk intent registered against this
session (server-stamped); 14:09:40Z -- the window-manager log stamps the
user's focus arriving at this pane's window. The reply was typed at the
physical keyboard inside the next 28 seconds; no recorded door wrote to
the pane.

1. 14:10:08Z -- a dictated delivery's deferred send read the composer, found

the line rendered as a ring-backed queue head (edit buffer empty behind
it), refused to overwrite a live-looking queue, and deferred 122s -- the
delivery-blocking cost of the sixth occurrence again. The pane was fully
idle; Enter should have started a turn six minutes earlier at the
latest sighting bound. No turn started.

1. 14:12:14Z -- the graduation probe force-submitted after the 120s window;

the line rode the flush turn in, the agent cross-checked the
decision-shaped confirmation per contract, worked the extension, and
ended honestly at 14:14:07Z -- under two minutes from flush to shipped.

1. The pane's next keyboard line ("remove the autosend chip, your assumption

was right") was sighted ring-backed at 14:16:03Z, seconds-to-minutes
after that honest end, and took the same recovery path -- keyboard input
on this pane is now 0-for-3 for the afternoon while door deliveries and
every turn ran flawlessly, matching the locked-pane presentation of
occurrences ten through thirteen.

1. That ninth flush's full chain, verified after the fold above was written:

the transcript is empty from the 14:14:07Z end to the recovery banner;
the graduation probe force-submitted at 14:18:10Z and the head fed whole
(no clip re-read needed). The line was another DECISION answer -- the
verdict on a steer the agent was working on assumption -- and the agent
handled it per the recovery contract: it matched the head against the
steer record rather than letting bare composer text close the question,
found it echoed the assumed option with the work already shipped, and
ended honestly at 14:19:20Z, seventy seconds from flush to done. The
strand's only cost was the ~2-minute verdict delay plus the resolver
page; a steer verdict is the highest-cost loss shape (the asking agent
sits on the assumption lane until it arrives), and this pane has now
stranded one.

Twentieth occurrence: the order to file THIS report stranded (2026-08-10)

The closing exhibit. The user's decision to file this very document as an
upstream issue -- "file the upstream issue to the claude-code repo", typed at
14:27-14:31Z into a pane whose turn had ended honestly at 14:27:48Z -- queued
dead, started no turn, and reached its agent only through the external probe
at 14:31:05Z. The formation was the standard one in every particular: honest
end_turn, Stop hooks fired, no Escape, no interrupt, no API death, the head
absent from the transcript before its recovery banner. The instruction to
report this bug was itself lost to this bug and delivered by the tooling built
to survive it.

Twenty-first occurrence: the user's retry of a stranded line strands again across a process replacement -- and recovery dedup cannot tell the retry from the old debris (2026-08-09/10)

The loss-compounding shape of the tenth/thirteenth occurrences taken one step
further: the RETRY of a stranded line is itself indistinguishable, to any
render-based recovery tooling, from the first loss's leftovers.

1. 2026-08-09, a pane with eight prior ledgered recoveries: the user's dictated

answer to a pending decision card ("Proportional to length -- confirming the
spine steer") queued dead. The recovery probe force-submitted it at 17:45:54
local; the pane's narrow tile (26 columns) clipped the captured head to
"Proportional to length", and 49 seconds after the flush turn the same head
rendered again -- the force-submitted turn had not consumed the queue entry
(the eighth occurrence's shape).

1. 19:18:02 local: the pane's claude process was replaced (--resume by an

external reset daemon). The in-process input queue died with it.

1. Between the replacement and the next morning the user re-entered the same

sentence into the NEW process -- the natural retry of a line he could see
had not been acted on. It queued dead again: no recorded delivery door
carried it, it appears nowhere in the transcript, no turn started. Same
sentence, two independent strandings, on either side of a process swap.

1. The recovery tooling's dedup memory (which exists because force-submitted

flush turns often fail to consume the queue, so re-flushing loops) matched
the re-entered line against the 2026-08-09 ledger row -- at 26 columns the
renders are byte-identical -- and refused to re-flush it as presumed debris
at every probe from 08:00 through 16:15 local on 2026-08-10. The user's real
answer sat hostage to the dedup horizon until 20:42:45 local, when a held
delivery's flush finally fed it -- roughly a day after his first attempt --
and a full-width re-read recovered the clipped tail ("-- confirming the
spine steer") for the first time.

1. Because recovered composer text cannot carry authorization, the agent could

bind neither delivery as a decision verdict: after two strandings, two
flushes, and a day of latency, the user's answer to a pending decision is
still formally unanswered, and the agent has had to ask a third time
through out-of-band UI.

The new datum for this report: on a stranding pane, the user's retry loop is
consumed by the same bug, and dedup logic that any external recovery tooling
MUST carry (see 4) then converts the second loss into a delivery delay bounded
only by the dedup horizon. Recovery tooling cannot fix this from outside the
TUI -- it cannot distinguish "the old queue entry still renders" from "the
user typed the same line again" without reaching into process state.

Frequency

On one busy session, external instrumentation recorded 5 such losses in 2 days
(each detected afterwards as orphaned text recovered from the pane by our own
tooling). Fleet-wide, pane-recovery tooling ledgered 14 flush-class recoveries
across 10 sessions on 2026-08-08/09 alone, and a further burst of 7 recoveries
across 4 sessions within twelve minutes on 2026-08-10 (00:42-00:54 local;
two of the four panes re-stranded within the burst). A second burst 01:19-01:20
flushed three more panes in 18 seconds, one of them its third strand of the
night. By 01:52 the night's count reached 24 flush recoveries (plus one
dismissal of machinery residue) across seven sessions, with one pane at ten
strands and keyboard input on all affected panes failing 100% of the time.
The seventh session's flush (01:51:43) was an idle-pane-shape strand on
2.1.226 in a different project tree -- the burst is neither build- nor
container-local. Happy to run added instrumentation if useful.

By midday 2026-08-10 a FOURTH pane showed the keyboard-only lock (four strands
across two days in a third project tree), and it demonstrated how the failure
compounds conversationally: an earlier strand on this pane was recovered
truncated, the agent had to ask the user which instruction he meant, and the
user's ANSWER to that question ("Notify me") stranded too -- on a locked pane,
every leg of the repair dialogue takes the loss-and-rescue detour. The user's
next follow-up eight minutes later ("can you also resend Stefan's expired
invite?") stranded as well, the pane's fifth: once locked, a pane strands
every keyboard message indefinitely, and only external recovery tooling keeps
the conversation moving at all.

By 14:06 on 2026-08-10 the day's ledger stood at 40 flush recoveries across
nine sessions on nine distinct panes -- among them a pane whose fresh
instruction ("continue with task 30"), typed two minutes after a clean turn
end, sat dead until the probe fed it: the shape strikes new work orders the
same as mid-exchange replies.

Between 14:01Z and 14:20Z the afternoon produced a fresh burst: strands on
four sessions' panes routed to four separate resolver slots within twenty
minutes (among them the nineteenth occurrence's pane twice), on an unloaded
machine -- the storm cadence of the previous night is now also a daytime
pattern.

By 15:58 an eleventh session had its first strand, and this specimen carries
a submit-path contrast: a programmatic injection (our tooling typing a
dictated message into the same pane's composer and submitting it) fed
normally at 13:54:37Z and the turn answered it; the user's hand-typed reply
one minute later queued dead. Same pane, same pty, sixty seconds apart --
delivery mechanics identical at the tmux layer, differing only in keystroke
timing and submit cadence.

The afternoon of 2026-08-10 added the sharpest consequence specimen, on the
thirteenth pane (28 ledgered flush recoveries on this one pane since
2026-08-05). The user's order to export a document and email it to a third
party stranded (detected 14:17:30Z); the pane's agent, treating the recovered
line as unverifiable, held the outbound send behind an explicit confirmation
card; the user's typed approval of that very send ("Yes, email it to Jasper,
his address is coming") then stranded too -- honest end_turn at 14:20:44Z,
Stop hooks and turn_duration stamped, no Escape, no interrupt, no API
death, transcript empty for eighteen minutes, probe delivery at 14:38:37Z,
head whole. Because recovered composer text cannot carry authorization, a
hand-typed approval on a locked pane can never bind: the user has no keyboard
route to authorize an external action at all, and every approval leg detours
through out-of-band UI at probe cadence.

Minutes later a pane with no strand history, in a project tree not previously
represented in the ledger, stranded its first two hand-typed messages -- a
100% keyboard loss rate from the pane's very first user keystroke. The agent
had asked where a notes file lived; the user's typed answer ("the notes file
is in the meeting notes folder now") was ring-rendered by 14:35:40Z at the
latest, while the pane's last turn ended honestly at 14:35:27Z (end_turn,
Stop hooks and turn_duration stamped, no Escape, no interrupt, no API
death) -- the submit either overlapped that turn's final seconds or landed
on the just-idled pane; either way no turn consumed it, the head never
appears in the transcript before its recovery banner, and the probe fed it
at 14:37:40Z. The agent verified the recovered claim and found the folder
empty; the user's typed correction ("the file should be there now, check
again") stranded identically and fed at 14:41:14Z -- the whole
claim-verify-reclaim exchange ran at probe cadence, every leg taking the
loss-and-rescue detour. Machine load stood at 24 on 10 cores in the window,
though earlier specimens fire on an unloaded machine as well. At this point
the recovery ledger's day stood at 58 flush recoveries across 14 sessions,
and 30 distinct sessions have ledgered at least one flush-class recovery
since 2026-08-05.

The same evening the sibling pane in that same new project tree stranded a
hand-typed message of its own -- the 31st distinct session in the recovery
ledger. The specimen carries a clean negative control on the "turn death"
framing: this pane HAD suffered a real API death hours earlier (18:25:22Z,
Connection closed mid-response, stop_sequence, turn_duration stamped
with no Stop hooks), yet the strand cannot descend from it -- two later
turns ended honestly and a door-fed delivery at 18:57:04Z fed normally,
which a ring-blocked composer would have refused. The typing window is
bounded to 18:57:29Z-19:03:01Z (last honest end_turn to the 120s
graduation bound); no turn started, and the head ("sent it, set up the
reply watch") was flushed at 19:05:01Z by the next passing delivery, whose
door found the sighting already graduated. The recovered claim failed
verification -- the draft it declared sent was still unsent -- so the agent
re-asked through out-of-band UI: on a stranding pane even the user's
send-state assertions arrive too stale to trust, and every outbound-send
leg detours again. Day total at that point: 63 flush recoveries across 16
sessions.

Between those two counts the evening also closed the twenty-first
occurrence's day-long arc (18:42:45Z): the user's RE-ENTRY of a previously
stranded and recovered decision answer, stranded again on the same pane
across a --resume process replacement, had been refused as presumed debris
by recovery-side dedup since morning and finally fed a day after his first
attempt -- the first specimen where the recovery tooling's own necessary
dedup became the delay, and the sharpest evidence that the retry loop on a
stranding pane is not survivable from outside the TUI.

Expected

Input that entered the prompt queue is fed to the next turn, or at minimum
remains visible in the composer if it cannot be.

{"type":"queue-operation","operation":"enqueue","timestamp":"T","content":"<the typed line>"}
{"type":"queue-operation","operation":"dequeue","timestamp":"T"}          // same millisecond
{"type":"system","subtype":"stop_hook_summary","timestamp":"T-minus","hookCount":4,
 "hookErrors":[], ...}                                                    // back-dated to the turn