OAR の更新 0.9.2 で追加

OAR はバックグラウンドで自分自身を更新しません。リレーは新しいリリースを探して Settings（設定）で知らせ、Update（更新）を押すか oar update を実行したときにインストールします。あなたの操作なしにインストールされることはなく、リリースを見つける確認も、有効にするまではオフです。

更新の確認 #

確認は既定でオフです。設定を変えたことのないリレーは、oar.sh に何も送信しません。

1. Settings → General（設定 → 一般）を開きます。
2. Check for updates automatically（自動で更新を確認）をオンにします。

オンにすると、リレーは 1 日に約 2 回、oar.sh に最新バージョンを問い合わせます。間隔は 12 時間で、多くのリレーが同時に問い合わせないよう最大 1 時間前後ずらします。スイッチをオンにしたときにも 1 回、スイッチがオンの状態でリレーが起動するたびにも 1 回問い合わせます。スイッチをオフにすると問い合わせは止まります。

Check for updates（更新を確認）ボタンは、スイッチの状態にかかわらず 1 回確認します。その横の行には Last checked <date and time> または Never checked. と表示されます。

確認時のリクエスト内容 #

リレーが要求するファイルは 1 つ、マニフェスト https://oar.sh/latest.json だけです。Accept: application/json ヘッダー付きの単純な GET で、前回の応答があればそのタグを入れた If-None-Match ヘッダーも付けるので、マニフェストが変わっていなければダウンロードは発生しません。リクエストにはバージョン、トークン、アカウント、マシンの情報は含まれません。待つのは最大 5 秒です。oar.sh とのやり取りはこれ以外にありません。更新のインストールでは、oar.sh ではなく npm レジストリと通信します。

マニフェストにはチャンネルごとのエントリがあり、最新バージョン、そのリリース日、リリースノートへのリンク、フラグ critical が含まれます。

{
  "schemaVersion": 1,
  "channels": {
    "stable": {
      "version": "0.9.19",
      "publishedAt": "2026-10-27T06:23:15.940Z",
      "notesUrl": "https://github.com/oar-sh/oar/releases/tag/v0.9.19",
      "minNode": "22.13",
      "critical": false
    }
  }
}

リレーは自分のチャンネルのエントリ（チャンネルを参照）を読み、そのチャンネルのエントリがなければ stable のエントリを読みます。minNode はそのリリースが動く最も古い Node.js を示しますが、リレーもインストーラーもこれを読みません。

自動の確認が失敗した場合（ネットワークがない、タイムアウト、不正な応答）は何も表示せず、次の間隔で再試行します。Check for updates をクリックして使える応答が得られなかった場合は、通知 Update check failed — the update server could not be reached. が表示されます。schemaVersion が 1 以外のマニフェストを受け取ると、リレーは再起動するまで確認を止め、ボタンの横の行に The relay could not read the update feed — try updating manually. を追加します。

新しいバージョンが見つかったとき #

新しいバージョンは、Settings → General の Check for updates の下に行として表示されます。

OAR 0.9.19 available

この行には release notes（リリースノート）のリンクと、Update と Dismiss（閉じる）のボタンがあります。ほかの場所にバナーやバッジは出ません。確認がオフのときは新しいバージョンが分からないので、何も表示されません。Dismiss は、さらに新しいバージョンが出るまでそのバージョンを非表示にします。critical とされたリリースは OAR 0.9.19 available — critical update と表示され、非表示にはできませんが、これも自動でインストールされることはありません。git チェックアウトでは行に Update ボタンがなく、This relay runs from a git checkout — pull and restart to update. と表示されます。

確認を完全に無効にする #

リレーの環境で OAR_NO_UPDATE_CHECK=1 を設定します。するとリレーは、Check for updates を押したときも含め、一切リクエストを送りません。スイッチとボタンは無効になり、Update checks are disabled by OAR_NO_UPDATE_CHECK in this relay's environment. と表示されます。--to なしの oar update も拒否されます。OAR_UPDATE_MANIFEST_URL を使うと、リレーと oar update が別のマニフェストを参照します。環境変数を参照してください。

