Claude Media
Claude Code Remote Controlの無効化設定と勝手に有効になる原因

Claude Code Remote Controlの無効化設定と勝手に有効になる原因

Remote Controlはsettings.jsonのdisableRemoteControlで無効化できます。勝手に有効になる原因のサーバー側フラグと、設定が効かないときの回避策も解説します。

設定リファレンスでは、~/.claude/settings.jsonに"disableRemoteControl": trueを置くと、Remote Controlの起動経路がすべて拒否されます。組織で強制するなら、managed settingsに同じキーを配信します。自動接続だけを止める設定としてremoteControlAtStartupのfalseもあります。

デスクトップアプリで勝手に有効になる場合は、Connect new sessions to Remote Controlを一度オンにしてからオフに戻すと止まったという報告があります。設定キーがサーバー側フラグに勝つかは未検証なので、再起動後の新規セッションで確かめてください。

Claude Codeのセッションを開くたびに、頼んでもいないRemote Controlが有効な状態で立ち上がる。そんな報告が2026年8月からGitHub issueに積み上がっています。issueの調査では、原因は個々の環境設定ではなく、サーバーから配信されるフィーチャーフラグが「過去に一度でも同意した端末」を自動的に有効化する仕組みだと指摘されています。止める設定は設定リファレンスにあります。

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

issue #88094は、更新後の自動有効化の報告として開きました。経過は下の表のとおりで、10件のコメントと10件の+1リアクションが集まり、Windows・Linux・macOSのいずれでも再現が確認されています。

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

同じ時期に、別の切り口の要望も2件立っています。#90179は、Remote Controlを既定でオフにしてオプトインにする提案です。#91459は完全に無効化するオプションを求める機能要望で、優先度を「Critical」としています。三つのissueはいずれもクローズされていません。

日付バージョン等出来事
2026-08-20バージョン等v2.1.236出来事issue #88094提出。更新後に全セッションでRemote Controlが有効化されると報告
2026-08-21バージョン等v2.1.237 / desktop 1.34493.1出来事サーバー側フラグtengu_ide_rc_auto_enableと、セッションごとのremoteControlAutoEligibleフィールドの存在が特定される
2026-08-23バージョン等v2.1.235/241のスキーマ出来事disableRemoteControl設定の存在が指摘される
2026-08-27バージョン等v2.1.247出来事issue #90179提出。「オプトインにすべき」という提案
2026-09-02バージョン等-出来事issue #91459提出。「完全に無効化したい」という機能要望
2026-09-13バージョン等v2.1.270出来事「バグはまだ存在する」というコメント。issueは未解決のまま

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

issueの調査によれば、有効化の引き金は手元の設定ファイルではなく、サーバーから配信されるフィーチャーフラグです。流れは次の3段階です。

手順

自動有効化が起きるまで

  1. 1

    過去に同意した状態が端末に残る

    一度でもRemote Controlに同意した端末にはhasUsedRemoteControl: trueが残ります。

  2. 2

    サーバーがフラグを配信する

    tengu_ide_rc_auto_enable: trueというフラグが、ユーザー操作とは無関係に届きます。

  3. 3

    次のセッションから自動接続する

    新しいセッションを開いた瞬間にRemote Controlがつながります。

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

別の報告者は、自分の~/.claude.jsonで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の既定値」です。同じページのDesktop appの項では、同じトグルの名前は「Settings > Claude Code > Connect new sessions to Remote Control」になっており、画面によって呼び名が違います。issueが問題にしているのは、この文書化された経路とは別に、サーバー側フィーチャーフラグという第二の経路が存在し、そちらがユーザー側の選択を待たずに有効化を決めている点です。

利用者への通知は一応用意されています。「Keep working from anywhere… To keep sessions in this IDE only, turn off…」という、表示回数に上限のあるトーストです。ただし先ほどの別の報告者の環境では、seenNotificationsが空でした。同じ表示枠にはfable-5-promo-2-4-maxとopus-5-launchの告知が出ています。通知が告知に枠を取られたのか、そもそも表示待ちに入らなかったのかは区別できていません。

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

公式の仕様では4経路すべてを拒否する設定が、ドキュメント上ちゃんと存在します。disableRemoteControlです。

{
  "disableRemoteControl": true
}

設定リファレンスによれば、この値はclaude remote-control・--remote-controlフラグ・auto-start・セッション内トグルのすべてを拒否します。スコープは「Any file」で既定はfalse。説明にはデバイス単位のMDM強制ならmanaged settingsに置くとあり、管理者向けの設定に見えます。ただし~/.claude/settings.jsonのような個人の設定ファイルからでも同じ効果があります。#91459では、個人プランにはアカウント単位で無効化する手段がないという指摘もありました。一方で設定リファレンスのスコープは「Any file」で、プランによる条件は付いていません。基本的な使い方や、より緩いremoteControlAtStartupとの違いはClaude Code Remote Controlで作業を別デバイスに引き継ぐにまとめています。

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

「無効化していても有効化される」という報告は、#88094の三人の投稿者から出ています。トグルをオンにしてからオフに戻す回避策は、そのうち二人が効果を報告しています。disableRemoteControlについては、ある投稿者が再起動後にサーバー側フラグへ勝つかをまだ確かめていないと書いており、実機での確認報告はissueにありません。

フィーチャーフラグの評価自体を止めるCLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFICやDISABLE_GROWTHBOOKという変数もあります。ただし公式ドキュメントの利用条件にあるとおり、設定するとRemote Control自体が利用不可になります。ピンポイントの解決策ではなく、他のフィーチャーフラグ判定も道連れにします。DISABLE_TELEMETRYやDO_NOT_TRACKだけを設定した場合は、Trusted Devicesを組織が必須にしていない限りRemote Controlは使えるままです(v2.1.283以降)。

