[Feature Request] Remote Control / web client: no Ctrl+B equivalent to background a running foreground command

Status Fixed / completed
Reported on v2.1.260
Maintainer reply None cached
Activity 1 comment · opened Sep 30, 2026 · closed Oct 2, 2026

Summary

In the terminal client, a running shell command shows (ctrl+b to run in background) and can be detached mid-flight. In Remote Control from a browser there is no equivalent: while a foreground Bash call runs, the UI offers a running-task row and a message box, but no way to move the command to the background.

The only escape is to interrupt, which kills the command. So a long foreground command cannot be rescued — it can only be destroyed and restarted.

Why this is not already covered

This was requested in #77997 ("(b) a mobile-friendly 'send this command to background' gesture (Ctrl+B equivalent)"). It was auto-closed three days later as a duplicate of #47127.

#47127 was only about the interrupt half — "Cancel/interrupt button for Remote Control (mobile)" — and closed COMPLETED on 2026-08-17 when the stop button shipped. The backgrounding half was never addressed, and is no longer tracked anywhere.

Related but distinct: #51267 (open) is remote sessions hanging with no remote unstick; #83878 and #89666 (both open) are Ctrl+B bugs in the terminal client.

Why it matters

Sending a message during a running foreground call does not interrupt it, but it also does not reach the model until the call returns, because messages are delivered at tool boundaries. So during a long foreground command a browser user cannot converse and cannot detach — only wait or kill.

Concrete cost, from a session today: an ~18-minute batch job was started in the foreground. Interrupting it was the only available action, and it died partway through, having completed roughly a quarter of its work. In the terminal, Ctrl+B would have detached it and the session would have stayed usable.

Verified in the same session that sending does not interrupt: two deliberate 60-second foreground calls both ran to completion (timestamps 17:48:19→17:49:20 and 17:51:01→17:52:01) while messages arrived mid-turn.

Repro

  1. From claude.ai Remote Control, have the assistant run a foreground Bash command lasting ~60s.
  2. Observe the running-task row while it runs.
  3. Look for any detach/background control — there is none; only send and interrupt.
  4. Compare with the terminal client, which prints (ctrl+b to run in background) beneath the running command, alongside ctrl+x ctrl+s to send now and esc to interrupt.

Proposed

A background/detach control on the running-task row in the web client, equivalent to Ctrl+B: the command keeps running, its output is collected as a background task, and the session becomes responsive immediately.

Environment

  • CLI 2.1.260, Linux, driven via Remote Control from a desktop browser
  • Terminal and web clients used against the same session

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