Web UI から更新する #

Settings → General で Update を押します。これはグローバルインストール（インストーラーや npm install -g で行うインストール）で使えます。

1. リレーが npm install -g --allow-scripts=@oar-sh/oar,better-sqlite3,koffi @oar-sh/oar@<version> を実行します（0.9.14 で追加 以降はリストに @oar-sh/oar が含まれます。npm でインストールを参照）。macOS と Linux では、リレーを動かしている Node.js の隣にある npm を使い、パッケージがすでにあるフォルダーにインストールします。これでインストーラーの 3 つの配置すべてに対応します。自分のグローバル npm フォルダー、npm フォルダーに root が必要だった場合の ~/.oar/npm、OAR 独自の Node.js を使う場合の ~/.oar/npm です。Windows では PATH 上の npm.cmd を実行します。npm に与えられる時間は 10 分です。
2. ステータス行に Updating to <version>… と表示され、npm の出力を含む Update log（更新ログ）が展開されます。Cancel update（更新を取り消す）で npm を停止できます。
3. npm が終わると、行は npm finished — the relay restarts once the running turns finish. になります。リレーは自身に再起動を要求します。実行中のターンは待ち、その間に送ったメッセージはキューで待機して再起動後に実行されます。接続中のすべてのデバイスにバナーが出て待機中であることを示し、Restart now（今すぐ再起動）と Cancel restart（再起動を取り消す）が表示されます。0.9.13 で追加 Ask after a queued relay restart has waited（キューに入れたリレー再起動の待機後に確認する）の時間（既定は 30 分）が過ぎると、今すぐ再起動するか、待ち続けるか、取り消すかを尋ねます。再起動と再開を参照してください。
4. リレーが再起動し、ページは自動で再接続します。この再起動は systemd などのサービスマネージャーを経由しません。自動起動を参照してください。

npm が失敗すると、行は Update failed: <reason> になり、ログに理由が表示されます。リレーは古いバージョンのまま動き続けます。

リレーによる結果の確認 #

再起動の前に、リレーはインストールしようとしたバージョンを記録します。次の起動時に、それを実行中のバージョンと比べます。一致すれば Updated to <version>. と表示されます。一致しない場合（例：npm がパッケージを置き換えなかった）は、Update to <version> did not apply. と npm ログの末尾が表示されます。7 日より古い記録はメッセージなしで破棄されます。行の横の Dismiss で表示を消せます。

ターミナルから更新する #

oar update

マニフェストで自分のチャンネルの最新バージョンを調べ、npm install -g でインストールし、実行中のリレーにキューがアイドルになったら再起動するよう要求します。新しいものがなければ Already up to date (<version>). と表示します。オプションと終了コードは oar update にあります。

特定のバージョン（古いバージョンも可）をインストールするには、フラグの後にスペースを空けて指定します。

oar update --to 0.9.9

--to は npm レジストリを読み、マニフェストを使わないので、OAR_NO_UPDATE_CHECK=1 でも動きます。--to=0.9.9 ではなく --to 0.9.9 と書いてください。前者は無視され、自分のチャンネルの最新リリースがインストールされます。

インストーラーを使う方法もあります。インストーラーはパッケージを入れ直すので、もう一度実行すれば更新になります。インストールを参照してください。

チャンネル #

チャンネルは stable と beta の 2 つです。beta バージョンは 0.9.19-beta.1 のような形で、同じ番号の stable リリースより低いバージョンとして扱われます。

リレーにチャンネルの設定はありません。実行中のバージョンのチャンネルに従います。beta バージョンなら beta、それ以外は stable です。これはリレー自身の確認にも oar update にも当てはまります。

beta のリレーには、実行中のものより新しい限り、マニフェストが beta に載せているバージョンが提示されます。beta のエントリが stable リリースを載せている場合（0.9.19 では両方のエントリがそうなっています）、beta のリレーはそのリリースに移り、以降は stable に従います。古いバージョンに移るには --to が必要です。

更新で変わらないもの #

実行中だったセッション #

