/remote-control forks a background computer-use bridge that is never torn down (orphan persists for days)

Summary

Bug: Running /remote-control forks a background bridge process
(--fork-session --resume <parent-transcript>.jsonl, full mcp__computer-use__* toolset,
--permission-mode bypassPermissions) that is never torn down when the parent interactive session
exits. It persists indefinitely, inherits the parent's customTitle, and can be picked by
title/recency-based session resolution in place of the real session.

Report type

Bug

Expected behavior

The /remote-control bridge process should be terminated when its parent interactive session
exits (or reconnects/is superseded), the same way other session-scoped background work is cleaned
up. At minimum, there should be a way to discover and remove one after the fact (a list/kill
surface), since today it is invisible outside the OS process table and the local session registry.

Actual behavior

Two independent orphaned bridge processes were found for one project directory on one machine, at
the same time:

1. One forked roughly 6 days earlier via an earlier /remote-control invocation in that session;

its parent interactive session had long since ended. The bridge was still running, idle.

1. One forked the same day via a later /remote-control invocation; the user then exited that

parent session's terminal entirely. The bridge remained alive several minutes later, in a
waiting for input state, with no parent session left to answer it.

Both processes had the identical command shape:

claude --session-id <new-uuid> --fork-session --resume <parent-session-transcript>.jsonl \
  --reply-on-resume --allowed-tools mcp__computer-use__request_access \
  --allowed-tools mcp__computer-use__screenshot [... 10 more computer-use tools ...] \
  --model <model> --permission-mode bypassPermissions

Both registered in the local session registry (~/.claude/sessions/<pid>.json) with "kind":
"bg" and the exact customTitle their parent session carried at fork time. Because the orphan
kept writing to its own transcript file while idle/waiting, its transcript's mtime could be newer
than the actual interactive session's — so any tool that resolves "the session named X" by
newest-active-transcript-with-that-title lands on the orphan instead of the real session. That is
exactly what happened here: a third-party CLI launcher's session-attach command landed the user in
the orphaned bridge's transcript instead of their long-running interactive session, with no
indication anything unusual had occurred.

Minimal reproduction

1. Start an interactive Claude Code CLI session (any project directory).
2. Run /remote-control.
3. Confirm a new background process appears (ps for a `claude ... --fork-session --resume

<this session's transcript>.jsonl ... --allowed-tools mcp__computer-use__* ...
--permission-mode bypassPermissions` process).

1. Exit the parent interactive session (close the terminal, or end its process).
2. Observed: the forked bridge process from step 3 remains alive indefinitely — no timeout, no

automatic cleanup, and no visible UI surface (desktop picker, claude agents, or otherwise)
that reveals or offers to end it.

Environment

• Product and version: Claude Code CLI 2.1.241 and 2.1.251 (two orphans observed running different

versions, from the same machine's version history)

• OS and version: macOS 26.6.2 (build 25G83), Darwin kernel 25.6.0, arm64 (Apple Silicon)
• Model / resolved model ID: claude-sonnet-5 (recorded in both orphaned processes' launch

arguments; not otherwise model-specific)

• Runtime context: Long-lived interactive terminal CLI sessions (tmux-managed via a third-party

session orchestration tool), each session's parent process started days apart

• Authentication/provider path: Claude subscription (OAuth), interactive CLI

Diagnostics

Sanitized process listing for one of the two orphans (paths/usernames generalized):

PID   ELAPSED      STAT  ARGS
<pid> 06-01:20:47   SN   .../claude/versions/2.1.241 --session-id <uuid> --fork-session \
  --resume /.../.claude/projects/<slugified-cwd>/<parent-session-uuid>.jsonl --reply-on-resume \
  --allowed-tools mcp__computer-use__request_access --allowed-tools mcp__computer-use__screenshot \
  --allowed-tools mcp__computer-use__zoom --allowed-tools mcp__computer-use__left_click \
  [... 8 more mcp__computer-use__* tools ...] \
  --model claude-sonnet-5 --permission-mode bypassPermissions

Corresponding registry entry (~/.claude/sessions/<pid>.json, sanitized):

{
  "pid": <pid>,
  "sessionId": "<new-fork-uuid>",
  "cwd": "<worktree path>",
  "kind": "bg",
  "name": "<same name the parent session had at fork time>",
  "status": "idle",
  "bridgeSessionId": null
}

Regression and controls

• Fresh process/session: Reproduces — observed independently for two separate /remote-control

invocations, days apart, same machine.

• Last known good version: Unknown — no prior version tested without this behavior.
• Relevant control: The parent session's own transcript recorded a "type": "bridge-session"

event around the time each /remote-control invocation ran, corroborating the fork's origin.

Hypothesis

/remote-control's bridge process is designed to keep running independently of the terminal so a
mobile/desktop Remote Control client can keep driving the Mac even if the originating terminal
closes — a reasonable design goal on its own. The apparent gap is that nothing ever revisits that
decision: there is no termination hook tied to the parent session's exit, no idle/inactivity
timeout, and no discoverable list/kill surface once the terminal is gone. This looks like the same
root neighborhood as #77649 (an idle background fork that never reaches a terminal/settled state,
so nothing ever cleans it up) with /remote-control as one concrete, easily reproduced trigger for
it, and inherits #77649's Defect 4 concern almost exactly (an unattended fork retaining auto-like
elevated permission — here bypassPermissions — plus the full computer-use toolset).

Related public reports

1. https://github.com/anthropics/claude-code/issues/77649 — "Background-session daemon: un-settled

worker pins daemon → reconnect re-forks a duplicate idle session (+ --continue drops
permission mode; forks inherit auto/computer-use)". Same defect family (Defects 1, 2, and 4):
an idle/un-settled background fork is never cleaned up and inherits elevated permission plus
the computer-use toolset. That report's trigger was a generic reconnect/bounce; this report
pins the trigger specifically to /remote-control and adds a multi-day persistence data point
plus a concrete downstream-tooling consequence.

1. https://github.com/anthropics/claude-code/issues/82375 — "Remote Control: orphaned server-mode

hosts cannot be removed and show false 'Connected' state". Same "Remote Control leaves
permanent, undiscoverable debris" theme, at the pairing/host-registration layer rather than the
local OS-process layer this report documents.

1. https://github.com/anthropics/claude-code/issues/90243 — "Stale Remote Control pairings (800+)

truncate cross-session reachability scan" (filed by this same fleet). A third, distinct
Remote-Control-debris mechanism (server-side pairing records, not local processes) with a
different functional consequence (ListAgents/SendMessage truncation). Cited as a sibling
"Remote Control never cleans up after itself" defect, not the same root cause.