{"version":"2.1.283","anchor":"remote-control-at-startup-gains-a-new-early-off-path-ahead","canonical_anchor":"remote-control-at-startup-gains-a-new-early-off-path-ahead","heading":"Remote Control at startup can now be switched off before a persistent session forces it on","tier":"soon","area":"Remote Control","url":"https:\/\/changelogs.core-directive.com\/v\/2.1.283\/e\/remote-control-at-startup-gains-a-new-early-off-path-ahead","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.283","markdown":"### Remote Control at startup can now be switched off before a persistent session forces it on\n\nA new check can now keep Remote Control off at startup even where a persistent remote session used to always switch it on\n\n**Unclear.** What the new check actually tests is not identified.\n\n**What**\n\nRemote Control lets a session be driven from elsewhere, and Claude Code decides at startup whether to turn it on. Before, a persistent remote session always turned it on, and nothing else was checked first.\n\nClaude Code now reads the organisation policy `remote_control_at_startup` first. A new check then comes before the persistent-session rule, and when it applies Remote Control stays off, with the organisation policy recorded as the reason when that policy is explicitly set to off. The last fallback is unchanged and is off unless it is switched on remotely.\n\n**Why**\n\nIn some cases a persistent remote session will no longer start Remote Control automatically.\n\n- Flag `tengu_cobalt_harbor`: Off in both readings (read for one account on one subscription tier against v2.1.283; this account: off, anonymous baseline: off, compiled default: off) These values were read against a different version of Claude Code, so treat them as the nearest reading available instead of one taken on this release.\n- Area: Remote Control\n- Tier: Nothing to try yet\n- Useful: 2\/5\n- Signal: 3\/5\n- Present in the build but not switched on"}