再起動は実行中のターンがなくなるまで待ち、その後リレーが新しいコードで起動し直します。更新前に起動したエージェントのプロセスは、再び起動するまで古いコードのままです。セッションのエージェントは起動時に自分のツールを把握します。0.9.10 のリリースが一例です。更新前から動いていたセッションでは、エージェントが再起動するまで remote_relay（現在の relay_tool）の subscribe も usage も使えません。0.9.11 では、更新前に起動したワーカーは、再起動したリレーにバックグラウンドタスクを報告できません。0.9.12 では、コマンドのコンソールには更新後に起動したエージェントが必要で、タスクパネルの Grok のターミナルも同様です。0.9.13 では、tail にパイプしたコマンドの印に更新後に起動したエージェントが必要です。エージェントがコマンドラインを報告するためです。アイドル状態のセッションで Kill session（セッションを強制終了）を使うとセッションが再起動し、次のメッセージで新しいエージェントが起動します。再起動と再開を参照してください。

プロバイダーの CLI #

OAR が更新するのは自分自身だけです。Claude、Grok、GitHub Copilot のコマンドラインツールは別のプログラムです。プロバイダーの CLI のインストールと更新を参照してください。

知っておくと便利なこと #

• グローバルインストールでの Cursor。 0.9.14 で追加 Cursor のエージェントストアはリレーのデータフォルダー内の cursor-agents にあるので、更新で置き換えられることはなくなりました。0.9.14 より前は既定でパッケージフォルダー内にあり、更新でストアが削除された会話には新しいエージェントが割り当てられました。ファイルとフォルダーと Cursor を参照してください。
• Windows。 グローバルインストールでは、リレーはパッケージフォルダーではなく OAR の状態フォルダー（%APPDATA%\oar）から動くので、リレーの実行中でも更新でパッケージを置き換えられます。自動起動のエントリはインストール済みのパッケージを起動します。自動起動を参照してください。

git チェックアウト #

チェックアウトは自分自身を更新することはなく、Update も oar update も使えません。pull してインストールし、会話の ⋯ メニューの 🌄 Restart web relay（Web リレーを再起動）でリレーを再起動します。

git pull
npm install

インストールを参照してください。

アップグレードの注意点 #

更新時に必要な作業を、新しいリリースから順に示します。載っていないリリースでは作業は不要です。

0.9.19 0.9.19 で追加 #

• マイグレーションはありません。 0.9.18 に戻すときも手順は不要です。0.9.18 は heapLimitMb を無視し、diagnostics フォルダーはそのまま残ります。
• リレーにヒープ上限が設けられました。 上限に近づくと、データフォルダー内の diagnostics にヒープスナップショットを書き出します。スナップショットにはアクセストークンと API キーが含まれるため、そのまま共有しないでください。
• 更新後に一度 oar を停止して起動し直してください。 リレーを起動して見守るプロセスは、起動したときのコードを使い続けます。更新による再起動、Web UI からの再起動、systemd サービスなしでの oar restart は、そのプロセスの中のリレーだけを起動し直します。このプロセスが 0.9.19 で起動するまで、リレーはヒープ上限、heapLimitMb、ヒープスナップショットなしで動き、メモリが不足したリレーは停止したままです。Linux の systemd サービスでは oar restart を実行します。それ以外では oar stop の後に oar start を実行します。oar copilot で起動したリレーは、そのセッションを終了して起動し直してください。
• 0.9.19 より前に起動したエージェントのセッションは、プロバイダーの一覧を保ちます。 それらのワーカーは更新中も動き続け、起動時の relay_tool を使います。その一覧は 0.9.19 のものと同じなので、今は何も変わりません。後の更新で加わるプロバイダーは、セッションのワーカーが再起動するまで一覧にありません。ワーカーは、たとえば ⋯ メニューの ☠️ Kill session の後に再起動します。
• Node.js 22.13 以降で引き続き十分です。

0.9.18 0.9.18 で追加 #

