OpenCode 密钥泄露影响范围辨析

2026-10-17，一则「OpenCode 被黑、用户凭据泄露」的消息，让不少人先怀疑起每天使用的 CLI。原文划出的边界很明确：暴露的是托管服务 OpenCode Console，不能据此认定本地 CLI 中的密钥也遭到泄露。

作者花了二十分钟核对自己的使用路径。对程序员更有用的，是这套判断方法：密钥交给了谁、请求发往哪里、磁盘还留着多少副本，以及出了事该到哪里撤销。

Console 和 CLI，密钥到底交给了谁

据原文转述，厂商承认一个正在退役的旧系统遭到未授权访问，保存在 workspace 中的第三方 provider 密钥可能暴露，包括 OpenAI、Anthropic。厂商要求用户到对应 provider 撤销并替换密钥，更新使用方，再检查近期用量。

一位 OpenAI 客户还贴出了收到的邮件：存储客户 API keys 的系统遭到未授权访问，该组织的一把密钥受到影响，而且已被禁用。这支持了事件涉及真实凭据暴露的判断，但原文没有给出完整影响范围。

Console 的设计解释了风险从何而来。用户连接已经付费的 provider 账户，Console 在服务端保存凭据，再通过 gateway 向整个 workspace 共享模型。保存密钥就是这项服务的一部分。

本地 CLI 的路径不同：凭据放在用户磁盘上，请求发往配置指定的 base URL。目标可能是厂商托管 gateway、本地代理，也可能是第三方 API。

判断自己是否受到这次事件影响，要同时看是否向 Console 托管过密钥，以及实际使用的配置。

原文提到，讨论串获得了 975 分，有 37 条顶层评论，大量争论围绕「究竟哪个产品出了事」。共用一个名字，却没有在通告开头说清系统边界，让用户承担了额外的排查成本。

作者核对了什么，这些检查能证明多少

作者每天使用 CLI，但从未向 Console 连接 provider。他检查了三项 provider 配置，分别对应一个 gateway、一个模型实验室和一个托管服务商；三条路径都指向 loopback 上的进程，也就是本机回环地址上的服务。

这说明，在作者检查的请求路径里，密钥先交给他运行的代码，而非由 Console 托管。它不能自动证明这些本地进程后续如何转发，也不能替代对其他使用路径的检查。

另一项检查是寻找密钥副本。作者扫描了 38,734 个文件，耗时约一分钟。代码仓库、曾经提交后又删除的 .env、shell history，都可能留下第二份凭据。删掉当前工作区里的文件，不代表提交历史里的内容也消失了。

作者还发现了两个 auth 文件，其中备份文件为三个 provider 中的一个保留了不同的密钥值。2026-10-20 发生过一次轮换，但旧值仍在磁盘上。他尚未删除这份备份，因为还要向 gateway 确认旧值确实失效。

配置目录本身也是一个公开仓库，共有 49 个已跟踪文件。auth 文件目前没有被跟踪，但一次疏忽的 git add -A 仍可能把凭据带进去。

原文把这部分称为四项检查，却没有附出完整命令、扫描工具和逐项输出。能借用的是检查思路，不能把它当成已经提供好的审计脚本。

本地明文和代理隔离，分别挡得住什么

作者的三把密钥都以明文 JSON 保存。文件权限模式为 600，可以限制其他系统用户读取，但挡不住以作者本人身份运行的程序。一个被安装的恶意包，可能和 CLI 拥有相同的文件访问权限。

所以，「没有把密钥交给 Console」只回答了这次托管服务事件的暴露路径，没有解决本机凭据保护。

作者进一步建议，让 agent 不直接持有密钥，由本地代理在网络层注入凭据。这个思路的价值是：agent 即使被攻破，攻击者也未必能拿走可在别处长期使用的密钥。

不过，作者将损害范围概括为请求层面，成立仍有条件。如果 agent 能读取代理的配置、访问其密钥文件，或修改代理进程，凭据隔离就可能失效；即便读不到密钥，能调用代理也可能消耗额度。原文没有展开这些权限边界。

真正要隔离的是 agent 对凭据的访问能力，代理只是实现这种隔离的一种方式。

我的判断

这篇最有价值的，是把两个经常混在一起的问题拆开：是否受到某次服务端泄露影响，以及自己的密钥管理是否可靠。作者的本地配置支持前一个判断，明文文件、备份旧值和公开仓库则暴露了后一个问题。

但它仍是一份个人排查记录。扫描 38,734 个文件，并不等于覆盖了所有泄露渠道；原文没说明扫描如何识别密钥、是否检查 Git 历史，也没有提供代理方案与直接持有密钥的对照数据。关于代理能缩小损害范围的论述，应当看作有条件的架构建议，不能当成已经验证的安全保证。

与让每个开发工具直接读取长期密钥相比，集中在受限代理中管理凭据，有机会减少散落副本；代价是团队需要维护代理权限、可用性和调用限制。单纯多加一层转发，却不收紧访问权限，收益就很有限。

能拿来做什么

• 给常用 AI 编程工具梳理一次凭据路径，记录密钥保存位置、base URL，以及是否向托管 workspace 连接过 provider。
• 如果曾把密钥交给受影响的托管服务，到 provider 端撤销并重新签发，再更新 CLI、Node 服务和 CI 中的使用方；只在托管服务里禁用不够。
• 检查 provider 最近两周的用量，同时搜索仓库历史、备份、shell history、CI secrets 和旧分支中的 .env，确认轮换前的旧密钥已经失效。
• 如果准备通过代理给 agent 提供模型访问，先验证 agent 能否读取代理凭据、修改代理配置，并限制它可发起的请求范围。