OpenClaw 2026.8.2 更新：Linux 桌面版、后台 Session 与升级恢复有哪些变化

GitHub 在 2026-09-01T16:00:56Z 发布了 v2026.8.2，当前它是 prerelease: false 的最新稳定版。

先把一个容易误判的版本号问题说清楚：GitHub 上虽然存在 v2026.9.1-beta.1，但官方已经明确把它改名并说明为 误发的 2026.8.1-beta.4。它不能作为“比 8.2 更前沿”的依据。当前版本判断请看版本中心。

先说结论：值不值得升级

如果你是新安装用户，直接从 2026.8.2 开始，没有必要先装 8.1 再升。

如果你已经稳定运行 2026.8.1，是否马上升级主要看四件事：

1. 你是不是 Linux 桌面用户。
2. 你是否经常并行创建、浏览和管理多个 Session。
3. 你是否使用 Chrome Extension、第三方插件或自研 Plugin SDK。
4. 你的 Gateway 是否多人共享，或有大量 cron Session。

对前两类用户，8.2 有直接可见的产品变化。对后两类用户，升级价值之外更重要的是重新检查权限和恢复流程。

生产、共享 Agent、重度插件和无人值守环境不建议只看版本号直接切主节点；先在副本验证 Session visibility、plugin capability review、migration 和 rollback。

1. 2026.8.2 最值得普通用户关注的变化

如果不逐条翻译 changelog，我认为这次可以压缩成五组变化：

• Linux 正式有 Desktop Companion。
• Control UI 更适合同时管理 Home 和后台工作 Session。
• 同 Agent Session 的默认可见范围变大，需要共享环境重新审视隔离。
• Chrome Extension 的本地 relay 可以在特定条件下独立唤醒，但 Gateway browser control 仍然存在。
• update / doctor / plugin finalization 的失败恢复路径变得更明确。

8.1 更像建立 OpenClaw 2.0 的新基线，8.2 则开始把“桌面使用、并行工作、升级恢复”补得更完整。

2. Linux Desktop Companion：Linux 不再只有 CLI 和 Docker

这是最容易被旧教程漏掉的一项。

v2026.8.2 的官方 GitHub Release 提供：

• OpenClaw-2026.8.2-amd64.deb
• OpenClaw-2026.8.2-amd64.AppImage

当前是 x86-64 / amd64 Linux 桌面资产。官方 Linux 专页说明，Desktop Companion 可以连接：

• 本地 Gateway
• 自动发现的远端 Gateway
• 手工填写的 remote Gateway
• SSH 连接的 Gateway

并可以从系统托盘或 X11 keyboard shortcut 打开 Quick Chat。

Desktop Companion 不等于 Gateway

这个区别值得单独强调。

Companion 是桌面入口和连接管理层；真正承载模型、Session、渠道和服务状态的仍是 Gateway。需要在 Linux 桌面本机运行 Gateway 时，Companion 会把本地服务管理交给 CLI-managed systemd user service。

连接远程 Gateway 时，不需要为了“有 GUI”再在笔记本上额外跑一套本地 Gateway。

需要先装 Node.js 吗

如果你走独立 CLI / Gateway 路径，当前 Node 要求仍是：

• 22.22.3+
• 24.15+
• 25.9+（包含 Node 26）
• 推荐 Node 26

但 Linux Companion 的官方文档说明：当 local setup 需要 CLI / Node 时，它可以安装 private managed runtime。因此普通桌面用户并不需要先全局配好 Node 和 OpenClaw CLI 才能安装 Companion。

官方文档有一个小的同步差异

版本特定的 8.2 Release Notes、Linux 专页和 GitHub release assets 都已经确认 Linux Companion 正式发布。如果你看到某个更宽泛的 Platforms overview 仍写 “Linux companion planned”，应把它视为没有同步到 8.2 的旧概览，而不是当前发布状态。

具体安装命令和 .deb / AppImage 注意事项已经更新到安装中心。

3. Control UI：Home Dock、New Session 与后台 Session

8.2 的 Control UI 越来越不像“只有一个聊天框的 Dashboard”。

Home 可以停靠在当前工作旁边

Home conversation 可以在右侧或底部 Dock 打开，不需要离开正在看的页面。还可以预览或移除当前 work-context snapshot，或把选中文本附到消息里。

这对“边看一个项目 / Session，边让 Home Agent 帮我判断下一步”的使用方式更自然。

New Session 可以直接放到后台运行

从 New Session 创建工作后，可以让它在后台继续，并保留选择的 local、cloud 或 paired-device placement。完成后再从通知进入对应 Session。

这不是单纯多一个按钮。真正的价值是：前台 UI 不再等同于唯一正在工作的 Session。

Session 浏览和管理也继续加强