• マイグレーション 0031 から 0034 までが最初の起動時に自動で実行されます。0031 はキューに入った各メッセージにプロバイダーを記録し、0032 は課金の切り替えの列を追加し、0033 と 0034 は Claude API の使用状況カードのテーブルを追加します。古いバージョンは新しい列とテーブルを無視します。古いバージョンでも、0031 がキューのテーブルに設定する 2 つのトリガーはその新しい列への記録を続けますが、害はありません。
• エージェントツールの名前が relay_tool になりました。 独自の指示、権限ルール、フックで remote_relay や mcp__relay__remote_relay を指定している場合は、relay_tool または mcp__relay__relay_tool に変更してください。名前を参照してください。
• 0.9.17 に戻す前に、Claude API のキーで動いている Claude のチャットを Subscription に戻してください。 0.9.17 は Claude API を知りません。知らないプロバイダーのチャットを Copilot に結び付けるので、キーのままのチャットは 0.9.17 では Copilot のチャットとして動きます。サブスクリプションで始めてキーに切り替えたチャットも含まれます。
• 0.9.17 に戻すと、DeepSeek のチャットでフックが再び有効になります。 設定フォルダーのフックとステータスラインが再び実行されます。フォルダーの設定で DeepSeek の向け先は変えられないを参照してください。
• Node.js 22.13 以降で引き続き十分です。

0.9.17 0.9.17 で追加 #

• マイグレーション 0024 から 0030 までは DeepSeek の使用状況カードのテーブルを追加します。モデル別と日別の支出、その基準となる残高、そして 0030 では取り込んだ使用状況エクスポートの数値です。DeepSeek を使わないリレーでも最初の起動時に自動で実行され、古いバージョンが使うテーブルには触れません。古いバージョンはこれらを無視します。
• リレーの環境にある Claude のログイントークン（CLAUDE_CODE_OAUTH_TOKEN）は、Claude と Claude Cloud のワーカーにだけ届きます。 Copilot、OpenAI、Cursor、Grok、DeepSeek のワーカーは、tmux の有無にかかわらず、このトークンなしで起動します。エージェントのワーカーに届く変数を参照してください。
• リレーの環境にある ANTHROPIC_API_KEY と ANTHROPIC_AUTH_TOKEN は、どのワーカーにも届きません。 そのようなキーで動いていた Claude のチャットは、ホストの Claude のサインインで動くようになります。ホストがサインインしていなければ、Settings → Providers → Claude（設定 → プロバイダー → Claude）の Relogin（再ログイン）でサインインしてください。環境変数を参照してください。
• Claude Code のセッション内から起動したリレーは、そのセッションをワーカーに引き渡さなくなりました。 そのセッションの変数はすべてのワーカーで除かれ、まだそれを保持している tmux サーバーの下でも同様です。独自の CLAUDE_CODE_* 設定は残ります。エージェントのワーカーに届く変数を参照してください。
• 手動で並べ替えたグループに加わったセッションは、グループの先頭に置かれます。 以前のように最後にはなりません。セッショングループを参照してください。
• Node.js 22.13 以降で引き続き十分で、設定や config.json のキーを変更する必要もありません。

0.9.16 0.9.16 で追加 #

• 3 つのデータベースマイグレーションが最初の起動時に自動で実行されます。0019 は購読オプションと見守る側自身のプロンプト、0020 はスイッチ Agents in this conversation may start sessions（この会話のエージェントにセッションの開始を許可）、0021 はエージェントが作成したセッショングループとエージェントが空にしたあなたのグループのためのものです。追加するのは列とテーブルだけです。古いバージョンに戻してもデータの変更は不要です。古いバージョンはこれらを無視し、1 階層のルールを守り、以前と同じく起動時に空のグループを削除します。
• マイグレーション 0022 は予約プロンプトのテーブルを追加し、各予約のメッセージの出どころ（origin_json、経由したホップを含む）と、発火があなたのために保留された時刻（held_since）も記録します。最初の起動時に、0019 から 0021 までと一緒に自動で実行されます。
• マイグレーション 0023 は作業を止めない質問のテーブル（relay_asks）を追加します。これも最初の起動時に自動で実行されます。古いバージョンに戻すと、このテーブルは無視されます。
• question_asked を受け取る購読には、今後 question_answered（質問へのあなたの回答）も届きます。
• ループ防止は、あなた自身のメッセージだけをあなたのメッセージとして数えます。 0.9.16 より前は、リレーイベント、使用量の上限後のフォローアップ、再起動後のメモによって、あなたに確認が求められるまでにエージェントがほかのエージェントへ送れるプロンプトの数がリセットされていました。そのため、互いを見守る 2 つのエージェントがあなた抜きで続けられることがありました。現在はあなたが書いたメッセージだけがカウントをリセットし、このようなループに入ったエージェントは早めにあなたに確認します。ルールを参照してください。
• アクションが受け付けない引数を渡すエージェント： create_session と update_session はその呼び出しを拒否し、何も変更しなくなりました。ほかのアクションはこれまでどおり実行され、その引数を ignored に示します。アクションを参照してください。
• 自分のプロンプトへの返信を待っていた見守る側には、そのターンの turn_end がイベントとして重ねて届くことはなくなりました。
• Node.js 22.13 以降で引き続き十分で、設定や config.json のキーを変更する必要もありません。

