再起動と再開

会話にはそれぞれ専用のエージェントがあり、リレーのマシン上のバックグラウンドプロセスで動いています。会話そのもの（履歴、キュー、下書き）はリレーにあります。このページでは、この 2 つがどう組み合わさっているかを説明します。これにより、Kill session（セッションを強制終了）、リレーの再起動、マシンの再起動で何を失い、何が自動で戻ってくるかが分かります。

要点：書いたものは何も失われません。会話のエージェントが動いていなければ、次のメッセージでエージェントが再び起動します。エージェントは空のセッションではなく、プロバイダー自身のセッションを続けます。

会話のエージェントプロセス #

OAR はこのプロセスをセッションワーカーと呼びます。自分で起動する必要はありません。会話で必要になったとき（通常は最初のメッセージで）リレーが起動し、ワーカーはリレーに接続し直してメッセージを受け取り、返信を報告します。tmux がインストールされた Linux と macOS では、ワーカーはデタッチされた tmux セッションで動き、⋯ メニューの Inspect tmux console（tmux コンソールを確認）でその 1 つを表示できます。tmux がない場合は、通常のバックグラウンドプロセスとして動きます。

0.9.11 で追加 ワーカーはどのプラットフォームでも、リレー自身の Node.js をフルパスで指定して動きます。そのため、リレーの PATH に node がなくても起動します。誰もサインインする前に Windows の起動タスクで起動したリレーなどがこれに当たります。別の Node.js は COPILOT_WEB_RELAY_NODE で指定できます（環境変数）。ワーカーの PATH に node がない場合は、その Node.js のフォルダーが末尾に追加されるので、ワーカーが起動する CLI やコマンドも Node.js を見つけられます。

ワーカーを起動できない場合、会話にメモが表示されます。

The worker for this conversation could not be started (2 tries). Cause: <reason>. Your message stays queued; the relay tries again every 1 minute until 14:20 UTC.

リレーは 10 分間、毎分再試行します。その後、メモは再試行をやめたことを伝え、Retry（再試行）ボタンを表示します。その間ずっとメッセージはキューに残り、ワーカーが起動するとすぐに配信されます。Windows では、失敗した起動や応答が返らない起動はすぐに失敗となり、プログラム名が示されます。リレーのログには、そのコマンドと起動時の PATH が記録されます。

自動で停止する場合 #

Claude と DeepSeek の会話、および SDK エンジンの GitHub Copilot と OpenAI の会話は、何も起きていないときにメモリを解放します。10 分間アクティビティがないとエージェント自身のプログラムが終了し、次のメッセージで再び起動して同じプロバイダーのセッションを続けます。ワーカープロセスは残り、リレーとの接続も維持します。アプリにはこの 10 分を変える設定はありません。

次のいずれかが進行中の間は、エージェントは停止しません。

• そのエージェントのターンが実行中またはキューに入っている
• 質問カードや権限のカードが回答を待っている
• バックグラウンドタスクが実行中である、または終わったばかりのタスクの継続がまだ予定されている

バックグラウンドタスクだけでエージェントを動かし続けられるのは、Settings → General（設定 → 一般）の Background task timeout（バックグラウンドタスクのタイムアウト）までです（既定は 4 時間、0 は無制限）。

0.9.17 で追加 DeepSeek の会話では、モデルや reasoning effort を変更したときにもエージェントのプログラムが再起動します。Claude Code はこの 2 つを起動時にしか読み込まないためです。再起動は次のターンの前、プログラム内で何も実行されていないときに行われ、同じセッションを続けます。プログラム内でバックグラウンドの作業がまだ動いている間は、ターンはそのままのプログラムで実行されます。新しいモデルはそこで切り替わり、新しい effort は再起動まで待ちます。

ほかのプロバイダーには、このようなアイドル時の停止はありません。Claude Cloud、Cursor、Grok のワーカーは、セッションを強制終了するか、会話をアーカイブするか、マシンが停止するまで動き続けます。Copilot の拡張機能エンジンも Copilot CLI を動かし続けます。30 分間使われていない Cursor のワーカーはエージェントのハンドルを閉じ、次のメッセージで同じ Cursor エージェントを開き直します。

Kill session #

