Repository navigation
Releases: Venshell/dsh-workbuddy-connect
Release list
0.8.3 — 文档修正
0.8.2 — 国内版 11128 拦截修复
0.8.2 — 国内版插件用不了的问题已修复
- 修复国内版对话被网关回
11128「请求被拦截,请重新发送」、插件无法正常使用的问题。 - 修复部分请求被回
11101(非流式请求不支持)而失败的问题。 - 错误提示现在带上游的
code/msg,再出问题能直接看出是哪一类。 - 新增
engines.dsh,同一0.2.x内核线内升级 DSH 不必重装插件。
安装
dsh plugin --profile web add @venshell/dsh-workbuddy-connect@0.8.2内核 0.2.1-rc.3 → 插件 0.8.2;完整对应表见 README。
0.8.0 — CN 11128 双触发面修复与模型目录双源合并
0.8.0
Fixes three CN (copilot.tencent.com) defects that together made the provider
look broken: two distinct body shapes drew 400 / 11128「请求被拦截,请重新发送」,
and the model picker lost 15 of its 20 ids. Each fix is pinned by a measurement
against a live CN account.
Fixed
CN requests rejected with 11128 when the body carried role: "developer" (#201)
The A/B is exact: on identical credentials, headers and models, system + user
answers 200 while developer + user answers 400 / 11128. International was
unaffected only because it routes through prepareChatBody; the CN branch
stripped the effort and relied on the shim having normalised the role first, so
any caller bypassing the shim leaked developer onto the wire. The CN path now
performs the rewrite itself, and because the rewrite is idempotent the existing
"the shim already did this" assumption no longer has to hold.
CN requests rejected with 11128 for the harness brand in the system prompt (#204)
The same code fires for a system (or developer) message carrying the full
two-word harness brand, which the shipped runtime-context opener contains — so
every request from an unmodified install hit it, and neither changing the
account nor the API key helped. Live bisection showed that deleting either
clause of that paragraph clears the rejection, and so does shortening the brand
alone; this release takes the smaller change and shortens only the brand,
leaving the rest of the sentence verbatim. The pattern matches spaces and tabs
only, so paths and package names such as deepseek-harness and
@deepseek-ai/dsh-system-prompt are untouched, and user / tool content is
never rewritten.
Model picker missing 15 of 20 CN models
/v3/config stopped serving a cli agent to App-shaped clients, and the flat
models list that replaced it is mostly completion-specialised rows
(hunyuan-3b, codewise-*) rather than chat models, so the picker fell back to
the static roster. The chat endpoint never stopped serving those ids — each
answers 200 with a normal SSE stream — so this was a catalog-source defect, not
an upstream withdrawal. The CN catalog is now read from two documents and
unioned:
/v2/enterprises/personal/models— the console document the desktop App's own
selector reads, which still carries thecliagent with its full roster./v3/config— the product document, read with the CLI User-Agent.
Neither roster is a superset of the other (measured: the console document lists
auto, the product document lists hy3-x and minimax-m2.7), which is why
this takes a union rather than switching sources. Each reader returns its roster
or its error, so one route failing degrades to the other; a double failure is
reported with the product document's HTTP status, which keeps
classifyUpstreamError able to separate an outage from a dead session from a
bad catalog.
Unchanged
The international provider keeps its single catalog source, App-shaped
User-Agent and X-Product header; the console route is CN-only and is never
read for a global credential. Regression tests pin both.
Project
This is the first release maintained in Venshell/dsh-workbuddy-connect. The
original repository is no longer available; this fork carries the full commit
history and credits every prior contributor — see
AUTHORS.md.
Verification
- 895 tests pass across 60 files, including 22 new assertions covering both
11128triggers, the union and every degradation path. - Typecheck clean on both
tsconfig.jsonandtsconfig.client.json. - End to end against a live CN account: all 21 merged catalog ids go through
prepareChatBody→prepareCnChatBodyand answer 200, withrole: "system",
stream: trueand the brand removed. One id (glm-5.1) returns
11133 / extError 1210, an upstream model-side parameter rejection that also
affectsglm-5.0-turboand predates this change.