feat: 新增 codebuddy 客户端支持（bili codebuddy）

[ProgramerNoob]

背景

codebuddy（CodeBuddy Code CLI，npm 包 @tencent-ai/codebuddy-code）是腾讯的 AI agent CLI。它和 claude 一样是 Node CLI，原生支持用环境变量覆盖 API 端点，接入成本低，值得加入 launcher 列表。

推荐方案：claude 式 /bili/ rewrite，proxy mode

codebuddy 有 CODEBUDDY_BASE_URL 环境变量，启动时注入即可把模型流量打进本地代理。不需要 cert-MITM，也不用碰用户的配置文件：

CODEBUDDY_BASE_URL=http://127.0.0.1:PORT/bili/<真实upstream>

压缩走 proxy mode。codebuddy 不是 ACP-native agent，做 agent 侧薄 plugin 不现实。wire 格式上 OpenAI 和 Anthropic 两种 adapter 都是现成的。

调研确认的配置事实

从本机安装包（dist/codebuddy.js）和内置文档核实：

• 上游有两个配置面。env CODEBUDDY_BASE_URL + CODEBUDDY_API_KEY（Anthropic 协议）；models.json 里每个模型的 url 字段（OpenAI /chat/completions 完整路径）+ apiKey + maxInputTokens，其中 maxInputTokens 可以直接当作 context window 声明。
• models.json 分两级：~/.codebuddy/models.json 和 <workspace>/.codebuddy/models.json，项目级优先。
• 平台登录态的默认端点是 https://tencent.sso.codebuddy.cn/v2（国内版）。控制面独立（CODEBUDDY_CONTROL_BASE_URL），rewrite 只影响模型流量，登录和产品配置加载不受影响。
• 配置根目录可用 CODEBUDDY_CONFIG_DIR 覆盖，默认 ~/.codebuddy。settings.json 有 env 块和 autoCompactWindow 字段。
• 原生 auto-compact 由 CODEBUDDY_AUTO_COMPACT_WINDOW / CODEBUDDY_AUTOCOMPACT_PCT_OVERRIDE / settings autoCompactWindow 控制，正好对应 REQ: codex 压缩预算协调 + 匿名代理模式拦截伪造（根本解决方案） #321 的 claude 预算对齐模式（env 注入面）。
• MCP 注入走 --mcp-config <fileOrString>，不带 --strict-mcp-config 时与用户配置合并，对应 mcp.ts 的 spawn 时注入路径。

接入点清单

1. src/client-config.ts：新增 CodebuddyConfig、resolveCodebuddyHome(env)（读 CODEBUDDY_CONFIG_DIR）、readCodebuddyConfig()，只读发现 settings.json（env 块的 CODEBUDDY_BASE_URL、顶层 model、autoCompactWindow）和两级 models.json（url 收集 + maxInputTokens 转 ModelWindow）；挂进 loadClientConfig、ModelWindowScope、collectModelWindows。
2. src/launcher.ts：LAUNCH_CLIENTS 加 "codebuddy"；discoverRoutes 加分支（仿 claude）；新增 buildCodebuddyEnv()（仿 buildClaudeEnv）；预算对齐复用 claude 的 env 注入路径；runLaunch 和 resolveClientCommand 加分支（binary 名 codebuddy / cbc）。
3. src/discover.ts：extractHttpsHosts 加 codebuddy 分支；configFilePaths 加 settings.json 和 models.json 路径。
4. src/cli.ts：HELP 加一行（isLaunchClient 自动识别，无新分支）。
5. 测试仿 launcher.test.ts、codex-window-align.test.ts 的模式，补发现 / rewrite / 预算对齐用例。
6. README client 章节和 AGENTS.md 模块表同步更新。

开放问题

1. 国际版默认端点未确认。本机只核实到国内版 tencent.sso.codebuddy.cn/v2，代码里需要兜底两种。
2. models.json 里的 per-model url 不经过 CODEBUDDY_BASE_URL，env rewrite 盖不住这部分流量。两个选择：(a) 首版只支持 env / 平台路径并在文档注明；(b) dsh 式持久 overlay，但把 CODEBUDDY_CONFIG_DIR 指向 overlay 目录会隔离用户的 sessions 和记忆，代价太大。建议首版选 (a)。
3. 纯平台登录场景（无 models.json，模型走平台端点）env rewrite 一条路径即可全覆盖，适合作为首个验证场景。

