Idle Remote Control bridge keeps a dormant session at ~7% CPU indefinitely (48h CPU over 26 days)

Summary

A CLI session that has been conversationally idle for weeks keeps a Remote Control bridge alive and burns a steady ~7% CPU indefinitely. Over 26 days one such session accumulated ~48 hours of CPU time while doing no work: its transcript shows no conversational turn after day 3.

The transcript's bridge-session records suggest a reconnect loop rather than real traffic.

Evidence

In the session's ~/.claude/projects/<project>/<session>.jsonl there are 124 bridge-session records. Their lastSequenceNum values contain only two distinct values:

• 123 records with lastSequenceNum: "0"
• 1 record with lastSequenceNum: "1804"

So the bridge appears to have been re-established ~124 times, and carried real traffic exactly once. The file keeps being written daily — last write 26 days after the final conversational entry — with no new user/assistant records.

Process state at the time of capture:

PID    STAT  ELAPSED       TIME        %CPU  RSS
47656  S+    26-00:07:45   2869:51.35  ~7.3  ~450 MB

STAT S+ (sleeping in the foreground process group, i.e. sitting at the prompt), yet top sampled it as running at 7.3% CPU.

Each such session also pins its MCP servers for its whole lifetime. On this machine four long-lived sessions plus one Codex app-server held 48 complete chrome-devtools-mcp instances = 144 processes, ~1.58 GB. None were orphaned (ppid == 1 count was zero) — every one had a living parent, so the usual "kill orphaned MCP servers" advice does not apply. Killing the one session above reclaimed its 5 MCP processes and dropped system swap by roughly 3 GB.

Expected

An idle Remote Control bridge should not consume a measurable CPU fraction indefinitely. Either the reconnect should back off, or a bridge for a session with no activity should be torn down.

Actual

Continuous ~7% CPU for 26 days on an otherwise idle session, with a repeating lastSequenceNum: 0 bridge record each cycle.

Environment

• Claude Code 2.1.247
• macOS 26.5.1, arm64
• Session started with --dangerously-skip-permissions (likely irrelevant)

Notes

Identifiers (bridgeSessionId, session UUIDs, absolute paths) are omitted deliberately; happy to supply them privately if useful. I have not been able to test whether this reproduces without Remote Control ever having been attached to the session.