Feature request: Cancel/interrupt button for Remote Control (mobile)

Status Fixed / completed
Maintainer reply None cached
Activity 10 comments · opened Apr 12, 2026 · closed Aug 17, 2026

Summary

When using Claude Code via Remote Control mode from a mobile browser (claude.ai), there is no way to cancel or interrupt a running tool (e.g., WebFetch, Bash) that hangs or takes too long.

On desktop, Ctrl+C works. On mobile, the only options are waiting for a timeout or killing the process from another terminal — neither is practical.

Use case

  • WebFetch hangs on large pages (e.g., Wikipedia 400KB+) with no timeout mechanism
  • Long-running Bash commands that unexpectedly stall
  • Any tool that blocks the session without a way to recover from mobile

Proposed solution

Add a Cancel / Stop button in the Remote Control UI (claude.ai web interface) that sends an interrupt signal equivalent to Ctrl+C on the desktop app.

Current workaround

  • PreToolUse hooks to block known problematic tools (e.g., WebFetch)
  • Using curl --max-time or timeout wrappers instead of built-in tools
  • These are preventive only — no recovery option exists once a tool hangs

Environment

  • Claude Code Desktop App on Windows 11
  • Remote Control from mobile browser (iOS/Android)

View original on GitHub ↗

9 Comments

github-actions[bot] · 4 months ago

Found 3 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/45330
  2. https://github.com/anthropics/claude-code/issues/41503
  3. https://github.com/anthropics/claude-code/issues/45445

This issue will be automatically closed as a duplicate in 3 days.

  • If your issue is a duplicate, please close it and 👍 the existing issue instead
  • To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

yasumorishima · 4 months ago

This is not a duplicate of the suggested issues:

  • #45330: UI freeze on deny action — different trigger, not about cancellation
  • #41503: Usage limit prompt stuck — specific to billing prompts, not tool execution
  • #45445: Bash tool hangs on specific command — about a specific bug, not a missing UI feature

This issue requests a Cancel/Stop button in the Remote Control web UI so mobile users can interrupt any hanging tool (WebFetch, Bash, etc.), equivalent to Ctrl+C on desktop. None of the linked issues address this feature gap.

GustavoVzla · 4 months ago

+1 — reinforcing this feature request with a slightly different angle.

My pain point isn't just "I can't cancel a hung WebFetch/Bash" — it's far worse than that. My Remote Control sessions on mobile consistently get stuck mid-execution even on normal workflows (no known-slow tools), and the only recovery is pressing Esc locally when I return home.

Actual usage pattern (solo founder, on-the-go)

  1. Start a Claude Code session on my laptop (VSCode terminal) before leaving the house
  2. Connect via Remote Control from mobile while commuting / at meetings
  3. First 2-4 messages work flawlessly — I read replies, send follow-ups, review plans
  4. At some point during a routine tool call (file edit, MCP call, Bash command — nothing unusual), the session just stops responding on mobile
  5. I send messages → they appear queued but the session never advances
  6. I try sending /clear, random text, reconnecting Remote Control → nothing works
  7. I have to wait until I physically return to the laptop and press Esc — then the session immediately wakes up and continues as if nothing happened

Why this kills the product value of Remote Control

Remote Control is marketed/advertised as "work from anywhere with your Claude Code sessions." In practice, for me it means:

  • I can start something from mobile, but I cannot reliably finish it away from my laptop
  • When something urgent breaks during the day (client issues, production bugs, deploys), I genuinely cannot resolve it remotely — I have to drop what I'm doing and physically go home
  • This defeats the entire purpose of the mobile experience

Yesterday I spent hours with two sessions stuck while I was out. When I got home at night, Esc on each terminal revived both sessions in 1 second. Hours of lost productivity for something that's a one-keystroke fix — but that keystroke must be local.

The ask — more than just a Cancel button

The Cancel/Stop button in #47127 would help, but the deeper issue is:

  1. State sync bug: the CLI process enters a state where it stops responding to Remote Control messages, but Esc locally unsticks it. This suggests the input pipe from Remote Control to the CLI has a failure mode (maybe buffer full, maybe event loop paused) that the mobile client can't recover from.
  2. No remote unstick mechanism: even if we can't get full Ctrl+C, we need any way from mobile to send an equivalent of "wake up the local process" or "abort current input state."

Suggested minimum viable fix

  • A "Force wake session" button on Remote Control mobile that sends whatever low-level signal Esc sends locally
  • OR automatic heartbeat detection: if the CLI hasn't processed a Remote Control message within N seconds of receiving it, reset the input state automatically
  • OR a visible state indicator on mobile ("Session responsive" / "Session frozen — needs local unstick") so users know immediately instead of wasting minutes assuming it's loading

Environment

  • Claude Code 2.1.112+ on Windows 11 (VSCode terminal)
  • Remote Control from mobile browser (claude.ai/code) on Android
  • Happens with various tools (MCP calls, Bash, Write) — not tied to a specific slow tool
  • Multiple sessions, multiple projects — pattern is consistent

Related but distinct from #28508 (which is about AskUserQuestion replies from mobile not propagating).

alex-rosenberg35 · 4 months ago

I keep running into this or a similar issue. Whenever a tool or subprocess gets stuck for any reason, the entire session becomes blocked with no way to rescue it remotely. This is a massive blocker for effective use of remote-control.

Zmeos · 4 months ago

Reinforcing this. There is indeed another issue causing the hangs. But adding this, would reduce any cause of hanging from a full day block (if out for the whole day), to a minor nuisance.

sfo2001 · 4 months ago

Also, reinforcing this. As a work around, I have started multiple "spare" sessions. However, I am on a two days business trip and now my spare sessions are one by one also hanging.

mattainge · 3 months ago

I back this. I have to use the Windows app just to MSTSC from my mobile device to my desktop and press ESC. There's no way that isn't feasible from the remote control system. It's a _fantastic_ facility let down by this one issue - cos tool use gets Claude code stuck often. Almost every hour.

aaronzhle · 3 months ago

Me too

Snailflyer · 3 months ago

This thread matches the distinction I keep running into: the hard part is not a mobile terminal UI, it is a recovery/control surface for the same live process when the normal chat/tool path is blocked.

For a first-class Remote Control fix, I think Cancel/Stop should be modeled separately from normal chat input. If WebFetch/Bash/MCP is hung, the user needs an out-of-band interrupt path that still works when the session is not accepting ordinary messages. Mapping that to the same effect as local Esc/Ctrl-C would cover a lot of the real-world failure cases described here.

For people who are okay with a self-hosted workaround while the official Remote Control path matures, I built a small open-source project in this narrower direction: https://github.com/Snailflyer/faryo

It keeps Claude Code/Codex/shell inside tmux as the live session layer, and uses a phone/desktop browser workbench for output review, short follow-ups, approval/interruption, and handoff into the same session. It is not a remote desktop and not a replacement for Claude Remote Control; the mature path today is Linux + tmux + CLI agent + mobile browser/PWA. Sharing it here because this issue is exactly the class of workflow gap it is meant to explore.

Showing cached comments. Read the full discussion on GitHub ↗