[ranxianglei]

ework 接单

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

已完成，PR: #641

按 OP 方案实现（claude 式 /bili/ rewrite，proxy mode，wire 注入）：

实现

• src/client-config.ts：CodebuddyConfig / resolveCodebuddyHome()（CODEBUDDY_CONFIG_DIR ?? ~/.codebuddy）/ readCodebuddyConfig()——只读发现 settings.json（env 块 CODEBUDDY_BASE_URL、顶层 model/autoCompactWindow、shell env 兜底）+ 两级 models.json（项目级按 model id 优先，maxInputTokens → ModelWindow，per-model url 收集为清单）。parseCodebuddyModelsJson() 对容器形状做了容错（顶层 map / models map / 数组）——实际落盘形状未经真机核实，容错读取避免首版踩空。
• src/launcher.ts：discoverRoutes claude 式分支（默认 https://tencent.sso.codebuddy.cn/v2，CODEBUDDY_BASE_URL rewrite）；buildCodebuddyEnv()；resolveCodebuddyBudgetEnv()——REQ: codex 压缩预算协调 + 匿名代理模式拦截伪造（根本解决方案） #321 预算对齐走 CODEBUDDY_AUTO_COMPACT_WINDOW（无 model / 用户已设 / shell 已导出 / 解析不到窗口 → 不注入）；resolveClientCommand 依次找 codebuddy / cbc。
• src/discover.ts / src/cli.ts / README / AGENTS.md 同步。
• 新增 17 个测试（发现、rewrite、预算对齐、命令解析、runLaunch 集成、discover 域名）。

v1 限制（按 OP 决策 (a)，代码注释 + PR 里都注明了）

1. models.json per-model url 不走代理（绕开 CODEBUDDY_BASE_URL）——首版只覆盖 env/平台路径；纯平台登录（无 models.json）是首个验证场景。
2. 国际版默认端点未确认——兜底用国内版端点，其他部署需显式设 CODEBUDDY_BASE_URL。
3. 未做 MCP 注入（纯 wire mode）：--mcp-config 兼容性未经真机验证，留作后续；验证过后可像 claude 一样接上。

Pre-flight：typecheck ✓；test 1251/1252（唯一失败是环境性的既有问题：沙箱里装了 /usr/bin/codex，导致 resolveClientCommand: codex/claude resolve to themselves 在 master 上同样失败，已用 git stash 验证，CI 上通过）；build ✓。

建议真机验证路径：纯平台登录场景跑 bili codebuddy，确认模型流量走 /bili/、压缩循环正常触发、CODEBUDDY_AUTO_COMPACT_WINDOW 对齐日志出现。

[ranxianglei]

需要确认登录协议是否私有,据我理解,类似qoder的是私有的,不通用.

需要确认这个软件是否一样.建议下载研究

[ranxianglei]

继续

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

[bot] 🏷 已下载 @tencent-ai/codebuddy-code@2.147.0（公网 npm 包，169MB）研究，结论如下：

1. 登录协议：确实是私有的（你的判断正确）

product.json → authentication：

{ "id": "Tencent-Cloud.coding-copilot", "type": "cli-external-link", "label": "TencentCloud",
  "attributes": { "tokenHeader": "Authorization", "tokenType": "bearerToken",
    "usernameHeader": "X-User-Id", "usernameEncode": "URLEncode", "prefixPath": "/plugin",
    "iOADomain": ["tencent.sso.copilot.tencent.com", "tencent.sso.codebuddy.cn", ...] } }

登录 = CLI 拉起外部链接走腾讯 SSO（tencent.sso.codebuddy.cn 等），用户腾讯账号认证后拿 bearer token——和 qoder 同类：私有 SSO，不是标准 OAuth，第三方无法互操作。模型请求携带 Authorization: Bearer <token> + X-User-Id/X-Enterprise-Id 等身份头。

但这不影响 bili 的方案：登录走 SSO/控制面，bili 完全不碰（rewrite 只作用于模型流量的 CODEBUDDY_BASE_URL）；token 对代理是不透明的——codebuddy 发出、代理原样转发给真实上游。决定 bili 能否工作的是模型流量的 wire 协议，不是登录协议。

