Feature request: Cancel/interrupt button for Remote Control (mobile)
Status Fixed / completed
Maintainer reply None cached
Workaround ✓ Mentioned in thread ↓
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-timeortimeoutwrappers 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)
Showing cached comments. Read the full discussion on GitHub ↗
9 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
This is not a duplicate of the suggested issues:
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+Con desktop. None of the linked issues address this feature gap.+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
Esclocally when I return home.Actual usage pattern (solo founder, on-the-go)
/clear, random text, reconnecting Remote Control → nothing worksEsc— then the session immediately wakes up and continues as if nothing happenedWhy 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:
Yesterday I spent hours with two sessions stuck while I was out. When I got home at night,
Escon 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:
Esclocally 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.Suggested minimum viable fix
Escsends locallyEnvironment
Related but distinct from #28508 (which is about
AskUserQuestionreplies from mobile not propagating).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.
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.
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.
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.
Me too
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.