dsh-workbuddy-fix

WorkBuddy 400 错误修复 · unapproved channel (code 11128) · DSH 插件

一键修复 WorkBuddy / CodeBuddy 的 Illegal API invocation from an unapproved channel（HTTP 400 / code 11128）。

装进 DSH，在「设置」页开关。提示词无损绕过 —— 语义不变、上下文不丢、可随时关闭。

关键词：unapproved channel · Illegal API invocation · code 11128 · 11140 · WorkBuddy 400 · CodeBuddy 400 · 请求被拦截 · 提示词风控 · 关键词过滤绕过 · 零宽空格 · DeepSeek Harness · prompt filter bypass

📺 看 24 秒演示 （1080p MP4，2.4 MB · 前情提要 → 报错长什么样 → 为什么不是渠道问题 → 真因与解法 → 装好后的开关）

_{背景音乐：Peaceful Instrumental Background Music by Peaceful Peach — CC0 1.0，来自 Internet Archive}

_{演示视频放在 Release 附件里而不是仓库内 —— 仓库只装插件本体（< 100 KB）， 视频/动图会拖慢每个人的 git clone。需要 GIF 版可以自己从 MP4 转。}

---

常见报错速查

---

如果你是因为这个报错搜到这里

buddy: 请求被拦截，请重新发送 Illegal API invocation from an unapproved channel

Illegal API invocation from an unapproved channel

HTTP 400 · 上游 code 11128（有时 11140）

这个报错在骗你

文案说 "unapproved channel"（未获批准的渠道），但它跟渠道一点关系都没有。

我逐项实测排除过：换账号、换域名（copilot.tencent.com / www.workbuddy.ai）、 换客户端身份（CodeBuddy / WorkBuddy）、补齐 13 个缺失请求头、调 reasoning_effort、 调 max_tokens、减少工具数量（316→少量）、换网络、降并发 —— 全都不是原因。

真因：上游在对 system prompt 做关键词内容风控。 只要 prompt 里出现 DeepSeek Harness 这个词组，请求就被拒。

60 秒自证

用同一个 token 打两次，只改 system prompt 里的一个词：

符合这个规律，就是这个原因。

💡 为什么它时好时坏：关键词要配合请求体够大（约 >1KB）才稳定触发。 短 prompt 即使含关键词也会放过 —— 这是最容易误判成「偶发故障」的地方。

修法：零宽空格

在 DeepSeek 与 Harness 之间插一个不可见字符 U+200B：

// 改前
"You are an AI agent powered by DeepSeek Harness."
// 改后
"You are an AI agent powered by DeepSeek\u200B Harness."

• 模型看到的语义完全不变
• 上游的子串匹配不再命中
• 无损：没有裁剪、没有改写、没有丢上下文

实测（真实 DSH 请求形状：316 tools + effort=max + max_tokens=128000）：

原文   → ❌ 0/5 全部失败
中和后 → ✅ 5/5 全部成功

⚠️ 文件路径不能被改写

运行时上下文里有真实路径：

D:\10_COD\DeepSeek Harness\resources\app.asar\dsh\

在路径里插零宽字符，会让模型把坏路径传给工具调用，直接失败。 所以匹配器带前后负向断言，跳过路径语境：

/(?<![\\/])(DeepSeek)[ \u00A0]+(Harness)(?![\\/])/gi

---

前置条件

不需要：官方客户端后台常驻、额外 API Key、管理员权限。

兼容性说明：旧版要求必须装 dsh-our-free-model（因为它要往 OFM 的 pack.js 插一行钩子）。v1.1.0 起不再依赖任何第三方文件 —— 主通道改在 globalThis.fetch 层拦截，只要你的 WB 反代插件用 fetch 发 chat/completions 请求就生效， 不管它是 OFM 还是别的实现、哪个版本、装在哪个 profile。

---

安装

先看这一步的版本要求：本插件需要 v1.1.4 或更新。 v1.0.0 是早期版本，没有 fetch 通道，对大部分人是无效的 —— 见下面的「装了没用？」。

方式一：从 GitHub 直接装（推荐，最简单）

在 DSH 里说：

我装了 github:balongTTY/dsh-workbuddy-fix 把 github:balongTTY/dsh-workbuddy-fix 装成插件

或自己执行（把 <DSH目录> 换成本机实际路径）：