会話の ⋯ メニュー、またはリストの行のメニューにある Kill session は、ワーカーとそれが起動したプロセスを停止します。会話が止まってしまったとき、エージェントが Stop（停止）に反応しないとき、または新しいツールや設定を読み込ませるためにエージェントを新しく起動したいとき（例：エージェントのセッションを有効にした後）に使います。

最初に確認が表示されます。

Kill the session for <title>?
This stops the current worker and any active turn will need a manual retry or a new message.

その後、短い通知に Session killed.（セッションを強制終了しました。）と表示されます。稼働中のプロセスが見つからなかった場合は、代わりに Session state cleared; no live worker process was found. と表示されます。試行後もプロセスが残った場合は、アラートに Failed to kill session（セッションを強制終了できませんでした）と表示され、何もクリアされません。

実行中だったターンは、会話内のメモ This session was killed from the relay UI before the turn completed. で終わります。メッセージをもう一度送るか、新しいメッセージを書いてください。会話、その履歴、キューに入っているメッセージは残ります。次のメッセージで新しいワーカーが起動し、プロバイダーのセッションが再開されます。

会話をアーカイブしてもワーカーは停止します。会話リストを参照してください。

エージェントに接続できないとき #

10 秒間どのワーカーからも報告がないと、会話の上にバナーが表示され、サイドバーのステータス行が CLI offline（CLI オフライン）になります。

⚠️ CLI is offline — messages will queue until it reconnects

このバナーは 1 つの会話ではなくリレーに属するもので、アイドル状態が続いたリレーでは正常な場合もあります。送ったメッセージは保持されます。メッセージを 1 つ送ってください。リレーが会話のワーカーを起動し、ワーカーが接続するとバナーは消えます。消えない場合は、リレーのログフォルダーにある worker-<session>.log を確認してください。場所はファイルとフォルダーにあります。

接続を失ったワーカー（例：リレーの再起動中）は、試行の間隔を最大 8 秒あけながら再接続を試み続けます。0.9.13 で追加 また、15 秒以内に完了しない接続は打ち切り、終了中のリレーが接続を閉じるのを待たないので、再起動が止まってもワーカーが次の試行をできなくなることはなくなりました。失敗した試行ごとに、理由を含む worker ws disconnected 行が worker-<session>.log に書き込まれます。最初の 3 回分と、その後は 1 分に最大 1 回です。0.9.11 で追加 安全策として、メッセージがワーカーを待っている間にそのワーカーが 60 秒間接続していない場合、リレーはワーカーを置き換えます。古いプロセスを停止して新しいプロセスを起動し、新しいプロセスがメッセージを受け取ります。そのセッションのターンやバックグラウンドの作業が動いている間は決してこれを行わず、行ったときは WORKER DETACHED 行をログに記録します。

リレーの再起動 #

新しいバージョン、変更した設定ファイル、新しくインストールしたプロバイダーの CLI を読み込むには、リレーを再起動します。会話の ⋯ メニューで 🌄 Restart web relay（Web リレーを再起動）を選ぶか、リレーのマシンで oar restart を実行します。oar update と、Settings → General の Update（更新）ボタンは、インストール後に自動で再起動します。

再起動が待つもの 0.9.13 で追加 #

🌄 Restart web relay は、まず再起動が何を待ち、何を動かしたままにするかを表示します。

• 実行中のターンがあるセッション（それぞれのタイトル付き）
• それまでに保留するメッセージの数
• バックグラウンドタスク（コマンド、モニター、サブエージェント）があるセッション。それぞれ動き続けるか、may stop（停止する場合あり）かが示されます。以前の再起動からリレーが引き継いだタスクで、ワーカーがまだ確認していないものは、未確認として表示されます。

ターンが実行中の場合、ウィンドウには再起動をキューに入れる 🌄 Restart when idle（アイドル時に再起動）と、待たずに再起動する Restart now（今すぐ再起動）が表示されます。何も実行されていない場合、ボタンは 🌄 Restart web relay で、リレーはすぐに再起動します。

再起動は実行中のターンを待つ #

再起動がターンを中断することはありません。Restart when idle で再起動がキューに入り、接続中のすべてのデバイスのすべてのページにバナーが表示されます。

🌄 Relay restart queued — waiting for 2 sessions · waited 4 min of 30 min
Waiting for: Review: server/, Build docs (2 turns)
New messages are held until the restart: 3 messages waiting.

