--continue restores a conversation's Remote Control binding, ignoring "Enable Remote Control for all sessions: false"

Claude Code CLI version: 2.1.241
Platform: macOS 26.5, terminal over SSH

Summary

Setting /config → "Enable Remote Control for all sessions" → false does not prevent Remote Control from starting. A fresh session honours it, but claude --continue reconnects Remote Control whenever the resumed conversation ended with RC active — the global opt-out is not consulted.

#87213 established that Remote Control is bound to the conversation, not the process, and that resuming replays the RC session id recorded in the transcript. This report is a different consequence of that same design: the replay is not gated by the user's global setting.

Steps to reproduce

1. /config → Config → filter remote → set Enable Remote Control for all sessions to false.

Confirm it persisted:

• ~/.claude.json → "remoteEnabled": false
• ~/.claude/settings.json → "remoteControlAtStartup": false

1. In project A, start a session, leave Remote Control connected, /exit.
2. claude --continue in project A → /rc connecting flashes and /rc appears. Expected: no Remote Control, because the setting says false.

What isolates it

Same host, same settings, same version, throughout:

| launch | RC disconnected before exit? | /rc on resume? |
|---|---|---|
| fresh claude, no --continue | n/a — no session state | no |
| --continue, project A | no | yes |
| --continue, project B | yes | no |
| --continue, project A after /rc + /exit | yes | no |

So the setting works for new sessions, and the resumed session's stored state overrides it.

Why this is worth fixing separately

It reads as intermittent. Whether /rc appears depends on how each conversation happened to end, so the same command in two project directories behaves differently with identical config. Diagnosing it took most of a day, and three plausible causes were tested and refuted first — the setting looks simply broken until you notice the per-conversation pattern.

The setting is a global opt-out that mostly does not apply. Anyone who resumes conversations as their normal workflow — which --continue exists to support — keeps getting Remote Control on every project that ever had it, however emphatically the toggle reads false. For a feature that exposes a local terminal session to claude.ai and the mobile app, an opt-out that silently does not hold is a poor default.

The workaround is undiscoverable. /rc disconnect does stick, permanently, per conversation — but nothing indicates that the fix is per-conversation rather than global, so it reads as "disconnecting doesn't work" until you test a second project.

Suggested fix

Gate the resume-time replay on the same setting that gates a new session: if Remote Control is disabled for all sessions, do not restore a recorded binding.

Failing that, make the scope explicit — say in /config that the setting applies to new sessions only, and offer a way to clear the recorded binding from a conversation without having to resume it and disconnect by hand.

Related

• #87213 — resume replays the binding; that report covers the dead binding case and its unrecoverable reconnect. Same mechanism, different consequence.
• #80400 — RC toggle disabled after resume-from-sleep (opposite direction: it stops working when wanted).
• #34350 — no way to deactivate Remote Control mid-session, which is why the toggle cannot take effect until the next launch.