fix(prompts): answering a prompt via its card can still leave text permanently refused

[RonenMars]

What happened

Observed live on hardware (Android, Xiaomi 2109119DG) during E2EE program G-2 device testing, 2026-09-04. This is a worse-case variant of #953: this time the app DID render a proper answer card for a detected prompt (a "=== 120 markers emitted; type anything and press Enter ===" banner from a test harness was rendered as a structured APPROVAL card with a tappable "Continue" option), and the user tapped it correctly.

After tapping Continue:

• The card disappeared.
• The banner text above it changed to: "That question isn't open anymore."
• But the composer stayed permanently blocked, still showing: "A prompt is waiting for an answer; answer or dismiss it before sending text."

The prompt is simultaneously reported as answered/gone ("isn't open anymore") and as still blocking input. There is no further affordance — no way to clear this state from the client short of killing the session and starting a new one.

Why this is worse than #953

In #953, the user never had an affordance to try, so the dead end is at least discoverable immediately. Here, the user did exactly the right thing — answered the prompt through the UI the app itself presented — and ended up in a permanently locked state anyway. This is very likely the mobile-client-side manifestation of the same class of bug fixed server-side in streamer #757 (fix(sessions): refuse input on the prompt registry's live state, not map membership, RonenMars/threadbase-streamer): a client-side "is a prompt open" flag that isn't cleared correctly when the answer completes / when the server-side prompt record transitions to a terminal state via a route the client's local gate-clearing logic doesn't recognize.

Reproduction

1. Trigger any prompt that renders a structured approval/question card in the app (permission gate, question gate, or — as observed — a plain terminal banner that some detection heuristic classified as prompt-shaped).
2. Tap the card's answer option (e.g. "Continue").
3. Observe: card disappears, message updates to "That question isn't open anymore," but the composer remains locked with "A prompt is waiting for an answer."
4. Attempt to type/send text: refused.
5. Only recourse: kill the session.

Suggested investigation starting points

• Find the client-side state (likely a boolean/flag mirroring "is there a pending prompt for this session") that gates the composer's text-send action, and check whether it's cleared on the SAME event that produces the "isn't open anymore" message, or on a different one — a race/desync between those two would explain exactly this symptom (one part of the UI thinks it's closed, another part thinks it's still open).
• Cross-reference with streamer fix(android): deny cleartext to numeric host forms the resolver reads as public #757's root cause: a server-side map entry (pendingPermission/pendingQuestions) could outlive the prompt registry record when a prompt closed via a route other than the normal answer/expiry paths — check if the mobile client has an analogous local cache (e.g. a per-session "openPromptId" or similar) that isn't cleared by every route that can close a prompt server-side, only by the ones the client currently recognizes.
• Confirm whether the client's composer-block flag is keyed off a specific promptId that becomes stale, similar to the server-side bug's shape, or off a simpler open/closed boolean that just isn't reset.

Related

• Companion issue: fix(prompts): blocking terminal prompt has no answer affordance on some agent CLIs #953 (same class — a blocking prompt with input dead-ended — but there the user never gets an affordance at all).
• Server-side analog, already fixed: fix(sessions): refuse input on the prompt registry's live state, not map membership (streamer fix(android): deny cleartext to numeric host forms the resolver reads as public #757, RonenMars/threadbase-streamer, commit 8864ae93) — worth reading that fix's diff for the shape of the underlying defect class before designing the mobile-side fix.

[RonenMars]

Status: partly addressed; the reported lockout is fixed on the streamer side in RonenMars/threadbase-streamer#851, which has not merged yet.

Verified on 2026-09-10.
The composer text "A prompt is waiting for an answer" is the streamer's 409 response from /input, not a client-side flag.
The reported card came from the streamer's shell-prompt detector: the banner ends in "press Enter", which produces a single "Continue" option.
Every answer route checked that gate with the Claude-box scraper, which can never see a shell prompt, so on the Claude provider tapping Continue could never write Enter.
The failed check marked the prompt cancelled without deleting the pending entry that /input reads, which left text refused with no card on screen.
An offline run of the streamer's own detectors, against the G-2 plain-control screen plus the reported banner, reproduces the exact card; the row1 capture itself is sealed, so the precise repro screen could not be recovered.

Fixes:

• P1: shell-prompt cards can never be answered on the Claude provider threadbase-streamer#850 makes the answer check accept shell-prompt gates, so Continue writes Enter while the prompt is on screen.
• P1: a stale permission entry keeps /input refusing text after its prompt is gone threadbase-streamer#849 clears the stale entry when no gate is painted.
• Both land in fix(sessions): close four prompt-lifecycle holes threadbase-streamer#851.
• fix(session): fetch the live gate when a permission answer is rejected #1033 fixes the client side for the legacy /permission/answer route, used by streamers that predate the prompt contract: it no longer drops the card on gate_mismatch or unknown_option, and fetches the live gate instead.

Remaining: this issue stays open until RonenMars/threadbase-streamer#851 is merged and released.

[RonenMars]

Completed.
The reported lockout is fixed in the streamer, released in v1.89.5 (https://github.com/RonenMars/threadbase-streamer/releases/tag/v1.89.5) via RonenMars/threadbase-streamer#851, squash commit 33e1c4ba.
RonenMars/threadbase-streamer#850 makes the answer check accept shell-prompt gates, so tapping Continue writes Enter while the prompt is on screen.
RonenMars/threadbase-streamer#849 clears the stale pending entry when no gate is painted, so /input stops refusing text once the prompt is gone.
The client side for the legacy /permission/answer route landed on main in #1033 (5673336).