2. 重要更正：模型 wire 是 OpenAI，不是 Anthropic

OP 里"env CODEBUDDY_BASE_URL + CODEBUDDY_API_KEY（Anthropic 协议）"是误判。dist/codebuddy.js 的 ModelProvider 直接用 OpenAI SDK：

createClient(ei, ea) { return new OpenAI(this.buildOpenAIClientOptions(ei, ea)) }
// { baseURL, apiKey, fetch: axiosToFetchAdapter(), maxRetries: 0, timeout }

请求是 POST <base>/chat/completions，标准 OpenAI chat body + SSE。base URL 优先级：models.json per-model url > CODEBUDDY_BASE_URL > <productEndpoint>/v2。

对 bili 无影响，现有 PR 直接可用：/bili/ rewrite 是 wire-agnostic 的；代理按路径判协议（src/server.ts:983：/chat/completions → openai adapter），codebuddy 流量走的就是现成的 OpenAI 压缩管线。我把注释/README 里的"Anthropic protocol"措辞更正了（commit ab93c77，已推 PR #641）。

3. 顺带解决了 OP 开放问题 #1（国际版端点）

• 国际版（公网 npm product.json）：endpoint: "https://www.codebuddy.ai" → 模型端点 https://www.codebuddy.ai/v2
• 国内版（OP 已核实）：https://tencent.sso.codebuddy.cn/v2
• 另有 internal/ioa（copilot.tencent.com）、cloudhosted、selfhosted 变体

launcher 默认保留国内版（目标用户群），国际版用户需显式设 CODEBUDDY_BASE_URL=https://www.codebuddy.ai/v2（settings.json 或 shell）——现在可以写具体值了。

4. 其他核实（v2.147.0 bundle）

• CODEBUDDY_AUTO_COMPACT_WINDOW 确认存在（resolveWindowBase 读它覆盖 base window）→ 预算对齐有效
• --mcp-config <fileOrString> + --strict-mcp-config 确认存在，语义与 claude 一致 → MCP 注入可作后续（flag 在，MCP client 兼容性未验证）
• models.json 实际形状确认：{ models: [{id, name, url, apiKey, maxInputTokens, ...}], availableModels: [...] } → 我写的防御式解析恰好覆盖这个形状
• settings.json env 块确认被尊重（代码里有 "custom CODEBUDDY_BASE_URL is set" 检查）
• binary 名：codebuddy / cbc / codebuddy-code / cbc-prewarm / codebuddy-lowmem → 我写的 codebuddy→cbc fallback 正确
• models.json 两级路径：<configDir>/models.json + <cwd>/.codebuddy/models.json（configDir 尊重 CODEBUDDY_CONFIG_DIR）

结论：登录私有但不挡路；真实 wire 是 OpenAI chat completions，bili 已支持。PR #641 就绪（含另一个 agent 补的 Windows CI 测试修复 b216a0e + 本次协议措辞更正）。

[ranxianglei]

再提交一个 qoder issue 支持并提供指导

[ranxianglei]

挂了？继续

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

[bot] 🏷 没挂，是进程卡住被重启了一次（调研 qoder bundle 时一次大文件扫描挂起）。调研已完成，qoder issue 已提交：

#653 — feat: 新增 qoder 客户端支持（bili qoder）

核心结论（下载 @qoder-ai/qodercli@1.1.47 + @qodercn-ai/qoderclicn@1.1.47 从 bundle 核实）：

1. 登录私有（你的判断正确）：浏览器 SSO（30 分钟自动刷新）或 PAT（QODER_PERSONAL_ACCESS_TOKEN），token 对代理不透明，不影响 bili
2. 模型 wire 是 OpenAI chat completions：POST https://<host>/model/v1/chat/completions（标准 OpenAI body + qoder 扩展字段），SSE
3. 和 codebuddy 的关键差异：scheme 硬编码 https，没有可用的 HTTP base URL 覆盖 env → /bili/ rewrite 走不通，必须 cert-MITM（dsh/claude 式：HTTPS_PROXY + NODE_EXTRA_CA_CERTS + MITM 白名单）。已验证 qoder 内置 undici 带 ProxyAgent、尊重 NODE_EXTRA_CA_CERTS，路线可行
4. 默认模型 host：api2-v2.qoder.sh（国际/国内相同）；区域 api1/2/3.qoder.sh（US/SG/JP）；国内全走 gateway.qoder.com.cn
5. 预算对齐：QODER_AUTOCOMPACT_WINDOW（cap 有效窗口，对应 REQ: codex 压缩预算协调 + 匿名代理模式拦截伪造（根本解决方案） #321 模式）
6. qodercli 是 gemini-cli 的 fork；bundle 里有 ACP 协议 schema——未来可走 plugin mode，首版不做

