opencode的“恶果”来了，吃掉100G空间！

软件质量不过关，就会有各种问题！就是因为在 Windows 的"用户目录"运行了一下 OpenCode，问题一个接一个地来。软件用不了还是小事儿，有可能直接把你的系统拖垮！

昨天晚上就遇到这个问题了，1 TB 的系统盘满了，一下午被吃掉了几十上百 GB，内存也完全被塞满了。

从截图看，是Git搞的鬼，但是起因还是OpenCode！

这两天都在研究这个问题。本来以为只是 OpenCode 无法调用模型而已，问题不大，大不了就是不在用户目录调用它就好了。

但是昨天晚上就发现不对劲了，电脑很卡，硬盘空间一直在缩小，越来越小，直到爆满。

我赶紧删除了十几个 GB 文件，又被吃满了，我就觉得很奇怪。

C盘爆满的恐惧感再次袭来！

让 Agent 分析了一下才发现又是一个大坑！

关键问题是：

最终结论是：

erlang 复制代码

你的 C 盘"突然少掉的几十 G"，就是 C:\pagefile.sys 这个文件从正常大小膨胀到了 91.4 GB。而把它撑大的，是两个至今还挂着的 git.exe 进程（PID 28040 和 48172，今天 15:30 / 15:36 启动），各自占用了约 61 GB 的内存提交量。目前系统内存提交已用到 159.3 GB / 上限 160.8 GB（99%），物理内存也只剩 7.3%------系统正处在内存即将耗尽的边缘。

证据链：

文字内容如下：

css 复制代码

1、这两个 git 进程的命令是 git ls-files --others --exclude-standard --work-tree C:\Users\tony，git 仓库指向 C:\Users\tony.local\share\opencode\snapshot\global...------是 opencode 的"全局快照"机制在把你的整个用户主目录当工作区扫描。你的主目录有 349 GB、几十万个文件（AppData、scoop、.conda、各种工具目录），ls-files 扫描它会在内存里堆出巨型文件清单，这就是 61 GB 的来源。它们的父进程已退出，成了孤儿进程，挂了 7 个多小时。


2、Windows 为了满足这么大的内存需求，把 C 盘上"系统自动管理"的页面文件一路扩到 91.4 GB（接近 32 GB 内存下约 96 GB 的自动管理上限），且运行期间不会缩回------这就是消失的几十 G。


3、时间线吻合：上次开机是 8 月 21 日 10:09（页面文件开机时重置），膨胀发生在最近 3.5 天内，和你"这两天突然变紧"的感受一致。


4、已排除其他嫌疑：Windows 更新缓存几乎为空、无 Windows.old、系统还原点 0 占用、无内存转储；C:\Build（296 GB）最近 3 天零文件变动；用户目录最近变动的大文件合计只有约 5 GB。


5、另外注意：你的主目录本身是个 git 仓库（存在 C:\Users\tony.git），今晚 22:08 ChatGPT 桌面版（Codex）也刚对整个主目录跑过同样的 git ls-files------不处理的话这个模式还会复发。

核心原因就是因为有程序在用户目录执行了 git ls-files 这个命令，而执行这个命令的就是 OpenCode。问题的关键是，我并没有让 OpenCode 执行这个命令，我只是想通过它使用 Ox 模型而已。

这个问题有一定的隐蔽性，如果我不是分析了好几天，我可能都抓不到 OpenCode！

它是通过页文件的方式吃掉了存储空间！

我为了在本地跑大模型，特地把页文件设置得比较大，最大是 100 GB。

也就是这个 100 GB 几乎被吃完了。

如果不是有牛逼的工具辅助，我完全想不到页文件为什么会增大！

我完全想不到 Git 命令会让页文件增大。

我更想不到是OpenCode引起的蝴蝶效应！

根据提示，把两个孤儿 Git 进程结束后，终于救了回来：

页文件已经释放了几十 GB 了，然后顺带清了 58 GB 的 Temp 文件！

现在已经有 67 GB 的空余了，基本够用了。重启一下，应该能把页文件的空间拿回来！

我之前吐槽 OpenCode 和 DSH，有人说我哗众取宠，有人说不专业，嘲笑我在用户目录执行命令。（CMD 的默认目录就是用户目录）

DSH 的问题，我已经在 GPT-5.6 的文章中详细地分析过了。

