feat: add codebuddy client support (bili codebuddy)

[ranxianglei]

Closes #640

What

New bili codebuddy launcher for Tencent's CodeBuddy Code CLI (@tencent-ai/codebuddy-code), following the issue's plan: claude-style /bili/ URL rewrite in proxy mode (codebuddy is not ACP-native, so no agent-side plugin; the proxy injects the context tools on the wire).

Changes

• src/client-config.ts — CodebuddyConfig, resolveCodebuddyHome() (CODEBUDDY_CONFIG_DIR ?? ~/.codebuddy), readCodebuddyConfig() (read-only: settings.json env-block CODEBUDDY_BASE_URL + top-level model/autoCompactWindow, shell CODEBUDDY_BASE_URL fallback; two-tier models.json with project-level winning per model id, maxInputTokens → ModelWindow, per-model url collected as inventory). Defensive parseCodebuddyModelsJson() tolerates the container shapes (top-level map / models map / array) since the exact on-disk shape is unverified. Wired into loadClientConfig, ModelWindowScope, collectModelWindows.
• src/launcher.ts — codebuddy in LAUNCH_CLIENTS/BaseClientName; discoverRoutes claude-style branch (default https://tencent.sso.codebuddy.cn/v2, CODEBUDDY_BASE_URL rewrite; models.json urls → MITM-whitelist inventory only, never rewritten — they bypass CODEBUDDY_BASE_URL, v1 limitation per issue decision (a)); buildCodebuddyEnv(); resolveCodebuddyBudgetEnv() — REQ: codex 压缩预算协调 + 匿名代理模式拦截伪造（根本解决方案） #321 budget alignment via CODEBUDDY_AUTO_COMPACT_WINDOW (no model / user-set window / shell env / unresolvable window → no injection); launcherInjectMcp excludes codebuddy (wire mode; --mcp-config compat not yet verified against a real build — possible follow-up); resolveClientCommand tries codebuddy then cbc.
• src/discover.ts — extractHttpsHosts + configFilePaths codebuddy paths.
• src/cli.ts — HELP lines (dispatch already auto-detects via isLaunchClient).
• Tests — 17 new: config discovery (settings + two-tier models.json + shape tolerance), CODEBUDDY_BASE_URL rewrite, budget alignment (inject / self-align / shell-override), resolveClientCommand (codebuddy/cbc), runLaunch integration (env + budget end-to-end with a fake binary), discover hosts.
• Docs — README launcher list/example, AGENTS.md module table.

v1 limitations (documented in code + issue)

1. models.json per-model urls are not proxied — they bypass CODEBUDDY_BASE_URL (issue decision (a): env/platform path only, documented). Pure platform login (no models.json) is the first validation scenario.
2. International-build default endpoint unconfirmed — CN endpoint is the fallback; other deployments set CODEBUDDY_BASE_URL explicitly.
3. No MCP injection (wire mode only) until --mcp-config is verified against a real codebuddy build.

Pre-flight

• npm run typecheck — pass
• npm test — 1251/1252 pass; the single failure (resolveClientCommand: codex/claude resolve to themselves) is pre-existing and environmental — it fails on pristine master in this sandbox because /usr/bin/codex happens to be installed (the test asserts the not-on-PATH fallback); verified via git stash on master. Passes in CI.
• npm run build — pass

Launcher-side change only (no request-pipeline changes), so the codex E2E suite is not applicable; coverage is mock-based per the existing launcher.test.ts patterns.

[github-actions]

📦 Built Package Artifact

Branch: 2026-09-08_codebuddy-client (e9dac95)

Option A — Install from npm PR tag (recommended)

npm install -g billion-context@pr-641

Each push to this PR publishes a new version under the pr-641 npm tag.

Option B — Download artifact

1. Download the artifact from the Actions run
2. Extract the tarball and install:

tar xzf billion-context-pr641.tgz
npm install -g package

---

This comment is automatically updated on each push.

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

[bot] 🏷 Reviewed the full diff (8 files, +610/−9) against the #640 plan and re-ran the pre-flight. Verdict: implementation is consistent with the plan and mergeable after the Windows CI fix I just pushed (details below). Merge itself stays human-only.

🔴 Found & fixed: Windows CI was red

The pre-flight claim "Passes in CI" held for ubuntu but test (windows-latest, 22/24) was failing on head ae0fb6d (master's Windows runs are green, so the PR caused it):

✖ discoverMitmDomains: codebuddy settings.json + models.json hosts discovered
  AssertionError [ERR_ASSERTION]: codebuddy host present:   ← domains array empty

Root cause: the withTempHome helper (tests/discover.test.ts:140) redirects the other clients via env overrides (CODEX_HOME, ZCODE_DATA_BASE_DIR, PI_CODING_AGENT_DIR) but not codebuddy. Codebuddy's home resolves via resolveCodebuddyHome() = CODEBUDDY_CONFIG_DIR ?? os.homedir()/.codebuddy — and on Windows os.homedir() follows USERPROFILE, not HOME (which the helper sets), so the temp-home config files were never found.

Fix pushed to the PR branch — commit b216a0e (one line: CODEBUDDY_CONFIG_DIR: path.join(tmp, ".codebuddy") in the helper env, parallel to the three existing overrides). All 6 CI checks now pass on b216a0e, including both Windows legs.

Pre-flight (re-verified on b216a0e, kernel 0.0.56 per PR lockfile)

• npm run typecheck ✓
• npm test — 1251/1252; the single failure is the one you flagged (see test: resolveClientCommand codex/claude test is environment-dependent (fails when codex/claude live in /usr/bin) #642)
• npm run build ✓
• PR + current master merge: clean, no conflicts (master is 12 commits ahead, incl. the kernel 0.0.59 bump + compat-roles test migration from 8ff082d — the merge result passes the full suite too)

Code review notes (non-blocking)

• client-config.ts / launcher.ts / discover.ts / cli.ts all follow the existing claude patterns faithfully; parseCodebuddyModelsJson shape tolerance is reasonable given the unverified on-disk shape; models.json urls → MITM inventory only (never rewritten) matches issue decision (a).
• Minor: the codebuddy budget path resolves the model from config.codebuddy?.model only, whereas the claude branch (src/launcher.ts:2012) also falls back to the shell ANTHROPIC_MODEL. feat: 新增 codebuddy 客户端支持（bili codebuddy） #640's research found no codebuddy model-selection env var, so this is consistent with the verified surface — just worth confirming during real-machine validation.

Side finding (pre-existing, not from this PR)

The resolveClientCommand: codex/claude resolve to themselves test (tests/launcher.test.ts:1069) hard-codes /usr/bin as a PATH without codex/claude — it fails on any machine that has them installed there (this sandbox has /usr/bin/codex; CI runners don't, which is why CI is green). Pre-existing on master, test-hygiene only. Filed as #642 with a suggested hermetic fix.

Suggested real-machine validation (unchanged from your note)

Pure platform login (no models.json) → bili codebuddy → confirm model traffic lands on /bili/, the compress loop triggers, and the CODEBUDDY_AUTO_COMPACT_WINDOW alignment log appears.

[ranxianglei]

解决 冲突

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

[bot] 🏷 冲突已解决 ✅

做了什么：把 origin/master（合并时位于 1d09d5b，v0.1.101）merge 进 PR 分支，commit b3ab4c8，已推送到 2026-09-08_codebuddy-client。PR 现在 mergeable: true，无冲突。

冲突详情：只有一个文件冲突 —— src/client-config.ts。两边在同一个位置（resolveDshHome 之后）各自新增了函数：PR 侧是 codebuddy 块（resolveCodebuddyHome / parseCodebuddyModelsJson / readCodebuddyConfig），master 侧是 resolveCodexHome（#683 引入）。解法：两边都保留——按 master 布局把 resolveCodexHome 放前、codebuddy 块紧随其后；已验证相对两个 parent 的 diff 都是纯新增，无逻辑纠缠。src/cli.ts、src/launcher.ts、tests/launcher.test.ts 均自动合并干净（其中包含 master 上对 resolveClientCommand codex/claude 测试的 hermetic 修复 #642 —— 即上次 review 里报的那个环境性失败问题，已在 master 由 PR #643 修掉）。

Pre-flight（合并后 b3ab4c8，kernel 0.0.61）

• npm run typecheck ✓
• npm test：1335 pass / 0 fail / 1337（2 skipped，e2e gate）
• npm run build ✓

说明：推送后 master 又前进到 9aa72ac（v0.1.102 release commit，纯版本号变更，与本 PR 改动的文件无交集），所以 PR 显示 behind 但不是冲突，可直接合并。

CI 正在跑（windows/ubuntu test matrix），完成后补结果。PR 合并仍需人工操作。

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

[bot] 🏷 冲突解决后 CI 又抓到一个 Windows-only 的测试问题，已修复并推送到 PR 分支（新 head e9dac95），现在 6/6 check 全绿（含 windows-latest 22/24）。

问题：合并 master 后，test (windows-latest) 挂在新增的集成测试 runLaunch codebuddy: CODEBUDDY_BASE_URL /bili/ rewrite + budget injected（TAP: # fail 0 / # cancelled 1，exit code 1，错误 Promise resolution is still pending but the event loop has already resolved）。Ubuntu 两个节点一直是绿的，所以本地 Linux 跑不出来。

根因：master 的 #679 给 launcher 加了 planClientSpawn（src/launcher.ts:1787）——Windows 上无扩展名的目标命令会改走 comspec /d /s /c ... 包装（CreateProcess 不能直接执行无扩展名文件，需要 cmd 的 PATHEXT 解析），.exe 则直接 spawn。本 PR 新增的 codebuddy 集成测试用的假二进制是 fake-codebuddy（无扩展名），stub spawnImpl 按 cmd === fakeCodebuddy 匹配；合并后在 Windows 上实际传入的 cmd 变成了 comspec → stub 失配 → 走到 exit 42422 分支 → runLaunch 进失败路径调用被测试 stub 成 no-op 的 process.exit → await 的 Promise 永不 settle → node:test 以 cancelledByParent 取消。文件里其他所有 launcher 集成测试（dsh/codex/claude/omp/hermes…）早已按 #679 惯例写成 process.platform === "win32" ? "fake-X.exe" : "fake-X"，codebuddy 这条是唯一漏掉的。

修复：一行测试改动（tests/launcher.test.ts:2719），给假二进制加 win32 .exe 后缀，与其他测试对齐。纯测试改动，不动 launcher 逻辑；Linux 行为不变（.exe 分支惰性）。commit e9dac95 test: .exe-suffix the codebuddy fake client so win32 spawns it directly (#679)。

当前状态

• PR head e9dac95：typecheck ✓ / tests 1335 pass, 0 fail（2 skipped = e2e gate）/ build ✓（本地 + CI 双确认）
• CI 6/6 success：ubuntu 22/24、windows 22/24、version-guard、build-artifact
• PR mergeable，仅因 v0.1.102 release commit 显示 behind（纯版本号提交，无文件交集，不会再冲突）
• 之前报的 issue test: resolveClientCommand codex/claude test is environment-dependent (fails when codex/claude live in /usr/bin) #642（环境依赖的 codex/claude resolveClientCommand 测试）已由 master 上的 PR test: make resolveClientCommand codex/claude tests hermetic (#642) #643 / f0a85ec 修掉，本 PR 合并后该测试在此沙箱也会变绿

PR 可以合并了——按规矩合并操作留给你：#641

---

中文摘要：修了冲突合并 master 后暴露的 Windows 测试挂起问题（#679 的 spawn 规划把无扩展名的假 client 改走 comspec，导致 stub 失配、Promise 永不 settle），按既有惯例给假二进制加了 .exe 后缀，CI 六项全绿，可以合并。