Mobile-bridge answer silently dropped (no queue-op, no tool_result) when a Stop-hook-triggered turn supersedes the state being answered

Open 💬 1 comment Opened Jul 13, 2026 by woodfordintegrations-collab

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 bridgeSessionId for 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)

  1. Assistant turn ends with stop_reason: end_turn — its text posed 4 questions in prose (no pending tool call).
  2. 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).
  3. 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-operation enqueue, no tool_result, nothing. The submission is lost with no error shown that the user noticed, and no artifact locally.
  4. Minutes later the user retypes the same content as a plain message — it arrives fine (recorded as queue-operation enqueue 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.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