停止使用 OpenCode
Hacker News 摘要如果你不知道 OpenCode 是什么，可以想象一只靴子永远踩在人类的脸上。这只靴子由 TypeScript 构成，而那张脸则是自 20 世纪 40 年代计算机发明以来，人类在安全和系统软件领域积累的所有知识。
它的开发者称其为 AI 编程助手。据作者观察，它是目前最受欢迎的开源编程助手，在 GitHub 上拥有 16.1 万颗星。作者在使用本地大语言模型（LLM）体验后得出结论：OpenCode 是一个由于一系列糟糕决策堆砌而成的工具，其安全防护形同虚设。作者呼吁所有人停止使用它。
作者从烦人的问题和令人担忧的问题两个方面进行了详细分析。
烦人的问题
即便在不涉及安全漏洞的情况下，OpenCode 作为一个工具也是失败的。
提示词缓存失效
大多数本地大语言模型服务器使用 OpenAI 的 API。服务器通常通过缓存历史对话的前缀来提高速度。然而，OpenCode 的多种行为会导致缓存频繁失效，迫使模型重新计算，浪费大量时间。
• 它每一轮对话都会重新读取文件，只要你修改了一点笔记，就会导致全量重新评估。
• 它在处理工具调用时会修剪上下文。只要超过一定的字数限制，它就会丢弃之前的工具调用结果。这意味着即使只是中断模型并调整方向，模型也会丢失之前的记忆。
• 最滑稽的是，它会在系统提示词中加入当前日期。如果你在午夜使用，日期更替会导致提示词缓存完全失效。
上下文修剪与压缩
OpenCode 的修剪机制非常简陋。例如，当模型读取了需求文档后，如果接下来的操作超出了阈值，它会直接删掉需求文档，导致模型在没有需求参考的情况下乱写代码。它的会话压缩功能也做得不好，往往会让模型陷入长时间的思考却只得出几行毫无意义的总结。
系统提示词
OpenCode 默认的系统提示词非常冗长，且带有很多个人偏见。比如它会强行要求模型绝对不要写注释。不同模型的提示词质量参差不齐，有些提示词甚至会傲慢地告诉模型不通过谷歌搜索就不可能完成任务，而不是让模型去阅读本地源码。
权限提示与用户交互
当模型尝试访问项目外的文件时，OpenCode 会弹出提示。但选项中只有“是”、“否”和“总是”，缺少“从不”这个选项。如果你拒绝了某个子代理的请求，系统会直接杀掉该代理，导致其之前的工作全部丢失。这种设计会导致用户产生决策疲劳，最后为了效率只能一路点“是”。
工具与界面问题
• 编辑工具：默认使用精确搜索替换，一旦行号偏移或匹配不唯一就会失败。
• 重复功能：很多内置的搜索工具与普通的 Bash 命令功能重叠。
• 终端界面（TUI）：渲染文本居然要消耗 1 GB 的内存。它无法输入换行符，且在处理长消息时会出现严重的性能下降。按下 Ctrl+C 会直接关闭整个会话，而不是中断当前命令。
令人担忧的安全问题
这部分内容揭示了 OpenCode 在安全设计上的极度业余。
强制联网与远程连接
OpenCode 很难完全脱离网络运行。它默认连接远程模型，且配置本地模型的过程非常繁琐。即便你配置了本地模型，它在启动时仍可能已经连接到了远程服务器。它还会从特定网站下载模型配置，这意味着你运行程序的一瞬间，本地的 Shell 就可能已经暴露给了远程环境。
盲目的互联网访问
系统提示词中包含了一个获取网页内容的工具。虽然提示词要求模型不要猜测网址，但语气非常模糊。由于 Bash 环境没有网络沙箱，模型很容易执行类似从网上下载脚本并直接运行的操作。
Bash 权限过滤形同虚设
OpenCode 试图通过解析 Bash 脚本的语法树来过滤危险命令（如禁用 git 命令）。作者展示了多种绕过方式：
• 使用环境变量或别名执行命令。
• 通过管道符将编码后的字符串传递给 Bash 执行。
• 使用 Python 的子进程模块调用受限命令。
这种基于文本的过滤完全无法提供安全保障，只会给用户一种虚假的安全感。
权限持久化漏洞
如果你给某个命令（如 python3）授权了“总是允许”，那么模型后续可以通过该命令执行任何危险操作，比如读取你的 SSH 密钥。因为 OpenCode 记录的是命令前缀，而不是具体的行为。
文件系统权限漏洞
OpenCode 的路径验证逻辑漏洞百出。它有一份预设的命令列表，只有列表里的命令才会触发路径检查。如果你运行列表中没有的命令，或者利用重定向操作，就可以轻易读写项目目录之外的文件。
远程代码执行（RCE）风险
OpenCode 历史上曾爆出过严重的漏洞。它默认开启一个 HTTP 服务器，且拥有完全放开的跨域配置。这意味着任何你访问的恶意网站都可以通过浏览器向你的 OpenCode 发送请求，从而获取你电脑的完全控制权。尽管开发者后来禁用了该服务器，但处理方式依然非常草率。
总结
针对“使用 Docker 就能解决安全问题”的说法，作者予以回绝。他认为 Docker 会增加系统复杂度并引入新的安全隐患，而且并不能真正保护容器内的重要资产。
作者认为，编程助手的安全应该是头等大事，应该利用操作系统原生的构造（如只读挂载、沙箱限制）来防护，而不是玩文字过滤的游戏。目前的 AI 软件生态环境非常糟糕，在它们真正成为可靠的工具之前，人类需要围绕它们进行严肃的系统工程改造，而不是像 OpenCode 这样留下无数的安全黑洞。