[BUG] /goal set via Remote Control does not start the documented immediate turn; goal-driven autonomy silently stalls until a manual message arrives

Claude Code version: 2.1.202
Platform: macOS (Darwin 25.5.0), session driven via Remote Control from an iOS device
Session type: Remote Control (mobile), NOT the desktop/local terminal

Expected behavior

Per docs (https://code.claude.com/docs/en/goal):

"Setting a goal starts a turn immediately, with the condition itself as the directive. You don't need to send a separate prompt."

Actual behavior

/goal was set via Remote Control from an iPhone. The goal registered correctly (confirmed by Goal set: ... local-command-stdout in the session transcript, and the ◎ /goal active status), but no turn started. The session produced zero assistant turns, zero tool calls, and zero Stop-hook-driven continuation for 61 minutes, until I manually sent a new message asking why nothing was happening — at which point the session responded normally and immediately (turn started within ~30s of my message, as expected).

This rules out a fully-hung/frozen TUI input loop (unlike #51267, which I initially suspected): the session was NOT unresponsive to remote input in general — an ordinary new message got a normal, prompt response. Only the goal-triggered "start a turn immediately" behavior failed to fire. iOS has no Escape key, so any theory relying on a local-keystroke recovery mechanism doesn't apply here — recovery was a completely ordinary remote chat message.

Repro / evidence (from session .jsonl transcript)

• 22:42:45.400Z — /goal keep benchmarking and iterating on improvements until you've exhausted all reasonable options... registered (Goal set: ... system event present in transcript).
• 22:42:45.400Z → 23:43:52.674Z (61 min) — no assistant events of any kind in the transcript (no text, no tool_use, no tool_result, no queue-operation, no Stop hook feedback attachment). Complete silence.
• 23:43:52.674Z — user sends an ordinary follow-up message ("what are you doing towards this goal?!?") over the same Remote Control channel.
• 23:44:22.167Z — assistant responds normally, ~30s later, business as usual (this is a normal turn-start latency, not a "just unstuck from a hang" latency).

Suspected mechanism

/goal is documented as "a wrapper around a session-scoped prompt-based Stop hook" that also kicks off an immediate turn at set-time. The immediate-turn-start path may not be reliably delivered/executed when the /goal command itself is issued through the Remote Control channel — as if the "start a turn now" side-effect of the command got dropped while the command's other effects (registering the goal condition, showing Goal set: ... in the local-command-stdout) still landed normally. The Stop-hook-based continuation-after-each-turn path also never fired, because no turn ever started to trigger it.

Impact

A goal set from a mobile Remote Control session can silently do nothing for an indefinite period with zero visible indication of a problem — no error, no stalled-turn indicator, nothing distinguishing "working autonomously" from "not working at all" until the user manually checks in. For an unattended/overnight autonomous-work use case (the documented primary use case for /goal), this is a serious reliability gap specific to Remote Control.

Suggested fix / mitigation

• Ensure the "start a turn immediately" side-effect of /goal is confirmed-delivered (e.g., ack'd) over the Remote Control channel, not fire-and-forget.
• Surface a visible warning/indicator if a goal has been active for N minutes with zero turns evaluated — the ◎ /goal active indicator should distinguish "actively working" from "armed but stalled."