Remote Control「environment was deleted」の原因と復旧手順
サーバー終了後にclaude.ai/codeで「This session's environment was deleted」と出る現象の原因と復旧を解説します。終了の仕組み、約4時間の復帰期限、期限後の選択肢を示します。
claude remote-controlを止めたあと、claude.ai/codeやデスクトップアプリで古いセッションを開くと「This session's environment was deleted. Start a new session to keep working.」と表示され、会話の続きが打てなくなることがあります。会話の履歴は見えるのに、続行する入口だけが消えた状態です。
この表示は、GitHubのissue #101190で報告されている現象です。issueはopenのままで、修正バージョンは示されていません。この記事では、報告された再現条件、ドキュメントが定める復帰の手順と期限、期限を過ぎたあとに取れる手段を順に示します。
何が起きるか: 履歴は残るが、続きは打てない
issueの報告者は、Linux(Ubuntu)でClaude Code 2.1.296を使い、claude remote-controlをsystemdのユーザーサービスとして常駐させていました。サーバーモードで7〜32のセッションを抱えた状態です。
再現の流れは次のとおりです。
claude remote-controlをサーバーモードで動かし、複数のセッションを開く- Wi-Fiが落ちるなどして、ネットワークが10分を超えて途切れる
- サーバーが諦めてプロセスが終了する(終了コードは0)
- 約7時間後に、同じディレクトリで
claude remote-controlを起動し直す - claude.ai/codeやデスクトップアプリで古いセッションを開く
結果として、古いセッションは一覧には並ぶものの、冒頭の「environment was deleted」が出て続行できません。再起動したサーバーは新しい環境を登録し、新規のセッションだけを受け持ちます。古いセッションは、その新しい環境に引き継がれませんでした。
別の利用者も、WSL2上のsystemdユーザーサービスとClaude Code 2.1.302で同じ表示に遭遇したとコメントしています。ホストを再起動したあと、前のブリッジプロセスが受け持っていたセッションがプロジェクトのグループから外れ、汎用の「Remote Control」一覧に移り、同じメッセージが出たという内容です。
どちらの報告でも、手元の会話記録(~/.claude/projects/<project>/以下のjsonl)は無事で、claude --resumeでローカルでは続きを打てています。消えたのは、claude.ai側のセッションをつなぐ「環境」だけです。
なぜ起きるのか: サーバーが10分で諦める設計
ドキュメントのLimitations節には、ネットワーク障害時の動作がモードごとに書かれています。
長いネットワーク障害のあとの動き
サーバーモード
約10分で諦め、プロセスが終了します。続けるにはclaude remote-controlをもう一度起動して、新しいセッションを始めます。
対話セッション
手元で作業を続けられます。障害が続くかぎり再試行し、ネットワークが戻れば自動で再接続します。
つまり、無人で動かしているサーバーモードは、長い停電やWi-Fiの断絶に強くありません。プロセスが終わった瞬間から、そのプロセスが受け持っていたセッションは「応答しない」状態になります。
「environment was deleted」という文言そのものは、Remote Controlのトラブルシューティング節にも、Limitations節にも載っていません。このため、表示が出る内部の条件は、ドキュメントからは断定できません。issueの報告者も、表示の理由とその後の選択肢を画面で案内してほしいと要望しています。
約4時間以内なら、同じディレクトリで起動し直せる
ドキュメントの「Resume sessions after stopping the server」節に、サーバーを止めたあとの復帰手順があります。Ctrl+Cで止めた場合を例に、同じディレクトリで次のいずれかを実行します。
| コマンド | 戻るもの | 終了のタイミング |
|---|---|---|
claude remote-control | 戻るものサーバーが受け持っていた全セッション | 終了のタイミング通常のサーバーと同じ |
claude remote-control --continue | 戻るものサーバーが最初に始めた1セッション | 終了のタイミングそのセッションが終わったとき |
claude remote-control --session-id <id> | 戻るもの指定したIDの1セッション | 終了のタイミングそのセッションが終わったとき |
--session-idに渡すIDは、claude.ai/codeのセッションURLで/code/と?のあいだにある部分です。--continueと--session-idは、Claude Code v2.1.200以降が前提で、--spawn・--capacity・--create-session-in-dirとは組み合わせられません。
cd ~/work/my-project
claude remote-control --session-id <セッションID>ここには前提が2つあります。同じディレクトリで別のclaude remote-controlを走らせていないこと、そして--no-create-session-in-dirで起動していないことです。この条件を満たすあいだ、Claude Codeはサーバーが止まったセッションをアーカイブしません。
そして、この復帰が効く期間は、サーバーが止まってからおよそ4時間です。それを過ぎたら、新しいセッションを始めるのがドキュメントの案内です。
issueの再現では、サーバーの再起動が約7時間後でした。ドキュメントが示す4時間を超えています。ただ、4時間を過ぎたことと「environment was deleted」の表示が結びつくのかは、issueのやり取りからは分かりません。復帰を試すなら、止まってからなるべく早く同じディレクトリで起動し直すのが筋です。
アーカイブ済みのセッションでも、v2.1.228以降なら--continueと--session-idがアーカイブを解除します。アーカイブされたセッションは、claude.ai/code/sessionsの「Archived」タブでも確かめられます。
4時間を過ぎたら: 取れる手段は3つ
期限を過ぎたセッションを、claude.ai側で元どおり生き返らせる手段は、ドキュメントにもissueにもありません。issueの報告者が求めているのは「新しい環境に再接続する操作」で、これは機能要望(ラベルはenhancement)として扱われています。
現実的な選択肢は次の3つです。
- ローカルで続ける: 手元の端末で
claude --resumeを使い、会話記録から作業を再開します。記録はjsonlで残っています。 - 新しいセッションで引き継ぐ:
claude remote-controlで新しいセッションを始め、直前の状況を最初のメッセージで伝えます。変更済みのファイルはディスクに残っているので、git diffの出力を渡すと状況が伝わります。 - 対話セッションに切り替える:
claude --resumeで再開した会話に/remote-controlを実行し、新しいRemote Controlセッションとして使います。
どれも元のclaude.ai側セッションの続きではなく、同じ作業内容を別のセッションで続ける形です。なお、3の方法には注意点があります。ドキュメントの「Previous session is unavailable」の節によると、再起動せずに/remote-controlを実行すると、新しいセッションに以前のメッセージが入りません。
常駐運用で踏みやすい穴: 終了コード0
issueの副次的な指摘も、常駐運用では見逃せません。ネットワーク障害で諦めたサーバーが終了コード0で終わるため、systemdのRestart=on-failureでは再起動されないというものです。報告者はラッパースクリプトで回避したと書いています。
終了コード0でも再起動したいなら、Restart=alwaysを使う方法が考えられます。次はあくまで例です。パスや間隔は環境に合わせて変えてください。
[Service]
WorkingDirectory=%h/work/my-project
ExecStart=/usr/bin/env claude remote-control
Restart=always
RestartSec=30ただし、自動で再起動できても、前のプロセスが受け持っていたセッションは「environment was deleted」になることがある、というのがissueの核心です。再起動は新しい環境を作るだけで、古いセッションは戻りません。復帰の期限を考えると、再起動の間隔を短くして4時間以内に同じディレクトリでclaude remote-controlが立ち上がるようにするほうが、復帰の可能性を残せます。
systemdのユニットファイルの作り方はClaude CodeでsystemdのUnitファイルを作成する手順に手順があります。サーバーモードが止まる別の原因は、could not renewの警告と26時間の猶予や、--sandboxフラグの削除によるエラーでも起きます。
切り分けの順番
表示が出たら、次の順で確かめると無駄がありません。
「environment was deleted」が出たときの確認順
- Qサーバーを止めてから4時間を過ぎているか答えが過ぎていない答えがはい
同じディレクトリで
claude remote-control(または--continue、--session-id)を実行します。戻らないときは、--session-idのIDの取り違えや、別のclaude remote-controlが同じディレクトリで走っていないかを見ます。 - Q起動し直しても古いセッションが戻らないか(4時間を過ぎている場合は「はい」)答えが戻った答えがはい
そのまま作業を続けられます。
ローカルで続ける
claude --resumeで会話記録から再開し、必要なら/remote-controlで新しいセッションとして公開し直します。
常駐サーバーと対話セッションのどちらで動かすか
コメントした利用者は、常駐サーバー、remoteControlAtStartupによる対話セッション、再開したセッションの3つが、それぞれ別の同一性の規則を持っていると指摘しています。再起動1回で、重複したセッション、孤立したセッション、削除された環境が同じ作業に対して生まれることがある、という見立てです。
ドキュメントも、サーバーモードと対話モードで障害時の動きを分けており、モードの違いが復旧の可否を左右する構造は変わっていません。夜通し動かす用途ならサーバーモード、手元の作業を外から見たいだけなら対話セッション、と目的で選び分けると、今回のような落とし穴を避けやすくなります。無効化の設定や自動で有効になる原因はRemote Controlの無効化設定の記事で扱っています。
まとめ
「environment was deleted」は、サーバーモードのプロセスが終わったあとに、古いセッションをつなぐ環境が見つからなくなった状態の表示です。ただし、この文言の意味と出る条件はドキュメントに載っていないため、断定はできません。
止まってから約4時間以内なら、同じディレクトリでのclaude remote-control、--continue、--session-idで戻せます。4時間を過ぎていたら、ローカルのclaude --resumeが最も確実な続け方です。issueがopenのうちは、新しい環境へ付け替える操作は用意されていません。常駐運用では、終了コード0で止まる点と4時間の期限を前提に、再起動の仕組みを組む必要があります。