セッション名は会話を開くリンクです。セッションにバックグラウンドの作業がある場合は、その後に Background tasks:（バックグラウンドタスク：）の行が続き、それぞれが動き続けるかどうかが示されます。バナーには 2 つのボタンがあります。

• Restart now は、まず確認を求め、待たないセッションを示してから再起動します。それらのワーカーは動き続け、再起動したリレーに報告を返します。リレーが不在の間はターンのライブ出力が止まり、返信が届かなかったターンはもう一度送る必要があります。Linux のサービスでは、ワーカーがリレーとともに停止する場合があり、ウィンドウにその旨が表示されます。
• Cancel restart（再起動を取り消す）は再起動を取り消します。保留されていたメッセージはすぐに送られます。

再起動を保留させるのは実行中のターンだけです。再起動がキューに入っている間に送ったメッセージはキューで待機し、エージェントには渡されません。そのため、忙しいリレーが再起動を何度も先送りすることはありません。それらのメッセージは再起動後に実行されます。エージェントが応答しなくなったターンは、リレーの無活動の時間枠（既定は 10 分、processingTimeoutMs）が過ぎると打ち切られ、それ以降は再起動を保留させません。

待ち時間が長いとき 0.9.13 で追加 #

キューに入った再起動が待つのは、最大で Settings → General の Ask after a queued relay restart has waited（キューに入れたリレー再起動の待機後に確認する）までです。既定は 30 分で、5、10、15、30 分、1、2、4 時間、または No limit（上限なし）を選べます。その時間が過ぎると、バナーは質問に変わります。

🌄 The relay restart has waited 30 min for 2 sessions — restart now, keep waiting or cancel?

Restart now、Keep waiting (30 min)（待ち続ける、30 分）、Cancel restart が表示されます。Keep waiting は、その時点からもう 1 期間まるごと待ち、再び確認します。通知を有効にしたデバイスにも、Relay restart waiting（リレーの再起動待ち）というタイトルの通知が届きます。

質問の有無にかかわらず、ターンの実行中にリレーが自動で再起動することはありません。また、最後のターンが終わればすぐに再起動します。No limit の場合、キューに入った再起動とそれが保留するメッセージは、実行中のターンが終わるか、自分で決めるまで待ちます。変更した設定は、すでにキューに入っている再起動にも適用されます。

何も実行されていない場合、バナーには Relay restarting now… と表示され、リレーはすぐに戻ってきます。開いているデバイスでは、短い接続の切断と、最初のワーカーが報告するまでの間 CLI is offline のバナーが表示されることがあります。

リレーを oar start やターミナルで起動した場合、oar restart も同じように動作します。再起動をキューに入れるので、バナーと最大待ち時間後の質問もこれに適用されます。最大 1 分待った後、リレーがまだ忙しく、ターンが終わると自動で再起動することを伝えます。oar stop も同じように最大 30 秒待ちます。リレーを systemd のサービス（oar service install）として動かしている場合、oar restart と oar stop は systemd を経由してすぐに動作し、ターンを待ちません。そのとき実行中のターンは終了し、後述のとおりに扱われます。

0.9.11 で追加 サインイン済みのブラウザーなら、どれでも再起動をキューに入れたり取り消したりできます。必要なのはアクセストークンだけです。リレーが拒否した場合は、ページにその理由が表示されます。ホストのターミナルからなら、oar restart はいつでも使えます。

0.9.13 で追加 リレーの再起動を頼まれたエージェントも同じように再起動をキューに入れ、再起動が何を待つか、どのメッセージを保留するか、どのバックグラウンドタスクが動き続けるかを知らされるので、それを伝えることができます。エージェントには、待機を決して省略しないよう指示されています。待たずに再起動するのは Restart now であり、それは利用者自身が決めることです。

再起動で残るものと失われるもの #

残るもの：

• 会話とその履歴
• キューに入っているメッセージ（再起動を待っていたものを含む）
• 入力欄の下書きと添付ファイル
• 0.9.11 で追加 プレビュー（起動時に再確認されます）
• 0.9.11 で追加 動き続けるワーカーのバックグラウンドタスク
• 0.9.13 で追加 タスクコンソール：完了した行はその 1 時間の残りの間、実行中のコマンドの出力も残ります
• エージェントがほかのセッションを監視するために設定した購読
• エージェントがセッションの開始について得た承認
• 使用量の上限による一時停止
• 会話のプロバイダーのセッション