今天就来说说 OpenCode 的四宗罪：

无条件把 cwd 当项目根

对主目录、盘根这类明显不该当项目的路径零判断，连个警告都没有。
遍历无超时

跑 6.5 小时还在跑，没有任何时间预算或中止机制。
无环检测、无深度上限

记录已访问的文件 ID 来断环是几十年的标准解法 ；find 默认就不跟随符号链接，ripgrep 也不跟随。
静默失败

这条最致命。关掉 snapshot 那次，日志停在 message=init 之后一条记录都没有 。既不报错、不超时、不提示"正在扫描 N 个文件"，UI 只有"加载中"。这是纯粹的工程质量问题，跟文件系统一点关系都没有。

出现这个问题的责任划分：

OpenCode ------ 主责：上面四条，每一条都是它自己能修的。

Git for Windows ------ 次责：在 Windows 上把 junction 当普通目录递归，这是个可争议的默认值。但它不是决定性的，因为 init 阶段的卡死压根不经过 git。

.dsh 包结构 ------ 诱因：61 层互链确实比一般 npm 包夸张

Windows 兼容 junction ------ 基本无责：已实测，单链环秒级终止，不致命。

然后再来探讨另一个问题，刚才的证据链中说，Codex 也执行了 Git 命令。那么 Codex 是否也有同样的问题？这个锅是不是用户目录的 .git 背！

就这个问题，我也专门分析了一下，结论是：删 .git 能挡住一部分，但挡不住全部。

第一类：蹭现成仓库的（删 .git 就能解决 ✅）

ChatGPT 桌面版、各种 IDE、都是在当前目录往上找 .git，找到了就把整个目录树当项目扫描。删掉 C:\Users\tony.git 后，这些工具在主目录下跑 git 会立刻得到"这不是 git 仓库"而直接结束，不会再扫出 61 GB 的进程。

第二类：自建仓库指向主目录的（删 .git 没用 ❌） OpenCode 的"全局快照"机制根本不用主目录的 .git。

它自己在 ~.local\share\opencode\snapshot\global 里建了裸仓库，用 --work-tree ~ 强行把整个主目录当工作区。这次吃掉 122 GB 内存的两个进程就是它发起的。

OpenCode 的快照缓存本身就占了 43 GB

顺带一个新发现：

C:\Users\tony.local\share\opencode\snapshot 里有 10 个快照仓库，全部指向主目录，合计 43 GB。这就是这次事故的直接残留物，删掉可以再拿回 43 GB，对功能无损（只是丢掉 OpenCode 的历史撤销点，反正也不该有）。

也就是说：因为和 OpenCode 说了一句"你好"，吃掉了 100 多 GB 的硬盘空间！

我就很好奇，一个 20 万 Star 的项目，为什么这一点就没注意到，到现在还没修复？

当然这个问题是有一定的隐蔽性的，DeepSeek V4 Flash、GPT-5.6 Sol、K3，专门叫它们分析也没有分析出来。但是 Opus 5 一眼就看出来了，另外一个模型也找出来了。

OpenCode 现在已经完全是一个盈利软件了，不应该这么草台吧！都拿出来卖了，怎么也得把服务做好，基础问题修复一下吧。

由于我装的各种开源、闭源的软件特别多，我最怕的就是它们在我电脑里偷偷"拉屎"，把整个系统搞瘫，把空间占满。然后你又很难发现！

手伸太长，不管理好自己排泄物的软件，都是"垃圾软件"！

我本来还开玩笑说，我准备留着个漏洞来测试，现在看来是不太敢留着测试了！

今天就把它铲了吧！

删之前把几个模型都测一波，也是个不小的收获。

大家如果有用 OpenCode 的话，也不用怕，一般情况没啥大问题。但是，切记不要在默认的 CMD 目录启动它，切记不要和 DSH 一起用，在其他目录启动大概率不会遇到这个问题。但是它 C 盘的快照，可能还是会占用较大空间，如果你的项目比较大，可能会把 C 盘塞爆！

我虽然这两天一直在吐槽它的问题，但是它也并不是一无是处，它主要是模型比较多，支付比较方便。适合我这种要跑测试的，一个套餐，一个软件可以接入不同的模型。

除此之外，软件体验的话确实一般，无论是 GUI 还是 TUI。