Claude Code Remote Controlの無効化設定と既定で有効になる経緯

Claude Codeのセッションを開くたびに、頼んでもいないRemote Controlが有効な状態で立ち上がる。そんな報告が2026年8月からGitHub issueに積み上がっています。原因は個々の環境設定ではなく、サーバー側から配信されるフィーチャーフラグが「過去に一度でも同意した端末」を自動的に有効化する仕組みでした。止める手段自体は公式ドキュメントに存在しますが、報告の多くはそこにたどり着く前に「無効化できない」と結論づけています。

「勝手に有効になる」報告がv2.1.236以降で続く

issue #88094は2026年8月20日、v2.1.236環境での報告として開きました。9月13日時点でも「バグはまだ存在する(v2.1.270)」というコメントが付き、開いたままです。10件のコメントと10件の+1リアクションが集まり、Windows・Linux・macOSのいずれでも再現が確認されています。

Remote Controlとは、claude.ai/codeやスマートフォンのClaude Appから、手元のマシンで動くClaude Codeのセッションを操作できるようにする機能です。最初の報告者はWindows上で「更新後、すべてのセッションでRemote Controlが有効になり、画面の隅に/rcが出続ける」と書いています。翌日にはLinuxのネイティブインストールでの再現も付き、Windows固有ではないことが早い段階で分かりました。

同じ時期に、別の切り口の要望も2件立っています。8月27日の#90179は「Remote Controlはオプトインにすべきで、既定で有効にすべきではない」という提案です。9月2日の#91459は「完全に無効化するオプションが欲しい」という機能要望で、優先度を「Critical」としています。三つの issueはいずれもクローズされておらず、Anthropicからの公式な返信も付いていません。

何が有効化を決めているのか

有効化の引き金は、手元の設定ファイルではなくサーバーから配信されるフィーチャーフラグです。過去に一度でもRemote Controlに同意した端末にはhasUsedRemoteControl: trueという状態が残ります。ここにtengu_ide_rc_auto_enable: trueというフラグが配信されると、次に新しいセッションを開いた瞬間からRemote Controlが自動接続します。

この仕組みを最初に突き止めたのはAlex0007の投稿です。デスクトップアプリのセッションメタデータを132件分さかのぼり、remoteControlAutoEligibleというフィールドが2026年8月21日午前4時37分を境に出現し始めたことを確認しました。同じ日の午前10時7分以降に作られたセッションは、例外なくtrueかつ接続用のbridgeSessionIds付きで生成されています。~/.claude.jsonのキャッシュを手でfalseに書き換えても、10分足らずでファイルごと再生成されtrueに戻ったとも報告されています。

LucAceの調査では、VS Code拡張がセッション開始時にAnthropicのバックエンドから受け取る設定にremote_control_auto_enable・remote_control_auto_on_by_default・ide_rc_auto_enable_gateという値が含まれることが確認されました。これらが揃って真になると、拡張は内部のトグルをユーザー操作なしに自動でオンにします。別の報告者kurtjcuは、自分の環境ではtengu_cobalt_harborという異なる名前のフラグが同じ役割を果たしていたと述べており、フラグの名称自体はロールアウトの時期によって変わっている可能性があります。

公式ドキュメントは、Remote Controlについて「claude remote-control・--remote-control・/remote-controlを明示的に実行しない限り有効化しない。ただしauto-connectをオンにしている場合を除く」と説明しています。auto-connectは/configの「Enable Remote Control for all sessions」で切り替え、既定は「組織の管理者設定があればそれに従い、なければClaude Codeの既定値」です。issueが問題にしているのは、この文書化された経路とは別に、サーバー側フィーチャーフラグという第二の経路が存在し、そちらがユーザー側の選択を待たずに有効化を決めている点です。

利用者への通知は一応用意されています。「Keep working from anywhere… To keep sessions in this IDE only, turn off…」という一度きりのトーストです。ただしkurtjcuの調査では、この通知枠はfable-5-promoやopus-5-launchといった製品告知と同じ表示回数の上限を取り合っており、自分のアカウントでは告知の方が枠を使い切っていて、Remote Control有効化の通知は一度も出ていませんでした。通知を実装していても表示枠を他の告知に取られれば結果は同じで、有効化だけが静かに起きます。

無効化が「効かない」という報告の実態

個人アカウントでRemote Controlを確実に止める設定は、ドキュメント上ちゃんと存在します。disableRemoteControlです。

{
  "disableRemoteControl": true
}

