先看结论
用安装 OpenCode 的同一渠道完成更新
最稳妥的 OpenCode 更新是“同渠道更新”：Homebrew 安装就用 Homebrew，npm 安装就用 npm，V2 独立安装器则按官方 CLI 的升级命令操作。混用渠道容易让两个二进制同时出现在 PATH 中，结果是你更新了一个文件，却仍在运行另一个文件。
动手前运行 opencode --version，并记录系统实际找到的路径。把项目级配置、用户级配置以及工作流依赖的插件和 skills 复制到私有备份位置。备份不必很大，但要能在更新失败时还原到可工作的状态。
本文针对已经可以运行的安装做常规更新。如果你是从 V1 跨到 V2，那是主版本迁移，兼容性边界不同，请改看OpenCode V2 迁移指南。
更新 OpenCode 前先确认安装来源
不要只看命令名猜安装方式。OpenCode 可能来自 shell 安装器、npm、Bun、Homebrew、Arch 包、Windows 独立二进制，或容器镜像里的包管理器。不同来源对应不同文件位置和替换行为。
| 可能的渠道 | 检查线索 | 更新边界 |
|---|---|---|
| V2 shell 安装器 | 最初使用 opencode.ai/v2/install | 使用 V2 CLI 文档的升级流程，并重新核对二进制路径。 |
| npm | npm list -g @opencode/cli 能看到包 | 更新全局包，确认 postinstall 脚本没有被跳过。 |
| Bun、pnpm 或 Yarn | 对应全局包列表中有 OpenCode | 使用同一管理器的全局更新语法及脚本权限参数。 |
| Homebrew | brew list --formula 有 OpenCode formula | 升级已有 formula，不要额外装第二个 V2 二进制。 |
| Windows 独立程序 | where opencode 指向下载的 exe | 通过官方 Windows 下载入口替换目标文件。 |
Unix 系统可以运行 command -v opencode 和 type -a opencode 查看优先级；PowerShell 使用 Get-Command opencode | Format-List Source,Version。如果出现多个路径，先解决路径歧义，再执行更新。
按安装渠道选择 OpenCode 更新命令
下面的命令来自当前官方安装路径，可作为排查起点。包名、别名和平台支持会变化，团队机器执行前应重新打开官方页面确认。不要把所有命令连续执行，只选择与你的安装证据相符的一条。
已经安装 V2 的 CLI
V2 CLI 文档列出了 opencode upgrade，opencode update 是别名。更新后再次运行 opencode --version。如果升级命令不存在，可能仍是 V1 包，或有另一个二进制排在 PATH 前面。
opencode --version
opencode upgrade
opencode --versionnpm、Bun、pnpm 与 Homebrew
当前 V2 npm 包名是 @opencode/cli。当包管理器拥有二进制时，全局重新安装往往比手动替换更容易审计。Bun 和 pnpm 可能要求明确允许安装脚本，Homebrew 则应只升级已经存在的 formula。
npm install -g @opencode/cli
bun install -g --trust @opencode/cli
pnpm add -g --allow-build=@opencode/cli @opencode/cli
brew upgrade anomalyco/tap/opencode-v2执行后检查输出中是否有权限错误、跳过 postinstall 或安装到意外前缀。包事务成功并不等于当前 shell 已调用新文件。
Windows、容器与 CI
官方 V2 下载页列出 Windows 二进制入口，而不是承诺 Windows 包管理器。替换文件后要重新打开 PowerShell，让命令查找缓存刷新。容器和 CI 应更新镜像或锁文件并重新构建；不要在运行中的容器里临时替换文件，再把它当成可复现更新。
更新后如何核验 OpenCode
版本号只能回答“哪个可执行文件做了响应”。完整核验应覆盖更新后最容易出问题的操作。
- 确认二进制。运行
opencode --version和系统路径命令，确认它们指向同一个渠道。 - 使用低风险项目。用一次性仓库或干净分支开始，不要在生产工作区第一次尝试。
- 测试 Provider 与模型。执行只读提示、列出预期模型，确认凭据可用但不会把密钥写入日志。
- 测试权限。分别请求读取文件、提出小修改以及需要批准的命令，确认 allow/deny 规则仍然生效。
- 测试扩展。运行一个常用 agent、command、skill、MCP 服务或插件。主版本扩展可能需要单独迁移。
- 查看 diff。检查改动文件、生成物、日志和项目配置；启动成功但产生意外文件，也不能算通过。
把操作系统、shell、安装渠道、Provider、模型和测试任务写在版本旁边。下一次 OpenCode 更新时，这份短记录可以帮助你比较行为，并给团队提供明确回退点。
更新后 CLI 出错时如何回退
先停止使用问题安装，判断它属于路径、包管理器还是兼容性问题。遵守团队策略保留旧包缓存或安装器，并把配置备份与可执行文件分开保存。
命令找不到
重新打开 shell，运行 where opencode 或 command -v opencode，再与包管理器的 bin 前缀比较。shell profile 可能仍指向旧目录；先修正 PATH，不要反复安装制造更多副本。
Provider 或模型失败
对比更新前记录的配置路径和模型 ID。不要把密钥贴进 issue。若只有一个 Provider 失败，先用同一账户做只读请求，再查官方 Provider 说明，避免为了排错扩大权限。
插件或 MCP 失败
在测试项目暂时禁用扩展，确认核心 CLI 能运行，再查扩展发布说明。V1 插件不能直接用于 V2 时，请看插件指南或MCP 指南，不要盲目降级。
从 V1 跨到 V2 必须按专门的迁移和备份方案执行。常规更新排错不应悄悄变成主版本迁移。
当前 OpenCode 版本说明
2026年10月18日，第一方 OpenCode changelog 首条显示 v2.0.32，对应日期为2026年10月16日。官方下载页列出 V2 shell 安装器、npm、Bun、Homebrew、Arch 以及平台二进制。这是带日期的核验结果，不代表以后仍是最新版本。
本文不猜测直链、文件大小或安全扫描结论。请按实际平台使用官方下载入口，并在安装后记录 opencode --version 返回值。
OpenCode 更新常见问题
OpenCode 怎么更新？
先确认安装渠道并记录当前版本，再运行该渠道的更新命令。已经安装 V2 CLI 时使用 opencode upgrade，update 是别名；如果原来用 npm、Bun、pnpm、Homebrew 或官方二进制，就继续用原渠道。
OpenCode CLI 更新命令是什么？
已有 V2 CLI 使用 opencode upgrade，opencode update 是别名。如果命令不存在，检查是否是旧 V1 包，或确认 PATH 中哪个二进制优先。
如何把 OpenCode 更新到最新版本？
不存在适合所有平台的通用命令。“最新”取决于安装渠道和系统。查看官方 changelog 与下载页，通过同一渠道更新，再用二进制输出的版本号核验。
Windows 上怎么更新 OpenCode？
使用官方 Windows 下载入口获取目标架构的文件，替换预期 exe，重新打开 PowerShell，再用 Get-Command opencode 与 opencode --version 检查。
OpenCode 更新会重写配置吗？
常规 CLI 更新不应被当作配置迁移。保留备份，阅读发布说明并检查警告。V1 到 V2 有独立兼容规则，应按迁移指南执行。
应该先更新 OpenCode 还是先更新插件？
先在测试项目更新核心 CLI，再逐个检查插件、MCP、agent 和编辑器客户端。若扩展有兼容版本，单独应用并保留回退路径。
官方资料与相关指南
命令和版本说明于2026年10月18日核验。软件发布信息会变化，下一次更新前请重新打开第一方页面。