0.9.15 #

• 0.9.14 から更新し、Windows で手作りの自動起動タスクを使っている場合： 0.9.14 で起動時モードに切り替えると、同じ名前の既存のタスク（oar-relay、または名前変更前のもの）がコピーなしで削除されることがありました。0.9.15 はそのようなタスクを残し、--replace を求めます。このオプションは先にコピーを保存します。タスクがすでに消えている場合、OAR にそのコピーはありません。
• 自動起動の切り替えで、OAR が作成していないものを置き換えることはなくなりました。 手で編集した起動タスクやランチャー、ほかの人が作成したタスク、名前変更前の起動タスク、手作りのスタートアップのエントリがあると、Web UI でも oar autostart でも切り替えが止まります。0.9.14 ではこれらを置き換えていました。oar autostart <mode> --replace を使うと、それぞれのコピーを残して置き換えます。OAR が作成していないエントリを参照してください。
• 新しいコマンド： oar autostart と oar uninstall が加わり、Windows では oar setup が自動起動のモードを尋ねます。oar コマンドを参照してください。
• パッケージが小さくなりました。 開発者向けの README（HTTP API を説明した server/README.md と、Web リレー拡張機能の README）はパッケージに含まれなくなりました。これらは GitHub のリポジトリにあります。
• Node.js 22.13 以降で引き続き十分で、設定や config.json のキーを変更する必要もありません。

0.9.14 #

0.9.14 はインストール中に、まずそのデータを OAR のデータフォルダー（%APPDATA%\oar\data、~/.oar/data）内の rescued-package-data/<time>/ にコピーし、リレーは次の起動時にそのコピーを引き継ぎます。npm 10 と 11 はこのコピーを実行し（11.21 では警告付き）、失敗した場合は古いバージョンをデータごと元に戻します。npm 12 は @oar-sh/oar が許可されていない限りこれをスキップします。その場合、インストールは成功し、古いデータは失われます。strict-allow-scripts を使うと、npm 11 と 12 はインストールを拒否し、何も変更しません。.npmrc の allow-scripts エントリは、0.9.13 の Update ボタンや oar update には効きません。それら自身の --allow-scripts がエントリを置き換えるためです。安全のため、この更新は手動で行ってください。