issue 里写了完整接入点清单 + 5 个开放问题（legacy transport wire 待真机验证、body 扩展字段透传、模型窗口服务端驱动、国内站点前缀检测、ACP 后续）。等 owner 拍板方案后再进实现。

[ranxianglei]

麻烦有空反馈下codebuddy 是否能用哈

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

[bot] 🏷 能用，已真机验证（真实 @tencent-ai/codebuddy-code@2.148.0 + PR #641 分支构建的 bili + 本地 mock OpenAI 上游，全链路跑通）：

✅ 验证通过项

1. 启动/路由：bili codebuddy 注入 CODEBUDDY_BASE_URL=http://127.0.0.1:<port>/bili/...，代理正确 unwrap 并转发到真实上游（forward POST → …/v2/chat/completions）
2. 免登录认证：自定义端点路径不需要腾讯 SSO——CODEBUDDY_API_KEY=test-key → 请求带 Authorization: Bearer test-key，token 对代理不透明、原样转发。纯平台登录场景同理（token 走原通道，代理只碰模型流量）
3. wire 兼容：真机发出的就是标准 OpenAI chat completions（stream SSE），body 约 138KB（system + memory 注入 + tools，含 qoder 类似的扩展字段 reasoning_effort/reasoning_summary/verbosity）——bili 的 OpenAI 管线无错误处理，响应流式回传正常，客户端正常输出、退出码 0
4. 压缩管线全程生效：kernel 分配 mNNNNN refs、prefix-affinity session 建立、出站 wire history 里确认注入了 <acp> 标签（assistant/user 消息头部都有配对标签）——模型后续可以引用这些 ref 做 compress；多轮 -c 续接时历史完整重发（system+首条 user 字节级一致），nudge 计数正常
5. 预算对齐：settings.json 设 "model":"gpt-4o" → 日志出现 bili: codebuddy budget aligned — CODEBUDDY_AUTO_COMPACT_WINDOW=128000 ✓

⚠️ 已知边界（不影响"能用"）

• 平台模型别名（default-model/fast-model…）不在 models.dev registry 里，窗口解析会落到默认 200k 兜底。用平台模型的话建议显式设 CODEBUDDY_AUTO_COMPACT_WINDOW（或 settings autoCompactWindow）拿到精确预算
• 真实腾讯端点没测（需要你的登录态/凭证）——但 bili 侧机制全部验证过了，剩余风险只在腾讯 auth 细节上。你方便的话用真实账号跑一次 bili codebuddy 交互模式即可最终确认
• models.json per-model url 仍不走代理（v1 限制，按 OP 决策 (a)）
• 小观察（非阻塞、非 codebuddy 特有）：快速连续重启代理进程的场景下，session reattach 有 flush/hydrate 竞态窗口（本沙箱里我自己的 opencode bili 会话还并发写同一个 prefix-affinity.json）。正常使用 = 单个长驻代理 + 交互式 TUI，不受影响。按规则只报告不开单独 issue

结论：PR #641 可以合并，codebuddy 接入按预期工作。

[ranxianglei]

Batched into a single PR together with the sibling client-support issues: PR #693 (codebuddy + qoder + trae merged once, conflicts resolved one time, docs unified across zh/EN README + CONFIGURATION tables).

Superseded PR to close after merge: #641

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

[bot] 🏷 收到。已确认 #693（feat(#640,#653,#655): client support batch — codebuddy + qoder + trae）当前 open、base master。#641 保持 open 作为回退，等 #693 合并后我立即关闭 #693→#641 这个 superseded PR（收到合并事件即执行，无需再提醒）。

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

[bot] 🏷 更正上一条笔误：#693 合并后我要关闭的是 #641（被 supersede 的那个），不是 #693。即：#693 照常由你人工合并，合并事件一到我就 close #641。