Remote Control message paints in idle CLI composer but never starts a turn

Summary

With Remote Control attached to an otherwise idle Claude Code CLI, a submitted message can be painted as dim text in the local composer but never start a turn. The message has no corresponding transcript user row or queue-operation row. The session remains idle until somebody returns to the local terminal and cancels/retypes the prompt.

This still reproduces after #78177 was closed as stale; that issue's closing automation asks affected users to open a new issue when the problem remains relevant.

Environment

• macOS
• Claude Code runtime recorded by the transcript: 2.1.267
• Remote Control client: claude.ai/code from another device
• The CLI was idle after a completed turn

Timestamped evidence

The prior assistant response ended at 2026-09-10T21:38:01.662Z.

Both configured Stop hooks then completed normally:

• 21:38:02.014Z: first hook returned {"continue":true}
• 21:38:02.195Z: second hook returned {}
• 21:38:02.199Z: Stop summary recorded preventedContinuation:false

At 21:38:03.640Z, 1.44 seconds after that clean Stop, the PTY output painted the remote message as dim composer text (build the F-831 control). There was no matching PTY input record, transcript user row, or transcript queue-operation row, and no turn began.

As a positive control under the same hook configuration, a message delivered while a turn was active produced a transcript queue-operation enqueue at 21:47:05.062Z, was removed with reason absorbed_mid_turn at 21:47:17.234Z, and the assistant explicitly followed it in that same turn. That successful path took 12.172 seconds and shows the hooks themselves do not prevent Remote Control delivery.

Expected behavior

A Remote Control message submitted to an idle CLI should become a user turn without requiring local terminal input.

Actual behavior

The text is visible only in the terminal composer. It is not model input and does not begin a turn. Remote users receive no delivery failure, while local UI output is the only evidence that anything is pending.

Workaround

Return to the local terminal, press Escape, and retype the prompt. This defeats unattended Remote Control use.

Related: #78177 and the broader input-stall report #51267.