8.2 继续补齐：

• 更清晰的 Session action menus
• transcript 复制为 Markdown
• tab / window / split 打开
• icon / color 管理
• 分组与隐藏空组
• cross-session forwarded message 的来源与发送 Agent 标识

如果你已经把 OpenClaw 用成项目工作台，而不是偶尔问几句话，这类变化会比新增一个模型 provider 更容易每天感知到。

4. tools.sessions.visibility：这是本次最需要共享环境注意的安全变化

官方 8.2 Release Notes 明确调整了默认行为：

unsandboxed Session 默认 tools.sessions.visibility = "agent"。

当前 Session tools 文档解释为：同一个 Agent 下，普通 unsandboxed Session 可以列出、读取、搜索、发送消息和管理其他同 Agent Session，包括 retained cron Session。

如果多个用户共享同一个 Agent，这也可能包含其他用户的会话。

这不是“所有会话互相可见”

需要把风险描述准确：

• sandbox 的默认 session-tool clamp 仍会限制范围。
• incognito Session 仍对 cross-session tools 隐藏。
• 普通 cross-agent 访问仍受 agent-to-agent policy 约束。

所以问题不是“OpenClaw 把所有人的聊天公开了”，而是：同 Agent 这个原本常被当作逻辑边界的范围，现在默认更宽。

tree 和 self 怎么选

官方当前范围是：

• agent：当前 Agent 的全部 Session，8.2 默认。
• tree：当前 + spawned tree；但从 canonical main 调用时，仍有同 Agent 的例外范围。
• self：严格只允许当前 Session，包括 main。

如果你明确要求“一个普通 Session 不能看另一个 Session”，尤其是共享 Agent / 多用户环境，self 才是最清晰的严格边界。

session.dmScope 解决的是 DM routing / 会话键隔离，不能代替 tools.sessions.visibility。升级后应该把两者分别检查。

5. Chrome Extension：Gateway 不运行时能唤醒 relay，但别理解过头

8.2 的 Release Notes 提到：受支持的 macOS / Linux Chrome Extension 构建可以在 Gateway 未运行时唤醒 paired local relay。

成立需要几个条件：

• native host 已安装
• Automatic local setup 开启
• 扩展构建本身支持 relay wake-up
• 已有有效 pairing

当前推荐的普通安装顺序是先运行：

openclaw browser extension install

让 OpenClaw 预注册 native host，再安装官方 Chrome Web Store extension。旧教程里把 Load unpacked 当普通用户默认步骤，现在已经不合适；它主要是 development fallback。

standalone relay 不等于 OpenClaw browser 脱离 Gateway

这是最重要的边界。

官方 browser CLI 文档明确说明：authenticated CDP client 可以使用 standalone relay，但 openclaw browser actions 仍需要 Gateway browser control。

所以不要写成“8.2 以后 Chrome Extension 完全不需要 Gateway”。准确说法是：relay 的可用性和 Gateway browser control 被进一步拆开了。

Windows 当前仍以 manual pairing 为主，不能直接照搬 macOS / Linux automatic bootstrap 流程。

站内原有的网页读取方案对比已经同步更新这部分旧教程。

6. 升级恢复：8.2 更重要的是“失败后知道停在哪一步”

对已经在跑 OpenClaw 的人，这部分价值可能比 Linux GUI 更高。

8.2 的 updater 会更谨慎地处理：

• 新配置不被旧 migration 覆盖
• Session migration 没完成时不假装升级成功
• 已停止 Gateway 的安全恢复
• doctor repair 与 updater restart 顺序
• plugin setup / capability review

核心思路是：core package 安装成功，不代表整次升级已经完成。

插件、registry、doctor repair、managed service 和 Session migration 都可能在后半段失败。

openclaw update repair 用在什么场景

当 core package 已经变更，但后续这些工作没有完成时：

• doctor repair
• tracked plugin sync
• managed npm plugin metadata
• missing configured plugin payload repair
• plugin registry refresh

官方支持的恢复入口是：

openclaw update repair

它会运行 openclaw doctor --fix 并重新完成 update finalization。

两个边界必须知道：

1. 它不会再安装一个新的 core package。
2. 它不会自行重启 Gateway。

这比“再跑一次完整 update”更适合已经安装到新 core、但后处理失败的现场。

完整步骤见故障排查中心：OpenClaw 升级失败怎么恢复。

7. cleanup：先 dry-run，而且不是修复命令

8.2 提供更明确的 migration-original cleanup：

openclaw update cleanup --dry-run

这个 dry-run 用来预览 retained migration originals。

真正 apply cleanup 之前要知道：

• 目标 Gateway 需要停止。
• 当前 SQLite history 会保留。
• 被删除 originals 对应的 rollback 会永久失去。
• 它不是你的备份系统。

