Repository navigation
GOAT 用户调用 claude-haiku-5-5 被 permission_error 拒绝（反代路由未回退 CLI 直连） #84
Description
现象
GOAT 用户调用 claude-haiku-5-5 稳定失败，但同一个 key 调 gpt-5.6-sol 正常。
- 走本插件的反代路由（
/provider/v1/messages）+claude-haiku-5-5→permission_error: Authentication failed. Please check your credentials. - 同 key 同 Bearer 头 +
gpt-5.6-sol（/provider/v1/chat/completions）→ 认证通过，正常路由到 openai。
关键点：claude-haiku-5-5 确实在这把 key 的可见模型清单里（GET /provider/v1/models 返回 88 个模型，含 claude-haiku-5-5）——即账号是 GOAT 且模型在授权范围内，但反代路由仍返回 permission_error。
根因（已定位到传输层）
本插件默认走 Provider API 反代网关 /provider/v1/*。isUpgradeRequiredError 只在 Go-plan 的 403 upgrade_required 时回退 CLI 直连 /alpha/generate；而 claude 系在反代网关上对 GOAT 账号返回的是 permission_error（不是 upgrade_required），匹配不上回退条件 → 卡死在反代网关。
我用本插件自己的 buildCliBody() + Authorization: Bearer 直连实测 /alpha/generate + claude-haiku-5-5：
| header 组合 | 结果 |
|---|---|
| 默认 UA | Cloudflare 1010（指纹拦截） |
仅 User-Agent: command-code/1.79.2 |
穿过 CF → 403 upgrade_required（minVersion 0.18.10），不是 permission_error |
完整官方 header（x-command-code-version:1.79.2 等 6 个） |
又触发 CF 1010 |
这证明 claude-haiku-5-5 在直连端点不被账号权限拒绝（报的是版本过旧，不是 permission_error）——方向上印证了「GOAT 该走直连」，也说明本插件伪装的 COMMAND_CODE_CLI_VERSION = "1.79.2" 已不被服务端认可（服务端要 0.18.10）。
建议
requiresMessagesEndpoint 对 claude-* 强制走反代 /provider/v1/messages，但反代对 GOAT 的 claude 系不放行。能否考虑：
- 把 claude 系的回退触发条件从「仅
upgrade_required」扩大到「upgrade_required或 claude 系的permission_error」，让 GOAT 用户自动落到 CLI 直连； - 或更新
COMMAND_CODE_CLI_VERSION到满足服务端minVersion（当前伪装值已过期）。
（我不直接改本仓库，因为直连还要过 Cloudflare 指纹 + CLI 版本校验两道服务端关卡，属于上游/作者更清楚如何跟进的部分。）
环境
- 插件
@mars-sea/dsh-commandcode-providerv0.12.10 - DSH web profile，
apiBase=https://api.commandcode.ai - 账号 GOAT，key 在 DSH 凭据里
- 本机 Node 24.21.0
Activity
Mars-Sea commentedon Oct 14, 2026
感谢你写的详细材料，它让定位快了很多。我们按你给出的两条路径做了实测，先同步结论，再说我们改了什么、还缺什么。
一、实测：同套餐的另一账号未能复现
测试环境为 GOAT 账号（
planId: individual-goat），插件基线 0.13.1。GET /provider/v1/modelsclaude-haiku-5-5标注supported_endpoints: ["/messages"]POST /provider/v1/messages+claude-haiku-5-5（流式、非流式、带x-cmd-zdr: 1、无Accept）POST /alpha/generate+claude-haiku-5-5（插件当前请求头）User-Agent（插件归属头、cli、command-code/1.82.1）User-Agent、不带x-command-code-versionupgrade_required，minVersion: "0.18.10"也就是说，
permission_error没有在另一个 GOAT 账号上复现。它更像是账号侧或当时的服务端状态，而不是「反代路由对 GOAT 的 claude 系不放行」这条普遍规则。二、对你两条判断的修正
minVersion 0.18.10的 403，是请求缺少x-command-code-version头时服务端的固定响应（上表最后一行）。补上这个头就恢复 200。插件当前发送的值是1.82.1（1.79.2是更早的插件版本），实测被服务端接受。所以「插件伪装版本已过期」这一条不成立。deepseek-harness/<版本>（不是 curl 默认 UA），它和cli、command-code/<版本>三种取值都能穿过。你遇到的 1010 可能与本机网络环境有关，暂时无法归因到请求头。三、我们已经做的改动
按你建议里的方向 1，加了一条有边界的回退：Messages 端点返回 403 且结构化错误标识恰为
permission_error时，自动改用/alpha/generate重试同一账号。边界刻意收窄——其它权限失败（例如MODEL_NOT_IN_PLAN）保持原样上报，回退结果也不会被缓存成整个账号的协议结论，避免掩盖真实的套餐限制。回退后若 CLI 也失败，报错会以 CLI 那次为主并附上反代侧先前的拒绝标识。这条改动尚未发布：现在升级到任何已发布版本都不会有这个行为。发布后我会在本 issue 补上包含它的版本号，请等版本号确认后再试。
四、需要你补充的信息
为了定位你账号侧的根因，方便的话请提供：
x-request-id，或 DSH 失败信息里的请求关联号）。command-code login写入的登录态（~/.commandcode/auth.json）？GET /alpha/whoami返回的org字段），还是个人账号？/provider/v1/messages的模型也一样？请不要提供密钥本身，也不要贴包含对话内容的完整跟踪文件，上面几项足够了。
feat: 兼容 dsh 0.2.1-alpha.3，修复 #84、#85 与安全告警
GT-610 commentedon Oct 16, 2026
按仓库源码核对了你这套排查，结论如下。
你判断的方向 1 已被采纳（0.13.2 落地）：Messages 端点返回 403 且结构化错误标识恰为
permission_error时，会自动改用/alpha/generate重试同一账号。触发面刻意收窄——其它权限失败（例如MODEL_NOT_IN_PLAN）原样上报，回退结果也不会写成整个账号的协议结论，避免把真实的套餐限制掩盖掉。回退后再失败时，错误以 CLI 那次为主，并附上反代侧先前的拒绝标识。方向 2 没有被采纳，但你的前提被修正了：维护者实测发现，那条
minVersion 0.18.10的 403 是请求缺少x-command-code-version头时的固定响应，补上就恢复 200；插件实际发送的值（现为 1.82.2）被服务端接受，所以「伪装版本已过期」不成立。Cloudflare 1010 在他们那边没有复现。仍没解决：
permission_error在另一个 GOAT 账号上没能复现，所以根因（账号侧还是当时的服务端状态）仍未确认。维护者在你这条里问的五项信息——插件版本与大致时间、失败响应的x-request-id、密钥来源（设置页 API key 还是command-code login的登录态）、/alpha/whoami的org字段、以及现在是否仍稳定复现——目前还没有回复，这也是 issue 还开着的原因。（我是普通用户，以上按仓库源码与 CHANGELOG 核对，没有真机实测。）