<DSH目录>\resources\runtime\cli\bin\dsh.cmd plugin --profile desktop add github:balongTTY/dsh-workbuddy-fix

实测耗时约 30 秒（要拉 GitHub）。装完重启一次 DSH。

⚠️ 网络不通时这条会失败（GitHub 直连不稳）。用方式二。

方式二：下载 Release 附件（网络不好时用这个）

1. 打开 最新 Release
2. 下载 balong-dsh-workbuddy-fix-<版本>.tgz（约 41 KB）
3. 执行：

<DSH目录>\resources\runtime\cli\bin\dsh.cmd plugin --profile desktop add .\balong-dsh-workbuddy-fix-1.1.4.tgz

⚠️ 只下 .tgz 附件。v1.0.0 的 Release 里那个 wb400-intro.mp4 是演示视频，不是插件包。

方式三：克隆后装（要改代码时用）

git clone https://github.com/balongTTY/dsh-workbuddy-fix.git
cd <DSH安装目录>\resources\runtime\cli\bin
.\dsh.cmd plugin --profile desktop add <克隆下来的目录绝对路径>

clone 实测约 0.35 MB（见体积说明）。

怎么确认装对了

重启 DSH 后打开 设置 → wb400修复，顶部应该显示：

主通道已接管（fetch 层）

看到这一行 = 新版且生效。 如果显示「未打钩子」「pack.js 钩子已打上」之类，说明装的是旧版，重装。

装完 DSH 起不来怎么办

先按下面「卸载」把插件摘掉，DSH 就能恢复：

<DSH目录>\resources\runtime\cli\bin\dsh.cmd plugin --profile desktop remove @balong/dsh-workbuddy-fix

然后去 Issues 反馈，带上：

1. 装的是哪个版本（v1.1.4 / v1.0.0 / 不确定）
2. 用的哪种方式（方式一 / 二 / 三）
3. DSH 启动日志里的报错原文
   • 位置：%APPDATA%\@deepseek-ai\dsh-desktop\logs\crash-<时间>-*.log

有这三条我能直接定位。

卸载

<DSH目录>\resources\runtime\cli\bin\dsh.cmd plugin --profile desktop remove @balong/dsh-workbuddy-fix

卸载不会动你的关键词配置（~/.dsh/workbuddy-meter/lexicon.json），重装后开关状态还在。

---

装了没用？先看这里

按顺序排查，通常第 1 或第 2 条就是原因。

① 版本装错了（最常见）

v1.0.x 只支持 workbuddy 渠道，走 buddy（CodeBuddy）渠道的用户完全不受益，而且它依赖 OFM 的文件结构，OFM 版本不对就打不上钩子。

② 报错前缀能区分渠道

两个渠道 v1.1.4 都覆盖了（WB_HOSTS 里的 5 个域名）。

③ 反代插件没有走 globalThis.fetch

极少见，但如果你的反代插件用 undici 直连或 node:http，fetch 层拦不到。 判断方法：在面板看「介入次数」是否随对话增长。

node diagnose.mjs

会打印当前 OFM 版本、锚点情况，以及该用哪条通道。

④ 装了但一次都没触发

如果你用的是 dsh-connect-workbuddy，注意它有个特性： 它会在 system prompt 丢失时补一句 "You are a helpful assistant." —— 那句里没有关键词， 所以本来就不需要本插件介入（这种情况你也不会看到 400）。这不是 bug。

---

使用

打开 设置 → wb400修复，看到 4 个开关：

面板还会显示：

• 补丁状态（钩子是否在位）+ 补打钩子按钮
• 本机已中和多少处
• 改写效果预览（前后对照）
• 是否与「用量计量」插件联动

改完即时生效，不需要重启。

---

与 dsh-workbuddy-meter 的关系

本插件是 dsh-workbuddy-meter 里 「关键词中性化」功能的独立精简版。

两个插件可以同时装，而且开关是联动的

它们共享同一个状态文件：

~/.dsh/workbuddy-meter/lexicon.json

任一方改了开关，另一方立即跟随 —— 一个打开，另一个也打开。 不会冲突，不会重复改写（钩子名相同，后装的覆盖先装的，但行为一致）。

只装其中一个也完全正常：

• 只装本插件 → 有修复功能，没有计量面板
• 只装 meter → 两者都有（meter 内置了同样功能）
• 都装 → 修复逻辑一致，开关双向同步

