Claude Desktopのstealth updateでRemote Controlが切れる原因と復旧
外出中にClaude Desktopが自動更新で再起動し、Remote Controlのセッションがスマホから消える報告です。ログの見分け方、再起動の条件、戻すときの手順を挙げます。
外出先からスマホでRemote Controlのセッションを操作していたら、全部のセッションが同時に閉じた。Mac側を見ると、アプリはいつの間にか再起動している。この症状が、GitHubのclaude-codeリポジトリのissue #95364に報告されています。issueはopenのままで、修正の告知は付いていません。
原因として報告されているのは、Claude Desktopの自動更新「stealth update」です。ログに [stealth-update] と出るこの処理は、アプリを閉じて更新し、開き直します。このとき各セッションのRemote Controlの接続が切れ、再起動後も戻りません。
何が起きているのか
#95364の報告によると、更新ファイルのダウンロードが終わったあと、アプリは短い待ち時間を置いてから自分で終了し、再起動します。ユーザーがMacの前にいれば気づきにくい動きです。
Remote Controlを使う人には逆に働きます。席を離れているときに限って再起動が走るためです。報告者は、旅行中にノートPCを開くたびに接続が切れ、アプリが再起動していたと書いています。
issueに貼られた1回分のログは次のとおりです(macOS、Claude Desktop 2.2553.1、時刻は現地)。
09:47:53 [updater] Update downloaded and ready to install
10:21:28 [stealth-update] Triggering stealth update after idle timeout
10:21:28 [remote-tools-device] close
10:21:28 [CCD] Stopping 3 active session(s) on quit
10:21:31 beforeQuitForUpdate handler fired, going down for update
10:21:54 Starting app
10:21:54 [updater] Version changed since last launch: 2.2553.0 → 2.2553.1更新が準備できてから約34分後に、セッションが3本とも止まっています。報告者の手元では、最後のセッション操作の約10分後に再起動が走りました。
再起動が走る条件
issueによると、更新の側には再起動を止める条件が4つあります。
stealth updateを止める4つの条件
同じ版の更新が何度も失敗している
インストールが繰り返し失敗した版は、再起動の対象から外れます。
セッションが実行中
ターンを処理している最中のセッションがあれば止まります。
ウィンドウにフォーカスがある
Claudeのウィンドウを操作している間は走りません。
ウィンドウが全画面
全画面表示のあいだも止まります。ただし後述の72時間経路には効きません。
出先でRemote Controlを使う人は、2つ目から4つ目がすべて満たされません。接続しているだけで誰も触っていないセッションは、更新から見ると放置されたマシンと区別がつかない、というのが報告者の見立てです。
コメントでは、さらに踏み込んだ指摘がありました。同じ版(2.7032.0)のバンドルを読んだというユーザーが、次の内容を書いています。
- 「リモート由来の活動」を数える判定は、スマホなどからセッションを開始した場合にしか働かない
- Mac側で開始し、Remote Controlを有効にしたセッションは、ターンの合間には待機中として数えられる
- 「Connect new sessions to Remote Control」で自動的につながったセッションも同じ扱いになる
デスクトップ側で始めたセッションを外から使う、という最も普通の使い方が、保護の外にあることになります。この読みはユーザーによるバンドルの解析で、Anthropicからの説明ではありません。
72時間後の再起動経路もある
別のコメントは、もう1つの経路を報告しています。更新が72時間たまったままだと、Auto-restarting app after update pending for N hours というログとともに、アプリが再起動します。
この経路は、入力が10分ないこと、セッションが実行中でないことを見ます。ウィンドウのフォーカスや全画面は見ません。全画面にしていても、72時間を過ぎれば止まらないことになります。報告者はこの経路のログも自分のマシンで確認したと書いています。
再起動後にRemote Controlが戻らない理由
接続が切れること自体より、戻らないことのほうが被害が大きい点を、#95491が指摘しています。
#95491の報告によると、再起動後にセッションの記録は復元され、準備もされます。しかし、プロセスを起動する処理が走らないため、Remote Controlを自動でつなぐ処理も走りません。Remote Controlの自動接続は、復元ではなくセッションの起動に結びついている、という説明です。
報告者のログでは、再起動後に Starting local session と Enabling remote control の組が出ませんでした。同じ報告では、この組が出たのはセッションを新しく起動したときで、復元の際には出ていません。
「Connect new sessions」では救えない
設定の「Connect new sessions to Remote Control」をオンにしていても同じです。複数のコメントが、この設定は新しく作ったセッションにだけ働き、更新後に復元されたセッションには効かないと報告しています。
スマホ側からは戻せない
セッション単位のRemote Controlスイッチも、止まったセッションには使えません。コメントによると、次のメッセージで断られます。
Remote Control requires an active session. Send a message first.メッセージを送るにはスマホから届く必要がありますが、届かないことが問題でした。#95491の報告者は、予約タスクで別セッションにメッセージを送る回避も試し、無人の実行からは送れないと書いています。
アプリの中に、更新後の復元処理があるとの指摘もあります。更新で終了する際にRemote Controlが生きていたセッションへ印を付け、次の起動で再接続して Remote Control restore after update とログに出す仕組みです。ただし、この指摘をした人のログには、5回の再起動すべてでその行が出ていません。印を付ける側が機能フラグの後ろにあり、自分のアカウントでは有効になっていないのではないか、と推測しています。推測なので、事実として扱えるのは「その行が出なかった」までです。
再起動が走ったかを調べる
症状が更新によるものかは、ログで確かめられます。macOSのログは ~/Library/Logs/Claude/main.log です。Windowsでは %LOCALAPPDATA%\Claude\logs\main.log にあります。
grep -nE "stealth-update|Auto-restarting app|Stopping [0-9]+ active session" \
~/Library/Logs/Claude/main.logTriggering stealth update after idle timeout の時刻が、スマホから接続が消えた時刻と重なっていれば、同じ症状の可能性が高くなります。続けて Stopping N active session(s) on quit が出ていれば、そのとき止められたセッション数も分かります。
再起動の後に、次の2行が組で出ているかも確かめます。
grep -nE "Starting local session|Enabling remote control|rcAutoEnable" \
~/Library/Logs/Claude/main.log再起動の直後にこの行がなく、数時間後に自分でセッションを開いたときに初めて出るなら、報告と同じ経過です。
落とし穴
窓が戻ると、再起動に気づけない
#95491に付いたコメントによると、再起動後はウィンドウが元どおり表示されます。見た目には再起動していないので、接続が消えた理由に気づきにくくなります。ログの時刻と、スマホ側のセッションが閉じた時刻を突き合わせるのが確実です。
接続を戻す方法
報告されている戻し方は、どれも人がMacの前、またはMacを操作できる状態にいる前提です。
| 方法 | 報告された内容 | 条件 |
|---|---|---|
| セッションにメッセージを送る | 報告された内容メッセージのターンが走ると、warm_send の契機でRemote Controlがつながる | 条件Mac側で送る |
| セッションのRemote Controlバッジを押す | 報告された内容止まったセッションでも、約5秒でつながったという報告 | 条件Mac側で操作する。画面ロック中は使えない |
claude:// のリンクでセッションを開く | 報告された内容プロセスが起動し、その後にRemote Controlをオンにできたという報告 | 条件ウィンドウが前面に出る。起動の上限に当たることがある |
バッジを押す方法は、止まったセッションを1つずつ戻します。報告者の1人は、10セッションを復旧するのに claude://claude.ai/epitaxy/local_<id> 形式のリンクを順に開く補助を自作しましたが、そのたびにウィンドウが前面に出て、1朝で何十回も繰り返されたと書いています。同じ人は、同時に動かせるセッションの上限(at cap=10)にも当たり、一部のセッションが起動しなかったとも報告しています。
予約タスクでRemote Controlを再有効化する回避は、権限モードに関係なく断られたという報告があります。無人の実行では、この操作の許可要求が自動的に拒否されるためです。席を外している間の自動復旧は、報告の範囲では成立していません。
更新自体を止める方法はあるか
issueのコメントで挙がっている更新の止め方は、組織向けの設定キー disableAutoUpdates だけです。報告者のバンドル解析では、macOSでは管理プロファイル(MDM)の /Library/Managed Preferences/com.anthropic.claudefordesktop.plist から読み、値が入っていれば更新機能が起動しません。個人で使う人が、アプリの中から切り替える手段ではありません。
Claude Code本体の autoUpdatesChannel で stable を選べば頻度を下げられるのでは、という試みは#92207にあります。ただし、報告者自身が、デスクトップアプリの更新がこのキーを読むのかは書かれていないと述べています。キーの意味はautoUpdatesChannelの解説にまとめていますが、#92207でも、このキーでDesktopの再起動が減ったという報告は出ていません。
影響はアプリ内のセッションだけではない
#95364のコメントには、範囲の広がりを示す報告が2つあります。
- 端末で
claude remote-controlを動かしたセッションは影響を受けなかった、という報告が1件あります。一方で、launchdで常駐させたclaude remote-controlのデーモンも、再起動の瞬間に終了コード-9で落ち、再起動後は新しいデバイスIDで登録されて、元のセッションにつなぎ直せなかったという別の報告もあります。端末経由の運用が安全かどうかは、起動方法によって報告が割れています - 更新が実際には適用されない再起動もあった。ログで「保留中の版はすでに最新」と判定された30秒後に再起動が走り、版は変わらず、セッションだけが落ちたという報告です
Windows(MSIX版)でも同じ症状が出ています。Windowsの報告者は、約20時間で3回の再起動を記録し、毎回10本前後のセッションが止まったと書いています。
再現した版の範囲と、報告された修正案
issueは、macOSのClaude Desktop 2.2553.1で書かれ、その後のコメントで2.7032.0から2.42304.0、同梱のClaude Code 2.1.275から2.1.299までの再現が報告されています。再起動の開始時期については、報告者の手元のログでは2026年8月27日ごろからです。
同じ主題の別issue(#92207)は、2026年10月22日に#95364の重複として閉じられました。#95491はopenのままです。
報告者たちが挙げている修正案は、重なっています。
- Remote Controlのブリッジがつながっている間は、stealth updateを走らせない
- 再起動後に、直前までRemote Controlが有効だったセッションをつなぎ直す
- 更新を延期できる設定を、ユーザーに見える形で置く
1つ目をどこに入れるかで、直る範囲が変わります。コメントによると、stealth updateの停止条件にだけ足すと、72時間経路が残ります。両方の経路が通る「セッションが活動中かを数える判定」を直すほうが、一度で両方に効きます。
まとめ
外出先でRemote Controlに頼る使い方は、Mac側の自動更新と相性が悪いままです。更新の準備ができた日は、夜に接続が消える可能性があります。
出先で使う日は、出発前に更新を済ませておけば、その日の再起動は避けられる計算です。ただし更新は次々に出るため、確実な予防にはなりません。Claude Desktopのバージョンの確認や更新は、アップデート方法の記事に手順があります。接続が切れた後に別の警告で止まる場合は、「couldn't refresh your login」の対処も切り分けの材料になります。
修正されるまでの間、スマホ側から自力で戻す手段は報告されていません。戻せるのは、Macの前で各セッションにメッセージを送るか、バッジを押したときです。