fix(prompts): blocking terminal prompt has no answer affordance on some agent CLIs

[RonenMars]

What happened

Observed live on hardware (Android, Xiaomi 2109119DG) during E2EE program G-2 device testing, 2026-09-04, reproduced independently on two different agent providers.

When a session's underlying agent process (claude or codex) opens with a plain terminal select-menu prompt — e.g. Claude Code's own "Select login method" picker, or Codex's "Sign in with ChatGPT / Device Code / API key" picker — the app correctly detects that a prompt is open and blocks free-text input with:

A prompt is waiting for an answer; answer or dismiss it before sending text

But no answer affordance is ever surfaced: no prompt card, no tappable options, the "Live control" tab is not clickable, and tapping the terminal output area does not reveal an arrow-key/keyboard toolbar. The composer stays permanently locked with no way to answer the detected prompt, other than killing the session.

Reproduction

1. Pair to any streamer, open a project, start a session using an agent binary whose first-run flow shows a plain terminal 1. Option A / 2. Option B / 3. Option C style select menu (Claude Code's login-method picker or Codex's sign-in picker both trigger it).
2. Observe the app enters "Waiting" state and the composer is blocked with the "A prompt is waiting for an answer" message.
3. Try: tapping "Live control" tab (not clickable), tapping the "N prompts" badge in the header, tapping directly on the numbered option text in the terminal output, tapping into the terminal pane itself. None surface an answer UI.
4. Only recourse observed: kill the session and start a new one (which, if it hits the same picker, repeats the dead end).

Why this matters

Any agent that asks an ordinary terminal question this way — not just first-run login pickers — hits this dead end. It happened identically on two different agent providers (Claude, Codex), so it's not provider-specific; it's the mobile client's prompt-detection/answer-affordance logic.

Suggested investigation starting points

• Wherever the client's prompt/pending-question detector decides a prompt is "open" and blocks the composer — find out why it doesn't also recognize this shape of prompt (a plain numbered select-menu with no structured question/permission schema from the server) as something needing a rendered answer UI.
• Check whether the detector only renders an answer card for prompts carrying a structured questions/options payload from the server-side prompt registry, and falls back to "just refuse text, offer nothing" for anything else it flags as prompt-like (e.g. text matching \d+\.\s menu patterns) — that would explain the total absence of an affordance rather than a broken one.
• A minimal fix might be: if no structured answer UI can be rendered for a detected prompt, still expose a raw-keystroke/arrow-key fallback (not just Escape) so the user can navigate a plain terminal menu, rather than leaving the composer in a dead end with zero paths forward.

Related

• Not the same as fix(ios): reconcile app.json and Info.plist permission strings #724 (detector re-minting an open prompt after an answer) or fix(android): deny cleartext to numeric host forms the resolver reads as public #757 (map entry outliving its registry record) — this is about a prompt that IS genuinely open, correctly detected, but has no rendered way to answer it at all.
• A related, worse-case failure (an answered prompt still permanently blocking text) was also reproduced in the same session — see separate issue.

[RonenMars]

Verified against origin/main at d4b37c8 on 2026-09-06.

Three things have changed since this was filed on 2026-09-04, and they pull in different directions — worth separating before anyone retests.

The raw-keystroke fallback this issue asks for now exists.
RemoteKeyboardControls is wired at app/session/[id].tsx:1148, opened via openRawKeyboard at :612.
It is gated on the server advertising the capability — serverInfo?.rawKeys === true at :526 — and says so explicitly rather than failing silently (terminal:rawKeyboard.unavailableBody at :614).
So against a streamer new enough to advertise it, the dead end described here should now have a way out.
One caveat: it passes promptId only when activeQuestion?.source === 'prompt' (:1149, :1155), and a plain terminal menu carries no structured prompt, so that path sends keys without one.

A second, unrelated mechanism produced this exact symptom, and it is fixed.
useActiveQuestion resolved the WS client once at effect time, so on a cold start it bound no listeners at all and never rebound — while the streamer was correctly unicasting the card back on subscribe_session.
A structured card was therefore emitted and dropped on arrival, which looks identical to "no affordance was ever offered".
Fixed in #992.
A retest that predates that build cannot distinguish the two causes.

The core claim here still stands, though, and should not be closed as fixed.
The login pickers named above emit no structured card at all, so there is nothing for either fix to deliver.
There is no detector for a sign-in or login screen anywhere in threadbase-streamer/src/services/questions/, and Claude's detectGateScreen requires a gate footer — GATE_FOOTER_RE = /esc to cancel/i at detectPermissionGate.ts:233 — which a login picker does not print.
Codex's detectors are similarly specific to its trust and hooks gates.

So: the fallback affordance has landed, one confounding client-side bug is gone, and the underlying "no structured card for an ordinary numbered menu" gap is untouched.