更新 OAR 0.9.2 新增

OAR 不会在后台自我更新。中继可以查找更新的版本，在 Settings（设置）中告诉你，并在你按下 Update（更新）或运行 oar update 时安装它。没有你的参与就不会安装任何东西，而用来发现新版本的检查在你开启之前一直是关闭的。

更新检查 #

该检查默认关闭。从未被设置为其他状态的中继不会向 oar.sh 发送任何内容。

1. 打开 Settings → General（设置 → 常规）。
2. 开启 Check for updates automatically（自动检查更新）。

开启后，中继大约每天两次向 oar.sh 询问最新版本：每 12 小时一次，上下浮动最多一小时，以免许多中继同时询问。你打开开关时它也会询问一次，并且在开关开启的情况下，每次中继启动时都会询问一次。关闭开关就会停止询问。

按钮 Check for updates（检查更新）会检查一次，无论开关处于什么状态。它旁边的一行显示 Last checked <date and time> 或 Never checked.。

检查请求的内容 #

中继只请求一个文件，即清单 https://oar.sh/latest.json：一个普通的 GET 请求，带 Accept: application/json 请求头；一旦有过应答，还会带上保存上一次应答标签的 If-None-Match 请求头，这样清单未变时就不需要下载。该请求不携带任何版本、令牌、账户或机器信息。它最多等待 5 秒。除此之外不会与 oar.sh 有任何联系。安装更新时连接的是 npm 注册表，而不是 oar.sh。

清单为每个通道提供一个条目，包含最新版本、它的发布日期、指向其发布说明的链接以及标志 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 改用另一个清单。参见环境变量。

从网页界面更新 #

在 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，并安装到该包当前所在的文件夹。这涵盖了安装程序的全部三种布局：你自己的全局 npm 文件夹、你的 npm 文件夹需要 root 权限时使用的 ~/.oar/npm，以及带 OAR 自带 Node.js 的 ~/.oar/npm。在 Windows 上，它运行 PATH 中的 npm.cmd。npm 有 10 分钟时间。
2. 状态行显示 Updating to <version>…，并展开一个 Update log（更新日志），显示 npm 的输出。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。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 中，更新之前启动的 worker 无法向重启后的中继报告它的后台任务。在 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 对它都不起作用。请拉取、安装，然后用对话 ⋯ 菜单中的 🌄 Restart web relay（重启网页中继）重启中继：

git pull
npm install

参见安装。

升级说明 #

更新需要你执行的步骤，最新版本排在最前。未列出的版本不需要任何步骤。

0.9.19 0.9.19 新增 #

• 没有迁移。 退回 0.9.18 无需任何步骤：0.9.18 会忽略 heapLimitMb，diagnostics 文件夹保持原样。
• 中继现在有堆上限，接近上限时会把堆快照写入数据文件夹中的 diagnostics。快照中包含访问令牌和 API 密钥：切勿原样分享。
• 更新后请把 oar 停止并重新启动一次。 启动并看护中继的进程会保留它启动时的代码：更新带来的重启、从网页界面重启，或在没有 systemd 服务时运行 oar restart，都只会重启它里面的中继。在这个进程以 0.9.19 启动之前，中继运行时没有堆上限、heapLimitMb 和堆快照，内存耗尽的中继也仍会一直停着。在 Linux 的 systemd 服务下，运行 oar restart；否则先运行 oar stop，再运行 oar start。由 oar copilot 启动的中继，请结束那个会话并重新启动它。
• 在 0.9.19 之前启动的智能体会话保留它们的提供商列表。 它们的 worker 在更新期间继续运行，使用启动时的 relay_tool。这个列表与 0.9.19 的相同，所以现在没有任何变化；之后的更新新增的提供商不在其中，直到会话的 worker 重启，例如在 ⋯ 菜单中使用 ☠️ Kill session 之后。
• Node.js 22.13 或更高版本仍然够用。

0.9.18 0.9.18 新增 #

