[Critical][Safety] Idle /rc bridge leaves a session live and forks it into an uninterruptible autonomous process - writes files & controls hardware with no operator kill path (v2.1.193)

Preflight Checklist

• [x] I have searched existing issues for similar behavior reports
• [x] This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Other unexpected behavior

What You Asked Claude to Do

I started a single Claude Code session to do a code-port task in one repo. Earlier in the day I had attached the mobile remote-control bridge (/rc) to drive a session, then put my phone down and did not touch it for ~1 hour. Separately I started one unrelated session for a different cleanup task on its own bridge.

What Claude Actually Did

The single port session silently forked into TWO concurrently-running live processes. One copy kept executing the task autonomously with ZERO human input from any client - writing files and driving LAN hardware (a Roku, via HTTP keypresses from the repo's own test tooling) - and ignored every terminal interrupt (ESC, Ctrl+C). I could not stop it from the terminal I was using; it only stopped when it finished the task ~14 min later. No UI surfaced the second runner; no subagent was shown.

On-disk session logs (~/.claude/projects/.../*.jsonl) prove it:

• Two session files for the one task share the same promptId and 87 identical message UUIDs, then diverge at one instant (a fork).
• Both forks carry the same /rc bridge id (bridgeSessionId cse_...).
• The mobile bridge carried ZERO command traffic: every bridge record in both forks has lastSequenceNum 0. Nothing was injected from the phone - the autonomous activity came entirely from the local agent loop.
• The idle bridge re-associated with the autonomous fork at the exact fork instant, with no human on the phone.
• The duplicating resume came from the CLI, not mobile: the 'Continue from where you left off.' turn is isMeta:true, entrypoint:cli. A local claude -c collided with a session still alive because of the idle bridge, producing a duplicate live runner instead of reattaching.
• The autonomous fork received no human input after the fork and has zero interrupt records; it ran to natural completion.

Expected Behavior

• Idle/abandoned /rc bridges should be torn down so a session does not stay alive and resumable in the background after the operator stops driving it.
• Resuming/reconnecting a session whose process is still alive should attach to it or refuse ("already active elsewhere") - never spawn a second concurrent executor.
• Every live runner for a session must be visible, and an interrupt/kill from any attached client must reach the process actually executing.
• An agent loop must never keep performing writes or external (network/hardware) actions with no human-reachable interrupt path.

Files Affected

Multiple source files in the target repo were rewritten by the autonomous fork, and the two forks stepped on each other's writes. Specifics generalized to protect the project. Redacted JSONL excerpts available on request.

Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

No, only happened once

Steps to Reproduce

Not deterministically reproduced. Suspected recipe:

1. Attach the /rc mobile bridge to a running session.
2. Stop using the phone / leave the bridge idle without tearing it down.
3. Later run claude -c / --resume against that still-live session from the CLI.

Result: a second concurrently-live process of the same session, one copy of which runs autonomously with no operator-reachable interrupt.

Claude Model

Opus

Relevant Conversation

Log-derived proof is summarized under "What Claude Actually Did." Confirmed: model claude-opus-4-8; permissionMode "auto" on the autonomous fork; 24 + 33 bridge records all at lastSequenceNum 0. Redacted JSONL excerpts (shared message UUIDs, dual bridgeSessionId, isMeta/entrypoint:cli resume marker, no-input fully-active second fork) available on request.

Impact

Critical - Data loss or corrupted project

Claude Code Version

2.1.193

Platform

Anthropic API

Additional Context

This is a harness / session-management and /rc remote-control lifecycle bug, independent of the model. Core failures: (a) idle /rc bridge not torn down -> session stays live/resumable in the background; (b) resuming a still-live session forks a second concurrent executor instead of reattaching; (c) no UI surfacing of the second runner; (d) no operator-reachable kill path for the autonomous copy. The forked process ran with permissionMode "auto" (Accept Edits ON), which is why it wrote files without prompts. A separate, unrelated session I started for a different task was on its own bridge and behaved correctly - not involved.