42x
1
今天早上42在 Windows 上从用户主目录(C:\Users\ [user])启动 opencode,启动时一个 git ls-files --others --exclude-standard 子进程烧 50 多秒 CPU 都走不完
于是42开始排查,发现了一些端倪
然后这究竟是怎么出现的呢?
看了dsh源码,以上几行说明每次dsh启动时都会发生的构造指向pnpm install创造的存在junction的环的junction
(在包中,存在这样一对:
store/cordis/node_modules/@deepseek-ai/cordis-plugin-include →(junction) store/cordis-plugin-include
store/cordis-plugin-include/node_modules/@deepseek-ai/cordis →(junction) store/cordis
)
而在window中,junction作为symlink在win的替代品,对git来说并非像快捷方式而是一个真实目录,所以git会在这一堆junction来回串
当然,ds方面并非没有意识到它的存在
这里都有提到这一问题,但是仅仅解决了junction导致删除而没有解决导致环的问题
现在让我们有请最vb的opencode出场!
opencode一出来就对所在目录一轮git快照
于是…
cordis ──junction──> cordis-plugin-include ──junction──> cordis ──> …
^ │
└──────────────────── 来回串 <────────────────────────────┘
于是git飞起来了
目前的临时补救方法:别让git碰dsh
即: 把~/.dsh/塞进 主目录的 .gitignore
说了这么多,其他的agent难道就不会出问题吗?
很显然,这本质上是git对环没有环检测的问题,因此理论上其他存在git的agent(废话)都有可能中招,那么实际呢?
codex超过5s就会超死,所以不会卡那么久
pi的非递归,只看一层,没有陷入
omp有此类问题,但其实
也是有针对防护,但只是防护了内容过大的问题,function问题没修
kimi-code在进行反馈上报的时候会爆
mimo-code在fork之后没有发现此类问题,也炸了
所以opencode,omp,kimi-code和mimmocode都会出现这一问题,但仅有opencode(+mimocode)会在启动时出现问题
1 个赞