Remote Controlでunarchiveしたセッションが「Sending…」で止まる

claude.aiでアーカイブしたRemote Controlのセッションを、あとから解除して使い直そうとすると、メッセージが「Sending…」のまま約2分止まり、最後に「Claude Code on 〈マシン名〉 is offline」と表示される。この症状が、GitHubのclaude-codeリポジトリのissue #98310に報告されています。issueは2026年10月10日時点でopenです。

対象は claude remote-control をサーバーモードで常駐させ、同じディレクトリでセッションを起動する構成です。ホスト側は接続も待ち受けも正常なのに、解除したセッションにだけ仕事が割り当てられません。

どんな症状が出るのか

issueの再現手順は次の流れです。報告者は3つの別セッションで毎回再現したと書いています。

「offline」と出ても、ホストが落ちているわけではありません。報告では、ホストは待ち受け（work/poll）を続け、ログには「no work」の空ポーリングが100回以上並びます。同じ環境で、アーカイブしていない別のセッションにメッセージを送ると、約1秒で作業が割り当てられて子プロセスが起動したとのことです。

つまり症状の切り分けは単純です。新しく作ったセッションは動くのに、解除したセッションだけが動かないなら、この報告と同じ型です。

issueから読み取れる原因

issueの報告者は、通信の記録（ブラウザのHARとホストのデバッグログ）から原因を絞っています。

• 解除のリクエスト（POST /v1/code/sessions/session_…/unarchive）は200で成功する
• 返ってきたセッションは status: active だが、connection_status は disconnected、worker_status は WORKER_STATUS_UNSPECIFIED
• ブラウザはWebSocketを開いて initialize の制御リクエストを2回送り、その後は keep_alive だけを送る。応答は何も来ず、ユーザーのメッセージ自体も送信されない
• 単にアイドルなだけのセッション（ホスト再起動後など）は worker_status が idle で、メッセージを送れば復帰する

報告者の見立ては、アーカイブ解除の経路に、ホストの環境へセッションを再キューする手順が抜けているというものです。ホストが起動時やハートビート回復時に使う bridge/reconnect を呼ぶと即座に直る、という観察が根拠になっています。これは報告者による分析で、実装側の説明ではありません。

メッセージを別経路で積んでも効果はありませんでした。解除したセッションに claude -p "continue" --cloud cse_… を送ると {"ok":true} が返りますが、やはりホストに作業は届きません。

同じ症状の追加報告

issueには2件のコメントが付いています。

元の報告はClaude Code 2.1.283のLinuxです。3件を合わせると、バージョンもOSも違う環境で出ています。修正済みのバージョンは、このissueからは分かりません。

1件目の報告には、もう一つ見逃せない点があります。アーカイブした覚えがなくても、ホスト側が「archived」を理由に終了指示を受けることがあり、その直後に解除されたセッションが同じ状態に陥った、という流れです。手動でアーカイブしていないセッションでも、この症状に当たる可能性があるということです。

回避策と、それぞれの代償

issueと追加コメントに挙がっている回避策は4つあります。いずれも報告者が試した結果で、公式の手順ではありません。

新しいセッションで済ませる場合

作業の続きだけが目的なら、新しいセッションを開いて、前の会話の要点を最初のメッセージに貼るのが現実的です。ローカルの会話履歴は claude --resume から開けるので、Remote Controlのセッションに依存した作業でなければ、手元で続ける手もあります。

--session-idで戻す場合

公式ドキュメントには、サーバーを止めたあとの再開手順として次の記載があります。

claude remote-control --session-id <id>

<id> はclaude.ai/codeのURLの /code/ から ? の手前までの部分です。ドキュメントによれば、サーバー停止から約4時間は有効で、アーカイブ済みのセッションはv2.1.228以降なら --continue と --session-id で解除されます。

ただし、この手順は「サーバーを止めたあと」を前提に書かれています。常駐ホストが動いたまま同じ環境で実行すると拒否された、という報告がissueにあります。使うなら、ホストを止めてから実行する形になり、他のセッションも一緒に止まります。

bridge-pointer.jsonを書き換える場合

2件目のコメントの手順は次のとおりです。

1. セッションを解除する（解除してから時間が経つと、死んだままのセッションはサーバー側で再度アーカイブされるように見える、との指摘があるため、直前に行う）
2. ~/.claude/projects/<プロジェクトのディレクトリ>/bridge-pointer.json の sessionId だけを session_<id> に書き換える
3. claude remote-control を再起動する

報告では、再起動の約3秒後にセッションが立ち上がり、元の会話の文脈を保ったまま、停止中に積んでいたメッセージに応答したとのことです。ただし、ホストの再起動が1回ごとに必要で、同じホストが抱える他の生きたセッションもすべて落ちます。モバイルやWebで「閉じる」操作にあたるのはアーカイブだけなので、誤ってアーカイブすると、その都度ホストの再起動が必要になる、という指摘も付いています。

同じ通信記録に出ていた2つの副次的な問題

報告者は、同じ記録から小さな問題を2つ挙げています。

• 解除直後の古い読み取り: アーカイブ解除のリクエストが返る前に、セッション取得のリクエストが飛び、status: archived が返る。UIが「This session is archived」のまま残り、もう一度解除ボタンを押すまで変わらないことがある
• 死んだセッションの再採用: ホストは起動のたびに bridge-pointer.json に記録されたセッションへ bridge/reconnect を呼ぶ。数週間前にアーカイブ済みでも再キューされ、直後に end_session（理由 archived）が送られて子プロセスが終了コード1で落ち、Session failed: Process exited with error がホストの再起動ごとに記録される

1つ目は「解除したのに戻らない」と見えたとき、もう一度ボタンを押すだけで済む場合があるという話です。本題の症状と見分ける目安は、解除後の画面がまだ「archived」を示しているかどうかです。「Sending…」まで進んでいるなら、本題の症状です。

手元で切り分けるには

接続全般の切り分けはRemote Controlに接続できないときの見分け方と対処にまとめています。ここでは、この症状に固有の判断だけを挙げます。

放置時間による切断が原因のこともあります。その場合はRemote Controlが20分放置で切断される原因と回避策の症状と比べてください。セッションを見分けたいときはClaude Codeでセッションを見分ける方法が役立ちます。

修正を待つあいだの運用

この不具合が避けにくいのは、モバイルとWebではアーカイブが事実上唯一の「閉じる」操作だからです。Remote Controlを使わない設定にする方法はClaude Code Remote Controlの無効化設定と既定で有効になる経緯にあります。

• 常駐ホストで運用するなら、使い終わったセッションのアーカイブは、再利用しないと決めたものだけにする
• 再利用したい会話は、アーカイブせず放置するか、ローカルの claude --resume で続ける
• 解除したセッションが動かないときは、ホストを再起動する前に、まず新しいセッションで作業が進められるかを見る

issueはopenで、公式の見解や修正バージョンはまだ付いていません。同じ症状に当たったときは、#98310のコメントで最新の状況を見られます。