• 迁移 0031 到 0034 会在首次启动时自动运行：0031 为每条排队的消息标记其提供商，0032 添加计费开关所需的列，0033 和 0034 添加 Claude API 用量卡片所需的表。旧版本会忽略这些新列和新表。0031 在队列表上设置的两个触发器会继续为表中的新列写入标记，这不会造成问题。
• 智能体工具现在叫 relay_tool。 如果你自己的说明、权限规则或 hook 中提到了 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，因此仍使用密钥的对话在那里会作为 Copilot 对话运行。这也包括一开始使用订阅、后来切换到密钥的对话。
• 退回 0.9.17 会在 DeepSeek 对话中重新启用 hook。 这些对话会再次运行其设置文件夹中的 hook 和状态行；参见文件夹设置无法让 DeepSeek 改道。
• Node.js 22.13 或更高版本仍然够用。

0.9.17 0.9.17 新增 #

• 迁移 0024 到 0030 添加 DeepSeek 用量卡片所需的表：按模型和按天的花费、用作对照的余额，以及 0030 中导入的用量导出文件的数据。它们会在首次启动时自动运行，即使中继从不使用 DeepSeek 也会运行，并且不会改动旧版本使用的任何表。旧版本会忽略它们。
• 中继环境中的 Claude 登录令牌（CLAUDE_CODE_OAUTH_TOKEN）只传给 Claude 和 Claude Cloud 的 worker。 Copilot、OpenAI、Cursor、Grok 和 DeepSeek 的 worker 启动时不带它，无论是否使用 tmux。参见哪些变量会传给智能体。
• 中继环境中的 ANTHROPIC_API_KEY 和 ANTHROPIC_AUTH_TOKEN 不会传给任何 worker。 原先使用这类密钥运行的 Claude 对话，现在使用主机的 Claude 登录运行。如果主机没有登录，请在 Settings → Providers → Claude（设置 → 提供商 → Claude）下用 Relogin（重新登录）登录。参见环境变量。
• 在 Claude Code 会话内部启动的中继不再把该会话传给它的 worker。 该会话的变量对每个 worker 都会被丢弃，即使在仍带有这些变量的 tmux 服务器下也是如此。你自己的 CLAUDE_CODE_* 设置会保留。参见哪些变量会传给智能体。
• 加入你手动排序的分组的会话会排在分组的最前面，而不再排在最后。参见会话分组。
• Node.js 22.13 或更高版本仍然够用，也不需要更改任何设置或 config.json 键。

0.9.16 0.9.16 新增 #

• 三个数据库迁移会在首次启动时自动运行：0019（订阅选项以及监视者自己的提示词）、用于开关 Agents in this conversation may start sessions（允许此对话中的智能体启动会话）的 0020，以及 0021（哪些会话分组由智能体创建，以及你的哪些分组被智能体清空）。它们只添加列和一个表。退回旧版本不需要修改数据：旧版本会忽略它们，保留只有一级的规则，并像以前一样在启动时删除空分组。
• 迁移 0022 添加定时提示词的表，其中记录每个定时任务的消息来自哪里（origin_json，含经过的跳数），以及某次触发从何时起为你暂缓（held_since）。它会在首次启动时与 0019 到 0021 一起自动运行。
• 迁移 0023 添加不阻塞的提问的表（relay_asks）。它同样会在首次启动时自动运行。退回旧版本时，旧版本会忽略它。
• 订阅了 question_asked 的订阅从现在起也会收到 question_answered，即你对提问的回答。
• 循环保护只把你自己写的消息算作你的消息。 在 0.9.16 之前，中继事件、达到用量上限后的跟进消息或重启后的提示都会重置一个计数：智能体在需要询问你之前，可以向其他智能体发送多少条提示词。因此互相监视的两个智能体可以在没有你的情况下一直继续。现在只有你写的消息才会重置它，陷入这种循环的智能体会更早地询问你。参见规则。
• 智能体传入某个操作不接受的参数时：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 创建的内容。 手动编辑过的开机任务或启动器、别人创建的任务、重命名之前的开机任务以及手动创建的 Startup 条目，现在都会阻止切换，在网页界面和 oar autostart 中都是如此，而 0.9.14 会替换它们。oar autostart <mode> --replace 会替换它们，并为每一项保留一份副本。参见不是 OAR 创建的条目。
• 新命令：oar autostart 和 oar uninstall；在 Windows 上，oar setup 会询问自启动模式。参见 oar 命令。
• 包变小了：开发者 README，包括介绍 HTTP API 的 server/README.md 和网页中继扩展的 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 停止：另一个中继持有它的锁时、两个数据库都有更新的工作内容时，或无法创建它的数据或上传文件夹时。退出前的那一行会说明是哪种情况以及该怎么做。0.9.14 的 oar service install 写入的 systemd 单元不会重启它；再次运行 oar service install 即可得到该单元。参见每个数据文件夹一个中继。
• 接管大型数据库需要几分钟。 中继会记录数据库的大小、至少每分钟一次的进度以及每一步的耗时，oar start 也会在此期间说明它仍在接管。不要启动第二个中继。
• Windows 自启动现在会等待 %TEMP% 和数据所在的驱动器就绪，最多 5 分钟；更新后的首次启动会把生成的条目或启动器更新到最新。参见自启动。
• Cursor 智能体的存储移到数据文件夹中的 cursor-agents，上传文件跟随 dataDir；早期版本留在 server/uploads 或状态文件夹的 uploads/ 中的上传文件仍会在原处读取。参见文件与文件夹。
• Node.js 22.13 或更高版本仍然够用。

