Mailbox deadlocks on Claude Code's suggestion prefill, and the stuck-message alert names a remedy that cannot clear it

[pseudoseed]

A message to a builder holds with reason busy and never delivers, because the agent left text in its own composer. The gate is correct. Nothing clears the text, so the wait never ends.

Hit five times on 2026-08-21, each needing manual intervention. mailbox currently records 16 dismissed/busy rows, nearly all from clearing these by hand.

Mechanism

After a turn ends, Claude Code leaves a suggested next action sitting in the composer, e.g.

spawn a real opencode builder and send it a message
keep it, re-request the gate
Retry the deactivate call

Verified by reading the terminal buffer directly via GET /api/terminals/<id>/output on five separate occasions.

classifyBuffer sees a non-empty composer and returns not-clean. Correct: injecting there would corrupt the agent input. But:

• the agent will not clear its own composer, it is idle and waiting
• the gate will not deliver until it is clear
• nothing else touches it

Deadlock. The message sits until a human intervenes.

The alert names the wrong remedy

The stuck-mailbox notification says:

Remedy: run afx inbox to inspect; afx interrupt builder-x clears a stuck composer.

afx interrupt sends ESC. ESC does not clear typed text in the composer. Running it changes nothing and the alert fires again three minutes later.

What actually works is afx send <id> --interrupt, which sends Ctrl+C first and clears the line. That is documented as a way to send a message, not as the remedy for this state, so nobody finds it.

Worse, afx interrupt defaults to ESC followed by Enter. When the composer holds a selection dialog rather than free text, that Enter selects the highlighted option. On 2026-08-21 the highlighted option was Retry the deactivate call, which would have deactivated the whole workspace and killed the architect session. ESC dismissed the dialog first, so the Enter landed harmlessly, but that was ordering luck.

Fix

1. Correct the alert. Name afx send --interrupt, not afx interrupt. This alone removes most of the pain.
2. Make the hold recoverable. A message held on busy for N minutes against an otherwise idle agent should either clear the composer itself, or escalate with the working command. A hold that can never resolve on its own is not a hold, it is a drop.
3. Distinguish idle-with-prefill from genuinely busy. They are the same busy reason today. The first is safe to clear, the second is not. The render gate already knows the screen; it can tell an idle composer holding text from an agent mid-turn.
4. afx interrupt should not send Enter by default, or should refuse when the screen shows a selection dialog. Sending Enter at an unknown dialog is a destructive act chosen by whatever happens to be highlighted.

Note

This is not the render gate being wrong. It is right every time. The gap is that nothing owns clearing a prompt the agent abandoned, and the documented escape does not work.

[pseudoseed]

Confirmed cause, and a working mitigation

The repo owner disabled Claude Code suggested replies via /config. The deadlock stopped completely, in both directions.

That confirms the mechanism reported above: the composer holds text the agent did not type and will not clear, the gate correctly refuses to type over it, and nothing owns clearing it.

Deprioritised, not fixed. The mitigation is enough for now.

What the mitigation does not cover

1. It is a per-user client setting, not a property of this system. It protects one machine. A new machine, a reset preference, or a Claude Code default change reintroduces it with no warning and no obvious link back to this issue.

2. Suggested replies are one source of prefill, not the only one. Any text left in a composer produces the same deadlock: a dialog, a partially typed message, a paste. The mechanism is untouched.

3. The alert is still wrong regardless. It says:

   Remedy: run afx interrupt <id> clears a stuck composer.

   afx interrupt sends ESC, which does not clear typed text. afx send <id> --interrupt sends Ctrl+C and does. That is a documentation defect independent of prefill, and it costs a person time every occurrence. Worth fixing on its own even while the rest waits.

Direction nobody had considered

Originally reported as a builder unable to receive. It also happens architect-side: on 2026-08-21 builder pir-13 sent three reports that sat 25 minutes because the ARCHITECT composer was busy. From the owner side that looked like a hung builder. It was not — the builder was idle and waiting, correctly, since writing a PTY directly is what this design forbids.

The builder own note is the useful design input: it could not tell whether busy meant working or wedged, so it checked Tower read-only to confirm something was alive to receive. A held message is only safe if a recipient exists. If the alert grows a builder-side direction, that liveness check is the piece worth building in.

Suggested reduced scope

Fix item 1 from the original list only — correct the alert to name afx send --interrupt. Leave the rest until the mitigation stops holding.

[pseudoseed]

Items 1 and 3 shipped in #91.

Item 3 — migration v20 records the gate's detail on the held row, so user-text (an abandoned draft, safe to clear) is no longer the same word as busy-indicator (a live turn, must not be touched). afx inbox shows it in place of the bare reason; afx inbox show renders it as Gate saw, with — (not recorded) for rows held before the migration.

Item 1 — the remedy is now chosen by that detail:

• user-text → afx send <id> --interrupt "<message>", with an explicit note that afx interrupt sends ESC and does not clear typed text
• busy-indicator → wait; do not clear a live turn
• anything else → the gate could not read a ready prompt, which is a screen problem, not a leftover draft

Corrected in the starvation notice, in the afx status escalation lines, and in afx inbox itself where it is actually read.

Items 2 and 4 are split out because each needs a decision rather than a fix:

• A mailbox hold on an abandoned composer can never resolve on its own #92 — a hold on an abandoned composer can never resolve on its own
• afx interrupt sends Enter by default, which selects whatever a dialog has highlighted #93 — afx interrupt sends Enter by default, which selects whatever a dialog has highlighted