設定リファレンスによれば、この値はclaude remote-control・--remote-controlフラグ・auto-start・セッション内トグルのすべてを拒否します。スコープは「Any file」で既定はfalse。「主にmanaged settingsで使う想定」という説明文が付いていますが、~/.claude/settings.jsonのような個人の設定ファイルからでも同じ効果があります。issue #91459のコメントでは、この設定が「Team/Enterprise向けの機能で個人プランには公開されていない」と誤解している投稿もありましたが、リファレンス上はプランを問わず有効な一般設定です。基本的な使い方や、より緩いremoteControlAtStartupとの違いはClaude Code Remote Controlで作業を別デバイスに引き継ぐにまとめています。

見つけにくさとは別に、デスクトップアプリ特有の落とし穴も報告されています。Alex0007によれば、Claude Desktopの「Enable Remote Control for all sessions」トグルは、実際に一度操作して値を変えたときだけclaude_desktop_config.jsonのpreferencesブロックに書き込まれます。画面上は「オフ」に見えていても、一度も触っていなければ内部には何も保存されておらず、サーバー側フラグを上書きする値が存在しません。トグルをオンにしてからもう一度オフに戻すと、そこで初めてccRemoteControlDefaultEnabled: falseが書き込まれ、以降の新規セッションはオフのまま起動するようになったと報告されています。この挙動はデスクトップアプリでの投稿に基づくもので、CLIの~/.claude/settings.jsonが同じ制約を持つとは確認されていません。

一部には「グローバルに無効化していても有効化される」という趣旨の投稿もありますが、これは他の参加者による再現の追認がない単発の報告です。一方でトグルの一度切り替えという回避策やdisableRemoteControlの設定は、複数の投稿者が効果を確認しています。フィーチャーフラグの評価自体を止めるCLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFICやDISABLE_GROWTHBOOKという変数もありますが、公式ドキュメントの利用条件にあるとおり、これらを設定するとRemote Control自体が利用不可になります。ピンポイントの解決策ではなく、他のフィーチャーフラグ判定も道連れにする点は踏まえておく必要があります。

この不具合が壊しているのは原則より運用

ドキュメントが明記する「明示的に実行しない限り有効化しない」という設計は、記述としては正しいままです。崩れているのは、その原則を上書きできる経路がフィーチャーフラグという形で別に存在し、しかも通知の仕組みが他の製品告知と表示枠を取り合って負ける、という運用の側だと見ることができます。

#90179と#91459の要求を読み直すと、求めているのは新機能ではありません。中心にあるのは、すでにあるdisableRemoteControlを見つけやすい場所に出すことと、フラグ配信よりユーザー自身の設定ファイルを優先させることの二つです。#90179はさらに、アカウント側で上書きできない環境変数ベースのキルスイッチをmanaged settingsで強制できるようにすることと、この挙動の脅威モデルを公式に公開することも求めています。issueにAnthropic側からの公式な返信は付いておらず、直近のCHANGELOG(v2.1.283まで確認)にもこの挙動を修正したという記載は見当たりません。

組織側で強制的に止める手段

Team・Enterprise組織の管理者は、メンバー個々の設定を待たずにRemote Controlを封じる手段を持っています。disableRemoteControlをmanaged settingsとして配信すれば、デバイス単位でMDM的に強制でき、メンバー側が気づいていなくても即座に効きます。

Trusted Devicesは、Pro・Max・Team・Enterpriseで使えるベータ機能で既定はオフです。Team・EnterpriseはOwnerが組織全体に対して有効化し、Pro・Maxは自分のアカウント設定から個別に有効化します。ただしTrusted Devicesが制限するのは「誰がセッションを閲覧・操作できるか」であって、「Remote Controlが自動で有効化されるかどうか」ではありません。auto-connect自体を止めたい場合の答えにはならない点は区別しておく必要があります。

なお、Zero Data Retentionを選択している組織は、個々のメンバーの設定を待たずにRemote Control自体を有効化できません。契約上のデータ保持ポリシーがそのままRemote Controlの可否を決めるケースで、disableRemoteControlの配信とは別の経路です。

まとめ

Remote Controlの既定オン問題は、ユーザーの設定ファイルではなくサーバー側フィーチャーフラグが有効化を決めているために起きています。無効化の手段自体はdisableRemoteControlとしてドキュメント化されており、Team/Enterpriseなら管理者側からのmanaged settings配信でも止められます。issueは3件ともクローズされておらず、公式からの修正アナウンスも確認できていません。同じRemote Control周りでは接続が不安定になる別種の不具合も報告されており、Remote Controlが20分放置で切断される原因で扱っています。Remote Control自体の来歴はClaude Code v2.1.51でclaude remote-controlが追加された経緯から確認できます。