失われるもの：

• キューに入っている Suspend host（ホストをスリープ）（Windows）。リレーはこれを破棄し、その旨を伝えます
• 再起動によって停止したワーカーのバックグラウンドタスク（Linux のサービスの場合。下記を参照）

リレーを oar start やターミナルで起動した場合、リレーは終了時にワーカーを停止しません。ワーカーは接続が切れたことに気づき、新しいリレーに接続し直します。oar service install のサービスは異なります。サービスがほかに何も指定していないため、systemd はワーカーを含め、サービスが起動したものをすべて停止します。その後、各会話への次のメッセージで新しいワーカーが起動し、会話は以下で説明するとおりに続きます。

停止したときに実行中だったターン #

計画的な再起動はターンを待つので、ここで扱うのは Restart now、クラッシュ、強制終了、停電、マシンの再起動です。

リレーは、ワーカーが報告するまでターンを実行中として扱います。ワーカーが報告しなくなった場合、リレーは無活動の時間枠（既定は 10 分、processingTimeoutMs。ワーカーがまったく接続していない場合は最大 45 秒）を待ってから、メッセージをキューに戻します。メッセージは新しいワーカーに再び配信され、新しいワーカーはプロバイダーのセッションを再開するので、エージェントはそれまでの会話を覚えています。エージェントがすでに変更したファイルは変更されたままです。

• メッセージがキューに戻されるのは最大 maxRequeueRetries 回（既定は 5）です。それを超えると Relay recovery limit reached … Send it again to retry. で失敗します。
• バックグラウンドタスクの後にエージェント自身が開始したターン（継続）はキューに戻されません。破棄されます。もう一度実行すると、エージェント自身への通知をユーザーのプロンプトのように渡してしまうためです。
• SDK エンジンの Copilot は、再起動中にリレーが受け取れなかった完了済みの返信を保持し、最大 5 分間それを再び提供します。そのため回答は失われず、プロンプトが 2 回実行されることもありません。

再起動の間も動き続けたワーカーは、そのターンを保持します。新しいリレーに報告を返し、ターンは続きます。

中断されたセッションに続行を指示する 0.9.13 で追加 #

エージェントがすでにメッセージを受け取っていたために、もう一度実行できないターンもあります。作業中に送ったメッセージ、継続、またはワーカーがそのターンなしで戻ってきたときにすでに始まっていたターンです。このようなターンはそのまま止まり、エージェントは中断されたことを知りません。

Settings → General の After a relay restart, tell interrupted sessions to carry on（リレーの再起動後、中断されたセッションに続行を指示する）を有効にすると（既定はオフ、リレーの設定です）、このようなセッションはリレーが戻ったときにリレーからメモを 1 つ受け取ります。会話にはコンパクトな relay（リレー）の行として表示され、エージェントは次の内容を読みます。

Automatic message from OAR, not from the user: the relay restarted at 2026-10-20 14:05 UTC, and the turn you were working on was interrupted before it finished. Check where you were (the files you changed, the commands and background tasks you started) and carry on from there. Do not repeat steps that already completed; if the work was already done, say so briefly.

• 自分のメッセージが再送されることはありません。また、1 つのセッションが受け取るメモは再起動ごとに最大 1 つです。
• アイドル状態のセッション、自動で再実行されるターン、アーカイブされた会話には何も送られません。使用量の上限による一時停止がセッションを止めている間も送られません（その一時停止自体のフォローアップがターンを続けます）。
• その間にキューに入れたメッセージが先に処理され、メモはその後ろで待ちます。
• メモは通常のメッセージと同じようにセッションのエージェントを起動します。対象になるのは、リレーの起動から 30 分以内に中断されたターンです。

この設定がない場合は、「続けて」のような短いメッセージを自分で送ってください。

プロバイダー別 #

会話とキューは、どのプロバイダーでもリレーが保持します。プロバイダーが何を保持するか、つまり再開した会話が何から続くかは異なります。OpenAI Image の会話にはワーカーがありません。リレー自身が Images API を呼び出すので、このページの内容はどれも当てはまりません。