0.9.13 #

• 迁移 0018 添加在中继重启后保留任务控制台的表，并在首次启动时自动运行。更新之前的中继保存在内存中的已结束行，会在重启到新版本时最后一次丢失。Node.js 22.13 或更高版本仍然够用。
• 新设置位于 Settings → General：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（排队的中继重启已等待最长时间）默认开启。参见设置和等待时间很长时。
• 监视中的智能体：没有指定事件的订阅现在会略过正常结束的 shell 命令；已结束的子智能体和失败仍会唤醒它。指定了事件的订阅则保持不变。指定 task_finished 可获得每个任务的结束事件。参见默认事件。
• 不指定模型就向现有对话发送消息的脚本现在会使用该对话自己的模型、推理强度和模式，而不是中继的第一个模型；如果该模型已从模型目录中移除，则会得到 409 和错误码 CONVERSATION_MODEL_UNAVAILABLE。参见模型与推理。
• 向 relay_tool 传入模型的智能体必须使用目标列出的 id；未知的 id 现在会被拒绝，并返回 REMOTE_RELAY_UNKNOWN_MODEL。参见接受哪些模型。

0.9.12 #

• 迁移 0017 为长对话的历史记录添加两个索引，并在首次启动时自动运行。Node.js 22.13 或更高版本仍然够用，也不需要更改任何设置或 config.json 键。
• 两个新设置位于 Settings → General：Mark a background task as quiet after（后台任务多久无输出后标记为静默）（默认 10 分钟，作用于中继）和 Messages kept per conversation for switching back（每个对话保留的消息数，用于切回）（默认 200，作用于每个浏览器）。参见设置。
• 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 请求头的代理，请把这两个键添加到 config.json 并重启中继。缺少它们时，页面能加载，但收不到实时更新，而且所有客户端共用代理的地址及其登录锁定。参见另一台机器上的代理。
• 同一地址在一分钟内输入十次错误令牌后会收到 429，直到这一分钟结束。来自中继所在机器、未经任何转发的请求永远不会被计数。参见登录保护。
• ?token= 只对页面地址有效。 使用 ?token= 获取 API、文件或资源地址的脚本必须改为发送 Authorization: Bearer <token> 或使用 cookie；Socket.IO 客户端把它作为 auth.token 传递。参见出示令牌的方式。
• Restart web relay、取消排队的重启以及 Empty queue（清空队列）只需要令牌，可以在任何已登录的设备上执行。会话 worker 套接字和图片操作的执行只响应来自中继所在机器、且未经任何隧道或代理转发的请求。参见只有中继所在机器才能使用的端点。
• 四个数据库迁移（预览、会话分组、分组中的位置、分享访问日志）会在首次启动时自动运行。Node.js 22.13 或更高版本仍然够用。
• 依赖版本已固定。 OAR 直接使用的包（其中包括 Claude、Copilot 和 Cursor 的 SDK）会按该版本测试时的确切版本安装；更新的版本会随 OAR 更新一起到来。

变更内容 #

变更日志位于 oar.sh，也以 CHANGELOG.md 的形式保存在仓库中。每个版本在 GitHub 上也有发布说明，可通过 Settings → General 中的 release notes 链接打开。如果某个版本有需要你执行的更新步骤，它们位于该版本条目的 Upgrade notes（升级说明）下。

无法正常工作时 #