---

它对你的代码做了什么

主通道：fetch 层拦截（v1.1.0 起，不碰任何文件）

包装 globalThis.fetch，在请求真正发出前改写 body：

POST https://copilot.tencent.com/v1/chat/completions
  ↓
命中 WB 域名 → 读 body → 改写 messages → 重新序列化 → 发出

• 不修改任何第三方文件，所以 OFM 升级、换插件、换 profile 都不会失效
• 只命中 copilot.tencent.com / workbuddy.ai / workbuddy.cn / codebuddy.ai / codebuddy.cn 的 chat/completions，其它请求原样透传（已测：非 WB 域名 body 字节一致）
• 只处理 POST + JSON；body 解析失败、rewrite 抛错、messages 非数组 —— 一律原样放行
• 关掉总开关后，发出的 body 与原请求字节级一致

兼容通道：pack.js 行钩子（可选，不再是依赖）

旧方案仍保留，在 pack.js 里插一行：

;globalThis.__wbLexicon?.rewrite?.(messages);

它的作用变成「兜底拦截非 fetch 请求」（比如插件自己起的 undici 实例）。 装不上不影响使用 —— 面板会显示「旧版钩子未打上（不影响使用）」， 而不是像以前那样报「未打钩子」让人以为坏了。

安全边界

• 判定顺序：先看总开关 → 再看 URL 是否 WB → 再看 method 是否 POST → 才碰 body
• 任何一步不满足就 return original(...)，开销是一条 URL 字符串匹配
• 可完整卸载（恢复原 fetch 引用），测试里验证过引用相等

手动控制（可选）

# 只检查，不改文件
node -e "import('./src/patch.mjs').then(m=>console.log(m.inspectLexicon(m.resolvePackFile())))"

# 打钩子（默认 dry-run，这里显式落盘）
node -e "import('./src/patch.mjs').then(m=>console.log(m.applyLexiconPatch({dryRun:false})))"

# 移除钩子（⚠️ meter 插件也依赖这行，会由它的自愈重打回来）
node -e "import('./src/patch.mjs').then(m=>console.log(m.revertLexiconPatch()))"

---

已知边界

• 只对本机 OFM 进程内的请求生效（服务器上反代的流量要单独装）
• 上游如果换关键词（不再拦 DeepSeek Harness），本插件就不需要了 —— 关掉总开关即可

主通道（fetch）：与 OFM 版本无关

只要目标插件用 globalThis.fetch 发 chat/completions，任何 OFM 版本都能拦。

兼容通道（pack.js 钩子）：只支持 OFM v2.5.2 ~ v2.5.7

这是 14 个版本全量实测的结论：

图里的 wb 是 pack.js 中 workbuddy 字符串的出现次数：正常 41 次，v2.5.8 骤降到 4 次 —— 这是「渠道被移除」最直观的信号。

所以如果你的 OFM 是 2.5.1 及以下，面板会显示「旧版钩子未打上」—— 这不影响主功能，fetch 通道照常工作。若想用上兜底，需升级到 v2.5.2~v2.5.7 区间内。

⚠️ 不要把 OFM 升到 v2.5.8+：那个版本移除了 WorkBuddy 渠道， 本插件的所有通道都会失去意义（没有 WorkBuddy 请求可拦了）。

• 如果某个反代插件用 undici 直连（不经 globalThis.fetch），fetch 钩子拦不到， 这时才需要 pack.js 那行；两者都失效时面板会明确显示原因

---

仓库体积

克隆实测约 0.35 MB（.git 131 KB + 工作区 220 KB）。 代码本体不到 100 KB，其余是文档和兼容矩阵图。

演示视频（MP4 2.4 MB / GIF 3.1 MB）不在仓库里，也不在 git 历史里 —— 它们放在 Release 附件和 README 的外链里。

v1.1.5 期间做过一次历史清理（git filter-repo），把早期误提交的视频 从整条历史中移除，clone 体积从 10.47 MB 降到 0.35 MB。 如果你在此前 clone 过，请重新 clone —— 旧的本地副本历史与远程已不一致。

如果你要重新生成演示视频，源码在 _video/（render.mjs / mix-bgm.mjs 等）， 按里面的注释可以用 ffmpeg 重建（渲染产物已被 .gitignore 忽略）。

---

许可

MIT © 2026 balong