1. すべての gh copilot セッションを閉じ（その拡張機能がリレーを再び起動するため）、oar stop を実行して、oar status が実行中でないと示すまで待ちます。0.9.13 の oar stop がシステム起動時のランチャーが起動したリレーを停止しない場合は、インストールの前にリレーを終了してください。タスクマネージャーでリレーのプロセス（OAR を実行している node.exe）を終了します。
2. npm root -g を実行し、<that folder>/@oar-sh/oar/server（通常は %APPDATA%\npm\node_modules\@oar-sh\oar\server）を開きます。data と uploads の両方のフォルダーを、中のファイルすべてと一緒に安全な場所にコピーします。
3. npm のインストールスクリプトを許可して更新します：npm install -g --allow-scripts=@oar-sh/oar,better-sqlite3,koffi @oar-sh/oar。--ignore-scripts では絶対に更新しないでください。コピーとネイティブモジュール（better-sqlite3、koffi）がスキップされ、その後リレーが起動できなくなります。
4. リレーを起動する前に、両方のフォルダーを同じ server フォルダーにコピーして戻します。
5. oar start を実行します。OAR の logs フォルダーにある relay-console.log で [data] Brought over the database … を探します。会話が戻っているはずです。すでに OAR のデータフォルダーにあったデータベースは、OAR フォルダー（%APPDATA%\oar、~/.oar）内の backups/<time>/ に保存されます。引き継がれたフォルダーのデータベースは copilot.db.adopted-<time> として、確認されたほかのフォルダーのデータベースは copilot.db.older-<time> として残ります。何も削除されません。
6. リレーが [data] Not starting: each database has changes newer than the other's で停止した場合は、両方に作業が含まれています。この行には両方のフォルダーが示され、一方は rescued-package-data/<time>/data の下にあることがあります。残す方を選び、もう一方の copilot.db、copilot.db-wal、copilot.db-shm を自分で用意したフォルダーに移動して（削除はしないでください）、もう一度 oar start を実行します。
7. 保存せずにすでに更新してしまい、何もコピーされなかった場合、OAR はパッケージからデータベースを復元できません。

0.9.14 のその他の変更：

• データを使って動けないリレーは終了コード 78 で停止します。 別のリレーがロックを保持している場合、2 つのデータベースの両方に新しい作業がある場合、データフォルダーやアップロードフォルダーを作成できない場合です。終了の直前の行に、どれに当たるかと対処方法が示されます。0.9.14 の oar service install が書き出す systemd ユニットは、この場合にリレーを再起動しません。このユニットに入れ替えるには、oar service install をもう一度実行してください。データフォルダーごとに 1 つのリレーを参照してください。
• 大きなデータベースの引き継ぎには数分かかります。 リレーはそのサイズ、少なくとも 1 分に 1 回の進捗、各ステップの所要時間をログに記録し、その間 oar start はまだ引き継ぎ中であることを示します。2 つ目のリレーを起動しないでください。
• Windows の自動起動は、%TEMP% とデータドライブを最大 5 分間待つようになりました。また、更新後の最初の起動で、生成されたエントリやランチャーを最新の状態にします。自動起動を参照してください。
• Cursor のエージェントストアはデータフォルダー内の cursor-agents に移り、アップロードは dataDir に従います。以前のバージョンが server/uploads や状態フォルダーの uploads/ に残したアップロードは、その場所のまま読み込まれます。ファイルとフォルダーを参照してください。
• Node.js 22.13 以降で引き続き十分です。

0.9.13 #

• マイグレーション 0018 は、リレーの再起動をまたいでタスクコンソールを保持するテーブルを追加し、最初の起動時に自動で実行されます。この更新前のリレーがメモリに保持していた終了済みの行は、この更新への再起動で最後にもう一度失われます。Node.js 22.13 以降で引き続き十分です。
• 新しい設定が Settings → General に 2 つ追加されました。Ask after a queued relay restart has waited は既定で 30 分、After a relay restart, tell interrupted sessions to carry on（リレーの再起動後、中断されたセッションに続行を指示する）は既定でオフです。新しい通知 Queued relay restart waited its maximum time（キュー中のリレー再起動が最大待機時間に達した）は既定でオンです。Settings（設定）と待ち時間が長いときを参照してください。
• 見守るエージェント： イベントを指定していない購読は、正常に終わったシェルコマンドを除外するようになりました。終了したサブエージェントと失敗はこれまでどおり購読を起こします。イベントを指定した購読はそのままです。すべてのタスクの終了を受け取るには task_finished を指定してください。既定のイベントを参照してください。
• モデルを指定せずに既存の会話へメッセージを投稿するスクリプトは、リレーの最初のモデルではなく、その会話自身のモデル、effort、モードを使うようになりました。そのモデルがカタログからなくなっている場合は、コード CONVERSATION_MODEL_UNAVAILABLE 付きの 409 が返ります。モデルと推論を参照してください。
• relay_tool にモデルを渡すエージェントは、対象が一覧に載せている id を使う必要があります。不明な id は REMOTE_RELAY_UNKNOWN_MODEL で拒否されるようになりました。受け付けられるモデルを参照してください。

