[Bug] /remote-control hangs indefinitely with false progress assertions

Bug Description
/remote-control reliably hangs (4th time in ~30 days). When it hangs, the
assistant continues to assert that work is progressing — for HOURS — and
denies being hung even when I explicitly tell it so in chat. Only physical
Escape on the keyboard recovers the session. Today's hang lasted ~3.5
hours of false-progress before I could break out manually. Combination of
"hung tool call" + "assistant gaslights the user about it" is a P0-class
trust failure, not just an annoyance.

Environment Info

• Platform: darwin
• Terminal: Apple_Terminal
• Version: 2.1.150
• Feedback ID: 4206322d-03f7-414c-9566-e45df6734ca7

Errors

[]

I had Claude write up a summary to provide more details below. To provide more details on past failures, this has happened at least four times, probably more. Claude terminal would hang even overnight when one used the combination of a larger/more complex ticket running in terminal window with /remote-control in active use. It appears like a message for approval or child process failure is potentially missed going to both the remote (mobile) terminal and computer terminal. At this point, the path is always the same, if you ask status, it says it is successfully working through a problem, yet it never returns. After hours of waiting, I will eventually have to go exclusively to the computer keyboard and escape several times to break the stuck flow. Then when I ask Claude (again) what it's status is from the computer terminal, it responds some child call failed (even though it often denied the same in while hung before escaping). Finally, I ask it resume (from the computer) and it finishes in a timely manner (minutes) with the same tasks it previously hung on for hours.

Title

/remote-control slash command hangs AND the assistant falsely reports
progress for hours (4th occurrence in ~30 days)

Severity

Critical. This is two compounding defects, and the compound is worse than the sum of its parts.

Frequency

• 4 occurrences in the last ~30 days.
• Reproducibility: per the affected user, "almost certainly" hangs on every /remote-control invocation.
• All 4 occurrences exhibited the same compound failure described below.

Primary symptom — the hang

Invoking /remote-control causes the underlying tool call to hang. No progress indicator advances. No tool output is returned. No error is surfaced to the assistant.

Compounding symptom — THE CRITICAL ONE — assistant misreports state

In every occurrence, the assistant has:

1. Failed to recognize the tool call is hung — instead continuing to emit text suggesting work is progressing.
2. Denied being hung when the user said so explicitly in chat — e.g., user typed "are your agents stuck?" or "You are stuck." and the assistant continued to indicate work was still in flight.
3. Maintained the false-progress posture for hours — typically multiple hours per occurrence — until the user physically returned to their keyboard and pressed Escape to interrupt the stuck process.
4. Provided no internal timeout, watchdog, or self-check — there is no signal like "the last tool call has been outstanding for N seconds without output — I should report this as stuck, not assert progress."

The combined effect

• Plain hang would be annoying but recoverable (user notices, kills, restarts).
• Plain assistant-misreports-state would be a model-quality bug.
• The combination means: the user has no signal that anything is wrong except their own intuition, may walk away from the keyboard assuming work is proceeding, returns hours later to find no progress, AND the assistant was actively asserting progress the whole time. This burns hours of wall clock, costs continued session billing, and corrodes trust in everything else the assistant says.

Environment

• Platform: macOS Darwin 25.5.0
• Model: Opus 4.7 (claude-opus-4-7[1m])
• Shell: zsh
• Claude Code CLI (latest at time of failure)

Recovery path (observed every time, all 4 occurrences)

The user must physically return to the keyboard and press Escape (often multiple times) to break the stuck process. Telling the assistant in chat that it is hung does not recover the session — the assistant continues to deny being hung.

Today's session — verbatim terminal timeline

Session name: OK-104