止めるキーは二つある

設定リファレンスにはRemote Control関連のキーが二つあります。/configの「Enable Remote Control for all sessions」の実体はremoteControlAtStartupで、disableRemoteControlとは効く範囲が違います。

くらべる

二つのキーの効き方

全面禁止

disableRemoteControl: true

claude remote-control・--remote-control・auto-start・セッション内トグルをすべて拒否します。拒否時は組織のポリシーで無効化されたと表示されます。

自動接続だけ停止

remoteControlAtStartup: false

セッション開始時の自動接続をやめ、/remote-controlを待つ状態にします。--remote-control付きの起動は、falseのままでも有効になります。

remoteControlAtStartupのfalseは、置き場所で強さが変わります。/configで選ぶとユーザー設定に保存され、managed settingsのtrueが優先されます。プロジェクトやローカルの設定(.claude/settings.json・.claude/settings.local.json)に置いたfalseは、managed settingsのtrueよりも優先されます。逆にこの2か所のtrueは無視されるので、リポジトリ側から全員のRemote Controlをオンにすることはできません。

v2.1.287のclaude --helpには、有効化側のフラグしかありません。

  --remote-control [name]               Start an interactive session with Remote
                                        Control enabled (optionally named)
  --remote-control-session-name-prefix <prefix>
      Prefix for auto-generated Remote Control session names (default: hostname)

1回だけオフにするフラグは出てきません。空のHOMEで未ログインのままclaude remote-controlを実行すると、次のエラーで止まります。

Error: You must be logged in to use Remote Control.
 
Remote Control is only available with claude.ai subscriptions. Run `claude auth login` to sign in with your claude.ai account.

Remote Controlはclaude.aiのサブスクリプション認証が前提で、APIキーはサポート外です。

issueで効果が確かめられたのは、デスクトップアプリのccRemoteControlDefaultEnabled: falseです。CLIのremoteControlAtStartup: falseがサーバー側フラグに勝つかは、issue上では検証されていません。CLIで「設定で無効化しても有効になる」という報告は出ていますが、どの設定かは書かれていません。

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

ドキュメントが明記する「明示的に実行しない限り有効化しない」という設計は、記述としては正しいままです。崩れているのは、その原則を上書きできる経路がフィーチャーフラグという形で別に存在し、しかも有効化の通知が出ないまま有効化だけが起きた環境がある、という運用の側だと見ることができます。

#90179の要望は四つです。既定をオプトインにすること、起動時に効いてアカウント側が上書きできないキルスイッチを設定キーと環境変数で用意すること、managed settingsで組織に強制できること、脅威モデルを公開することです。#91459は、/configかClaudeのダッシュボードのユーザー設定に、完全に切る選択肢を足してほしいという要望です。三つのissueにAnthropic側のアカウントからのコメントは付いておらず、v2.1.287までのchangelogにもこの挙動を直した項目は載っていません。

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

Team・Enterprise組織の管理者は、メンバー個々の設定を待たずにRemote Controlを封じる手段を持っています。disableRemoteControlをmanaged settingsに置けば、デバイス単位でMDMによる強制ができます。メンバーの画面には、IT管理者がこの端末でmanaged settings経由で無効化したという趣旨のエラーが出ます。

状況有効な手段補足
個人アカウントでRemote Control自体を止めたい有効な手段~/.claude/settings.jsonにdisableRemoteControl: true補足ユーザー設定ファイルは端末ごとのファイル
Team/Enterpriseで組織全体に強制したい有効な手段managed settingsでdisableRemoteControlを配信補足デバイス単位のMDM強制向け
組織としてRemote Controlの入口を閉じたい有効な手段Ownerが管理画面のRemote Controlトグルを有効にしない補足Team・Enterpriseでは、Ownerが有効化するまで使えない
接続は許すが操作元を制限したい有効な手段Trusted Devices補足自動接続自体は止めない。閲覧・操作を承認済み端末+直近の認証に限定する
フィーチャーフラグ配信自体を止めたい有効な手段DISABLE_GROWTHBOOK等補足Remote Control以外の機能判定も止まる副作用がある

Trusted Devicesは、Pro・Max・Team・Enterpriseで使えるベータ機能で既定はオフです。Team・EnterpriseはOwnerが組織全体に対して有効化し、Pro・Maxは自分のアカウント設定から個別に有効化します。

Zero Data Retentionのようなコンプライアンス要件のある組織は、Remote Controlを有効化できません。これはdisableRemoteControlの配信とは別の経路です。

まとめ

公式仕様で4経路をまとめて拒否するのはdisableRemoteControlだけで、組織で強制するならmanaged settingsに置きます。ただしどちらのキーもサーバー側フラグに勝つかはissue上で検証されておらず、止まったかどうかは再起動後の新規セッションで確かめることになります。同じRemote Control周りでは接続が不安定になる別種の不具合も報告されており、Remote Controlが20分放置で切断される原因で扱っています。Remote Control自体の来歴はClaude Code v2.1.51でclaude remote-controlが追加された経緯から確認できます。

参照した一次ソース

この記事の記述は、次の一次ソースと照合しています。更新時に参照先が変わった場合は一覧も更新します。

  1. github.com/anthropics/claude-code/issues/88094
  2. github.com/anthropics/claude-code/issues/91459
  3. github.com/anthropics/claude-code/issues/90179
  4. code.claude.com/docs/en/remote-control
  5. code.claude.com/docs/en/settings-reference
  6. code.claude.com/docs/en/changelog
この記事を共有:XはてブLinkedIn