Mobile-bridge answer silently dropped (no queue-op, no tool_result) when a Stop-hook-triggered turn supersedes the state being answered
Summary
An answer submitted from the claude.ai mobile app (bridged session / remote control) was silently dropped — it produced zero trace in the local session transcript (no queue-operation, no tool_result, no bridge-session rotation). The loss window coincided with a Stop-hook-triggered turn superseding the state the user was responding to. The user had to retype the content, which then arrived normally.
Environment
- Claude Code 2.1.207, macOS 26.5
- Session running in the terminal, continued live on the phone via the claude.ai bridge (single
bridgeSessionIdfor the whole session — no rotation) - A Stop hook was configured that emitted output on stop (this re-invokes the model with no human input)
Sequence (reconstructed from the transcript JSONL)
- Assistant turn ends with
stop_reason: end_turn— its text posed 4 questions in prose (no pending tool call). - The Stop hook fires the same second; its output re-invokes the model. This unattended turn runs, writes files, and ends by calling
AskUserQuestion(a different question). - The user, on the phone app, composed and submitted answers to the 4 prose questions from step 1. Nothing arrives client→CLI: the transcript records no
queue-operationenqueue, no tool_result, nothing. The submission is lost with no error shown that the user noticed, and no artifact locally. - Minutes later the user retypes the same content as a plain message — it arrives fine (recorded as
queue-operationenqueue and consumed mid-turn).
Expected
Any submission from the mobile bridge should either (a) be delivered (as the pending AUQ's answer or as a queued user message), or (b) be explicitly rejected client-side so the user knows to resend. Silent loss with no local artifact makes the failure look like the model ignored the user.
Notes / adjacent observation
- A pending AskUserQuestion correctly holds the turn open: elsewhere in the same session an AUQ sat unanswered for 22 minutes and the Stop hook never fired during it. The vulnerable state is a turn that ends without a pending tool call while the user is composing on the mobile bridge and a hook-triggered turn advances the session underneath them.
- Timing is racy by nature (user composing on phone vs hook re-invocation), so a deterministic repro is hard; conditions above reproduce the window: Stop hook that emits output + prose questions at turn end + user responding from the bridged mobile app during the hook turn.
Impact
Sessions that combine Stop hooks with mobile-bridge use can silently lose user input. Workaround we've adopted: always collect awaited input via a pending AskUserQuestion (which blocks the Stop hook) instead of ending a turn on prose questions.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