windows codebuddy跳过hook

[zdGrande]

当前windows环境下，初始化时 codebuddy是直接跳过hook的，是否有适配计划。

[jeff-r2026]

感谢反馈,原因找到了:teamai 的 hook 走 bash,Windows 上没 /bin/sh,只能用工具自带 shell。WorkBuddy 自带 PortableGit 的 sh.exe 所以能跑,CodeBuddy 没登记这个,于是被跳过——是缺可用 shell,不是漏适配。

修法很小:在 src/bundled-runtime.ts 的 BUNDLED_SHELLS 加个 codebuddy 条目,照 resolveWorkbuddyShell() 写一个指向 CodeBuddy 自带 sh 的即可。

我这边没有 Windows + CodeBuddy 环境复现,方便的话能帮忙提个修复 PR 吗?关键是确认 CodeBuddy 在 Windows 装目录里有没有 sh.exe、路径是什么。有问题随时 at 我。

[zdGrande]

分析了下代码，CodeBuddy 在 Windows 上一向跑不起来 teamai 的 hook。原因有两个，彼此独立。

1. 被当成"这个环境没有 shell"直接跳过

skipToolsWithoutShell() 的门禁只问一件事：existsSync('/bin/sh')。而 Windows 版 CodeBuddy 的安装树里没有任何 POSIX shell（没有 sh.exe/bash.exe），于是门禁判定"该环境无法执行 hook 命令"，把 codebuddy 整个从注入名单里摘掉、只留一条 warn，其它工具则不受影响。

2. 渲染出来的命令是 POSIX 形态，cmd.exe 读不懂

即便放行，命令串也仍是 POSIX 形态：

PATH="$HOME/.teamai/bin:$PATH" teamai hook-dispatch session-start --tool codebuddy 2>/dev/null || true

cmd.exe 没有 VAR=value command 前缀、没有 /dev/null、也没有 || true，这条串在第一个 token 就会失败。而失败比"静默不生效"更糟：CodeBuddy 会把非 0 的 UserPromptSubmit 判定为 allowed: false，直接挡掉用户提问。

提交了一个相关的PR: #637 ， 可以review判断是否采取这种修复方案。

[CarlosWonMore]

独立复现：Windows + CodeBuddy，两个原因都成立；但"用 CodeBuddy 自带 sh"这个方向没有落地目标

在 Windows 11 25H2 + CodeBuddy CN 4.9.8 + teamai 0.24.0 上独立踩到同一个问题，两处原因都复现到了，另外补一个关键事实——CodeBuddy 的安装树里根本没有 POSIX shell，所以楼里"照 resolveWorkbuddyShell() 写一个指向 CodeBuddy 自带 sh 的 resolver"这个方向，在 Windows 上找不到目标文件。

1. 确认：安装树里没有任何 POSIX shell

$ find "/d/Program Files/CodeBuddy CN" -maxdepth 6 \( -iname sh.exe -o -iname bash.exe -o -iname ash.exe \)
（无输出）

$ ls "/d/Program Files/CodeBuddy CN" | head
CodeBuddy CN.exe
bin
chrome_100_percent.pak
d3dcompiler_47.dll
ffmpeg.dll
icudtl.dat
libEGL.dll
libGLESv2.dll
locales
...

这是一个 Electron 应用，树里没有 sh.exe / bash.exe / ash.exe。WorkBuddy 能跑 hook 是因为它额外分发了一份 PortableGit（~/.workbuddy/binaries/PortableGit/versions/*/usr/bin/sh.exe），CodeBuddy 没有对应物。所以 bundledShellFor("codebuddy") 无处可指 —— @zdGrande 在 #637 里的判断（skipToolsWithoutShell() 在这个场景问错了问题：hook 运行器走的是 %ComSpec%，cmd.exe 是操作系统一定提供的）我认为是对的。

2. 确认：POSIX 形态的命令串在 Windows 上是"会失败"而非"不生效"

这一点值得强调。我这边注入时 ~/.codebuddy/settings.json 里留下的正是 POSIX 形态：

"command": "PATH=\"$HOME/.teamai/bin:$PATH\" teamai hook-dispatch session-start --tool codebuddy 2>/dev/null || true"

且 ~/.codebuddy/settings.json 里当时只有 1 条残留 hook（SessionStart），缺少 Stop / PostToolUse×3 / UserPromptSubmit，与"被门禁整个摘掉"的表现一致。

3. 我这边的临时绕法（仅供参考，不如 #637 的方案）

我先用了一条不改渲染方式的路子：在 BUNDLED_SHELLS 里给 codebuddy 注册一个 resolver，复用本机已有的 Git Bash（优先 WorkBuddy 的 PortableGit，其次 %ProgramFiles%\Git 等）。补丁后：

$ teamai hooks list
codebuddy → installed
$ python -c "import json;d=json.load(open(r'C:\Users\Carlos\.codebuddy\settings.json'));print(sum(len(v) for v in d['hooks'].values()))"
6
$ teamai pull --force
（无 skip 警告）

6 条 hook 全部补齐并能被 hooks list 认到。但这条路有两个明显缺陷，所以我倾向 #637：

• 依赖 Git Bash 被安装。 没装 Git for Windows 的机器仍然无解，而 Windows 上 Git Bash 并非必然存在。
• 仍然输出 POSIX 命令串。 它之所以能跑，是因为 hook 最终交给了 MSYS sh；一旦 CodeBuddy 侧的执行路径变化（或像 fix(hooks): run CodeBuddy's Windows hooks through cmd.exe #637 指出的那样落到 cmd.exe），命令串立刻失效。相比之下 fix(hooks): run CodeBuddy's Windows hooks through cmd.exe #637 让命令形态与执行器一致，是更稳的解法。

4. 一个附带观察

#637 review 里提到的 P2（wrapper 写入位置用 getUserHome()，而 hook 里固定搜 %USERPROFILE%\.teamai\bin）我在代码里看到的是同一处不一致，确实值得在合并前处理好 —— 这条路径在 HOME 被显式设置过的 Git Bash 环境里很容易分叉，而症状是"静默失效"，和本 issue 的其它症状难以区分。