因此正确顺序不是“升级失败 → cleanup”，而是：

升级 / repair 成功 → 验证数据和 Gateway → 确认备份 → cleanup dry-run → 最后才决定是否应用。

只要你还在排查 migration，就不要急着删除回滚材料。

8. Plugin capability 与 SDK migration：两个问题不要混在一起

capability review 是运行权限问题

插件新版本如果声明新的 capability，8.2 会要求 operator review。没有完成 review 时：

• --yes 不会自动视为批准。
• 之前可用的插件可以被保留。
• 本次请求的 Gateway restart 可以被阻止。
• core 已更新时可以通过交互式 openclaw update repair 继续完成 finalization。

这意味着插件升级不能只看“版本号有没有变”，还要看 declared capability surface 有没有扩大。

SDK deprecation 是代码兼容问题

官方 Plugin SDK migration guide 当前明确说：

已经移除的入口包括：

• openclaw/plugin-sdk root
• openclaw/plugin-sdk/compat
• openclaw/extension-api
• api.registerEmbeddedExtensionFactory(...)

继续依赖这些入口的插件需要迁移，否则不能按“只是 warning”处理。

但是 8.1 里写着 2026-09-01 removal target 的 5 个兼容 subpath，在 2026.8.2 仍然保留且继续 deprecated：

• config-runtime
• channel-reply-pipeline
• infra-runtime
• channel-lifecycle
• channel-message

所以 2026-09-01 更准确地说是一个计划移除 / compatibility checkpoint，而不是“到了 9 月 1 日它们已经从 8.2 package 消失”。

插件作者仍然应该马上迁移，因为保留兼容不等于长期承诺。

9. 哪些人建议尽快升级

新用户

直接装当前稳定版即可。

Linux x86-64 桌面用户

8.2 首次给了正式 Desktop Companion，升级价值最直接。

经常并行跑多个工作 Session 的用户

后台 Session、Session 管理和 Home Dock 会改善实际工作流。

之前正好遇到 update / migration / plugin finalization 问题的人

8.2 补了多项恢复和错误收敛逻辑，值得在备份后优先验证。

10. 哪些环境建议先测试

多用户共享同 Agent

先验证 tools.sessions.visibility，不要默认沿用之前的隔离预期。

大量 cron / 自动化 Session

retained cron Session 也进入同 Agent 默认范围，需要先看是否符合你的权限模型。

自研或重度第三方插件

先检查 SDK imports、capability review 和更新后 runtime registration。

无人值守生产 Gateway

先在副本跑完 update、repair、restart、渠道与回滚演练，再切主节点。自动更新最怕的不是“安装包下载失败”，而是 core 已经变了、后处理没有收敛。

11. 升级前 checklist

• 记录 openclaw --version。
• 记录当前 update channel 与安装方式。
• 备份配置、状态、关键 workspace 与可用的 rollback 材料。
• 列出关键插件 / Skills 与安装来源。
• 如果多人共用 Agent，记录当前 Session isolation 预期。
• 运行 openclaw update --dry-run，确认目标与 restart 计划。
• 自研插件先查 Plugin SDK migration guide。
• 生产环境准备一个低风险验证任务和明确停止条件。

12. 升级后 checklist

openclaw --version
openclaw doctor
openclaw gateway status --deep
openclaw plugins list --enabled --verbose

然后确认：

• 版本确实是目标 stable。
• Gateway 能稳定运行，服务 ownership 没有被意外替换。
• Session migration 没有残留阻塞。
• tools.sessions.visibility 符合共享环境预期。
• 关键插件 runtime 注册正常，capability review 已明确处理。
• 常用模型和渠道完成一条低风险测试。
• Chrome Extension 用户确认 native host / relay / Gateway 的边界正常。
• 暂时不要 cleanup；先运行一段时间并确认备份。

如果 core 已升级但 finalization 没完成，走 openclaw update repair，不要连续覆盖安装。

13. 官方来源与核验说明

本文只用 OpenClaw 官方 GitHub Release、官方 Release Notes 和 docs 确认版本、安装要求、权限默认值、升级命令与 SDK 状态，没有用第三方文章补足这些事实。

截至 2026-09-02，本站采用的版本结论是：

• Stable：v2026.8.2
• GitHub published_at：2026-09-01T16:00:56Z
• v2026.9.1-beta.1：官方确认误发，实际是 2026.8.1-beta.4
• 8.2 没有一份官方统一标题为 “Breaking Changes” 的列表，但 Session visibility 默认值、plugin capability restart gate 和不可逆 cleanup 都值得按行为兼容变化处理

后续如果官方再发布新的 stable / prerelease，实时结论以版本中心重新核验为准。