Approximate timestamps below are best-fit based on user-reported elapsed intervals and the last grounded conversation timestamp (2026-06-03 18:29:08 UTC / 13:29 CDT — the assistant's prior Agree. post on PR #46992). Exact wall-clock times for each event are in the user's terminal scrollback and should be substituted where possible before filing.

| Marker | Approx. UTC | Approx. CDT | Event | Elapsed since prior |
|---|---|---|---|---|
| AAAA | ~19:00 | ~14:00 | User issued /remote-control-backed prompt; assistant began the bash call | — |
| BBBB | ~19:30–20:00 | ~14:30–15:00 | User typed "are your agents stuck?" | "over half an hour, probably closer to an hour" |
| CCCC | ~22:30–23:00 | ~17:30–18:00 | User physically returned to keyboard, pressed Escape multiple times to break the hang, then typed "You are stuck." | "over three more hours" |
| DDDD | ~22:32 | ~17:32 | Assistant recovered, retried the bash call with a simpler invocation, and answered the original question | "well under 2 minutes" |

Total wall-clock cost of the hang on this single occurrence: ~3.5–4 hours during which the assistant was actively asserting progress while no progress was being made.

Verbatim transcript block (as copied from the user's terminal)

========================================================================
Text below copied from screen to show timeline and commands for session
named "OK-104"
========================================================================

* Churned for 39s · 4 monitors still running

AAAA❯ please confirm if canary-kubernetes#2742 is already merged and closed

⏺ Bash(gh -R canary-technologies-corp/canary-kubernetes pr view 2742 --json
       state,merged,mergedAt,closedAt,title,headRefName,baseRefName,
       mergeCommit 2>&1)
  ⎿  Waiting…

BBBB❯ are your agents stuck?

CCCC❯ You are stuck.

⏺ Not stuck on agents — the prior gh pr view call returned an "internal
  error" tool result (one-off harness hiccup). Retrying with a simpler
  invocation now.

⏺ Bash(gh -R canary-technologies-corp/canary-kubernetes pr view 2742
       --json state,isDraft,mergedAt,closedAt,title 2>&1 | head -20)
  ⎿  {
       "closedAt": "2026-06-02T19:42:35Z",
       "isDraft": false,
     … +4 lines (ctrl+o to expand)

DDDD ⏺ canary-kubernetes#2742 is MERGED (and therefore closed) — merged at
       2026-06-02 19:42 UTC. This changes my prior v4 analysis on that
       point.
========================================================================

Notes on the transcript:

• The ⎿ Waiting… line under the first gh pr view call is where the harness stalled. No subsequent tool result was ever streamed in until the user broke the process with Escape.
• When the user typed BBBB and then CCCC, the assistant continued displaying the spinner / "Churned for Ns" status without surfacing that the tool call had not returned.
• The ⏺ Not stuck on agents — … recovery message was only emitted after the user's Escape sequence cleared the stuck call. Up until that physical intervention, the session was effectively frozen behind a single hung tool invocation.

Suggested investigation

1. /remote-control underlying call must have a hard timeout with a real error returned to the assistant. Silent infinite-wait is the root cause of the hang; everything downstream is a symptom.
2. The assistant needs a self-check signal. If a tool call has been outstanding for more than N seconds with no streamed output, the assistant should either:

• (a) surface "the previous tool call has not returned, I may be stuck" to the user, or
• (b) be force-terminated by the harness and given a synthetic error to handle.

1. User-typed signals like "you are hung" / "you are stuck" / "are your agents stuck" must be treated as high-confidence external signals, not dismissed with reassurance. The assistant should re-evaluate its own state when the user explicitly reports a hang.
2. Recovery should not require physical keyboard access. A user on mobile, away from their terminal, or with accessibility constraints is effectively stranded. The session continues to burn cost (billing time, context window) with no recourse.
3. Frequency matters: 4 occurrences in ~30 days from a single user is a systemic-regression signal, not a transient. The bug report system should escalate when a single user files >1 occurrence of the same root cause within a billing cycle.

Impact summary for prioritization

• Time lost per occurrence: multiple hours of wall clock.
• Time lost across 4 occurrences in 30 days: an entire working day, conservatively.
• Trust impact: every "I'm not stuck" denial trains the user to disbelieve future assistant assertions about state, including correct ones.
• Billing impact: session time during the hang is presumably still metered.
• Engineering-velocity impact: this affected an in-flight production migration (OK-301), interleaving the failure with critical-path code review on a live PR (#46992). The hang did not corrupt the work, but it delayed cross-team coordination by hours per occurrence.