0.9.12 #

• マイグレーション 0017 は長い会話の履歴用に 2 つのインデックスを追加し、最初の起動時に自動で実行されます。Node.js 22.13 以降で引き続き十分で、設定や config.json のキーを変更する必要もありません。
• 2 つの新しい設定が Settings → General に追加されました。Mark a background task as quiet after（バックグラウンドタスクを無出力と見なすまでの時間）はリレーの設定で既定は 10 分、Messages kept per conversation for switching back（切り替えて戻るために会話ごとに保持するメッセージ数）はブラウザーごとの設定で既定は 200 です。Settings（設定）を参照してください。
• Claude のバックグラウンドコマンドは、既定で 2 時間、Claude が求めた場合は最大 8 時間実行できます：Settings → Providers → Claude → Claude background command limit（設定 → プロバイダー → Claude → Claude のバックグラウンドコマンド上限）。OAR は Claude のセッションに BASH_DEFAULT_TIMEOUT_MS、BASH_MAX_TIMEOUT_MS、CLAUDE_CODE_AUTO_BACKGROUND_TIMEOUT_MS を設定するようになったため、リレーの環境にあるこれらの値は適用されなくなりました。バックグラウンドコマンドの上限を参照してください。
• 更新中に動いているセッションは、エージェントが再び起動するまでそのエージェントを使い続け、それまではコマンドのコンソールに出力が表示されません。実行中だったセッションを参照してください。

0.9.11 #

• 別のマシン上のリバースプロキシの背後では、trustProxy と allowedOrigins を設定してください。 0.9.11 は、ライブ接続のオリジンを確認し、プロキシが信頼されている場合にだけ X-Forwarded-* ヘッダーからクライアントのアドレス、ホスト、スキームを読む最初のリリースです。リレーと同じマシン上のプロキシやトンネルは最初から信頼されています。別のマシン上のプロキシや、Host ヘッダーを書き換えるプロキシの場合は、この 2 つのキーを config.json に追加してリレーを再起動してください。これがないと、ページは読み込まれてもライブ更新が届かず、すべてのクライアントがプロキシのアドレスとそのサインインのロックアウトを共有します。別のマシン上のプロキシを参照してください。
• 1 つのアドレスから 1 分以内に 10 回誤ったトークンが送られると、その 1 分が終わるまで 429 が返ります。 何も転送していない、リレー自身のマシンからのリクエストは数えられません。サインインの保護を参照してください。
• ?token= はページのアドレスでだけ使えます。 API、ファイル、アセットのアドレスを ?token= で取得するスクリプトは、代わりに Authorization: Bearer <token> かクッキーを送る必要があります。Socket.IO クライアントは auth.token として渡します。提示する方法を参照してください。
• Restart web relay、キューに入った再起動の取り消し、Empty queue（キューを空にする）に必要なのはトークンだけになりました。 サインイン済みのどのデバイスからでも使えます。セッションワーカーのソケットと画像操作の実行は、トンネルやプロキシが転送していない、リレーのマシンからのリクエストにだけ応答します。リレーのマシンだけが使えるエンドポイントを参照してください。
• 4 つのデータベースマイグレーション（プレビュー、セッショングループ、グループ内の位置、共有のアクセスログ）が最初の起動時に自動で実行されます。Node.js 22.13 以降で引き続き十分です。
• 依存関係のバージョンが固定されました。 OAR が直接使うパッケージ（Claude、Copilot、Cursor の SDK を含む）は、リリースのテストに使った正確なバージョンでインストールされます。新しいバージョンは OAR の更新と一緒に届きます。

変更内容 #

変更履歴は oar.sh と、リポジトリの CHANGELOG.md にあります。各リリースには GitHub のリリースノートもあり、Settings → General の release notes リンクで開けます。更新時に必要な作業がある場合は、リリースのエントリの Upgrade notes（アップグレードの注意点）に記載されています。

うまくいかないとき #