[BUG] Remote Control auto-registration mints an empty <hostname>-* session every ~5 minutes, flooding Recents (onset 2026-07-16, server-side default; workaround: remoteControlAtStartup=false)

Bug report: Remote Control auto-registration floods Recents with empty <hostname>-* sessions

Component: Claude Code CLI (2.1.209 / 2.1.211) + claude.ai Code sessions surface
Platform: macOS 15 (Darwin 25.5.0), Claude desktop app 1.22209.0
Date observed: onset 2026-07-16 ~16:55 UTC, ongoing through 2026-07-17

Summary

Since 2026-07-16 (~16:55 UTC), Claude Code CLI processes on this machine have been auto-registering
claude.ai "Remote Control" sessions at a rate of one every ~5 minutes, around the clock. Each
registration creates a NEW cse_* session titled <hostname-slug>-<codename> (here:
macbook-pro-local-*), archives the previous one, and the trail floods the desktop app's Recents
sidebar. In ~40 hours: 191 sessions, every one with user_message_count: 0, all tagged
remote-control-auto, config.origin: "claude_code_cli", environment_kind: "bridge".

The user never enabled this. Nothing changed locally at onset time; the CLI bundle contains
remote_control_auto_on_by_default described as "True when remote_control_auto_enable is true
because of the org/GB default rather than an explicit remoteControlAtStartup" — i.e., a
server-side default flip appears to have enabled auto-registration for existing installs.

Evidence

• GET /v1/code/sessions (claude.ai): 191 sessions titled macbook-pro-local-*;

created_at by day: 2026-07-16: 85, 2026-07-17: 105 (by 08:29 UTC); none before 2026-07-16.

• Cadence: created_at at exact ~5-minute marks, two interleaved 10-minute clocks

(e.g. 08:04:01.7, 08:09:02.8, 08:14:01.7, 08:19:02.3, 08:24:01.7 UTC) — consistent with two
long-running CLI processes re-registering on a poll, not with any local scheduler
(the machine's launchd timers were ruled out; their run times don't align).

• All sessions: user_message_count: "0", tags: ["remote-control-auto"], status lifecycle

active → archived as the next tick replaces them (1 active at any moment, 190 archived).

• Machine runs many concurrent Cowork/CCD sessions (CLI 2.1.209 app-bundled) plus a standalone

CLI that self-updated 2.1.209 → 2.1.211 on 2026-07-16 21:38 CEST.

• Default name prefix is the hostname (--remote-control-session-name-prefix "default: hostname"),

producing the macbook-pro-local-* titles from MacBook-Pro.local.

Impact

• Desktop app Recents fills with dozens of empty, identically-named sessions per day; the user

was archiving "a dozen at a time" and could not tell what was creating them.

• Because the records are server-side only, the local session list (list_sessions) cannot see

them, making the source very hard to diagnose from the machine.

• User-trust issue: unattributed session records on an account read as a possible compromise.

Workaround found (verified)

"remoteControlAtStartup": false in ~/.claude/settings.json (explicit setting overrides the
org/GB default per the bundle's schema description). Verified effective: registrations stopped
immediately after the setting was written — zero new sessions across all subsequent 5-minute
tick windows (previously 12/hour, around the clock) — and it propagated to already-running CLI
processes without restarting them.

Suggested fixes

1. Reuse a single Remote Control registration per device (or per session), instead of minting a

new cse_* record every poll tick.

1. Don't surface zero-message auto registrations in Recents (web or desktop).
2. Don't flip remote_control_auto_on_by_default on for existing installs without a visible

notice; headless/background CLI invocations especially should not auto-register.

1. Tag auto-registrations distinctly in UI (they already carry remote-control-auto) so users

can bulk-dismiss them.

Related

• Likely the same root cause as #77517 ("Remote control sessions auto-triggering without explicit trigger", v2.1.202, darwin, 2026-07-14) — that report predates this machine's onset by two days, consistent with a staged rollout of the same server-side default.

🤖 Generated with Claude Code