dsh win 更新后用不了模型，出现 本轮运行失败unknown prompt variable "{{cwd}}" in section "deployment:persona-suffix"; registered variables: provider, model UNKNOWN

[Goron01]

dsh win 更新后用不了模型，出现 本轮运行失败unknown prompt variable "{{cwd}}" in section "deployment:persona-suffix"; registered variables: provider, model UNKNOWN

更新前是0.2.0 rc2 一切正常

[Goron01]

[w44p]

一样的问题

[Turroise]

同款bug（手动狗头）

[argszero]

What the error is

Prompt assembly interpolates {{variable}} references strictly (packages/core/system-prompt/src/index.ts:342-372): an unregistered name is not left as literal text, it throws, and the throw happens while the request is being assembled — before the model is called — so the whole turn fails with 本轮运行失败 and the session cannot continue.

At 0.2.1-rc.1 (c6e89e6755) the loop registers exactly two variables, provider and model (packages/core/agent-loop/src/index.ts:389-390). That is precisely the set your message names. There is no registration site for cwd anywhere in the tree — git grep "\.variable(" over every src/ returns those two lines and nothing else.

The boundary is 0.2.0-rc.2 → 0.2.1-alpha.2, and it was deliberate

At dsh-v0.2.0-rc.2 both sides existed:

• packages/core/agent-loop/src/index.ts:372 — ctx.systemPrompt.variable('cwd', context => context.agent?.session.header.cwd)
• packages/bundle/web-app/cordis.patch.yml:18 — personaSuffix: Your working directory is {{cwd}}. (the same line sat in the headless, sdk-app and acp-app patches)

Commit 79bd3d8da7 — feat(session): centralize working directories and directory context, 2026-09-13 — removed both: the variable registration and the clause in all four bundles. It is first contained in tag dsh-v0.2.1-alpha.2 and is not an ancestor of dsh-v0.2.0-rc.2. At 0.2.1-rc.1 the shipped web patch carries only personaPrefix: You are a coding agent powered by the {{model}} model. and no suffix at all.

So "it worked on 0.2.0-rc.2" is exact, and the removal was intentional: the working directory stopped being baked into the persona and became runtime context instead (working-directory:current, required: true, interpolate: false — packages/session/working-directory/src/index.ts:90-96).

Which means the reference is coming from a layer the upgrade does not rewrite

Profile composition is bundle layers → the profile's own patch file → the home patch file → --patch argv, and only the first of those comes from the installation. A new release replaces its own shipped text; it never touches the layers below. The places a surviving personaSuffix can live:

Layer	Path (Windows)
the active profile's patch file	%USERPROFILE%\.dsh\profiles\<profile>\cordis.patch.yml
the home patch file	%USERPROFILE%\.dsh\cordis.patch.yml
a preset row @deepseek-ai/dsh-persona with suffix:	same two files
a profile-pinned copy of an older @deepseek-ai/dsh-web-app	<profile>\node_modules\ — bundle resolution is installation-first, then the profile, so a profile-local copy can still supply the old patch file

One command settles which one it is — the config dump prints every layer with the file it came from, and composes nothing:

dsh --profile web --dump-config            # bundles + your profile layer + home layer + argv
dsh --profile web --dump-default-config    # the same, without your layer

The system-prompt row's personaSuffix appears in the second output if it is still shipped, and only in the first if it is yours.

The fix

Delete the personaSuffix line — or just the Your working directory is {{cwd}}. sentence — from the file the dump names, then restart. Nothing is lost: the current directory reaches the model as required runtime context, and the shipped bundles stopped putting it in the prompt for that reason. packages/core/system-prompt/README.md:78 states the same remedy, which is where the maintained answer for this exists.

Why someone can have this without remembering an edit

The configuration editor persists a row's whole effective config, not the changed field. In packages/boot/config-editor/src/index.ts, edit() derives next from structuredClone(entry.options.config ?? {}) and then writes config: next into your profile patch; the key is removed only when next deep-equals the inherited layer. So a single settings save against the system-prompt row under a release whose default carried the clause pins that sentence — variable reference included — in your own file permanently, and every later release's removal of it cannot reach you.

Three things worth fixing upstream, smallest first

1. The error is missing the one fact that makes it actionable. It names the section and the registered set but not the layer that supplied the text — and with four composable layers that is the whole question. The dump machinery already knows the answer per layer; surfacing the file in the message (or pointing at --dump-config) turns "the app cannot use any model" into a one-line self-service fix.
2. There is no user-facing troubleshooting entry. The remedy exists only in a package README that plugin authors read. This report has four reporters in an hour; the shape will recur every time a shipped prompt default changes.
3. A release that removes a variable could carry the cleanup itself — strip the dead clause from user layers on load, or have the config editor omit each key that equals its inherited default instead of persisting the whole object.

This is the same shape as #9952 (a stale models field in a profile after an upgrade): an upgrade moves shipped defaults, a materialized user layer keeps the old value, and a newer, stricter reader rejects it at runtime rather than ignoring it. Worth treating as one class — the shared defect is that nothing distinguishes "the user chose this" from "the user's file froze a default that no longer exists".

[argszero]

A plugin that restores the name

I built the shim described above: @argszero/dsh-legacy-prompt-vars (dsh-legacy-prompt-vars).

It registers cwd on ctx.systemPrompt when it mounts, and the registration goes away with the mounting fiber. The value comes from, in order: the effective directory reported by the workingDirectory service — what the tree means by "current" after 79bd3d8da7 — then the session header's original project, which is what the removed registration actually returned in 0.2.0-rc.2, then a configured fallback (the launch directory by default). source: original swaps the first two, if the clause in your profile is meant to name the project the session started in.

Two properties it holds on purpose, because getting either wrong would replace your current error with another fatal one:

• it never answers undefined — the renderer treats that as fatal too (prompt variable "{{cwd}}" has no value for this assembly), so an unreadable directory resolves to the fallback;
• it never throws — the provider runs inside request assembly, so an exception there is a dead turn with a stranger stack trace.

It also steps aside if a future release registers cwd again: the duplicate registration is refused, reported, and the tree's own provider stays in force.

Scope, deliberately: only cwd is restored. 0.2.0-rc.2 registered three names (provider, model, cwd) and cwd is the one that commit took away; a typo like {{cwdd}} still fails loudly, which is what the strict interpolator is for.

Status: repository first, npm next. The registry is unreachable from this machine right now, so there is nothing to npm install yet — from git in the meantime:

npm install github:argszero/dsh-legacy-prompt-vars

and mount it from your profile's cordis.patch.yml:

- insert:
    - id: legacy-prompt-vars
      name: '@argszero/dsh-legacy-prompt-vars'

The packed artifact is @argszero/dsh-legacy-prompt-vars@0.1.0, 12 files, shasum f0cf24ee7d08cbe54110090ed9c0f2cc301d50bf; the same version goes to npm once the registry answers.

This is still not the fix. Deleting the stale clause from the file dsh --profile <name> --dump-config names is, and the three changes in my earlier reply are what stops this family from recurring at all. The plugin is for profiles where that edit is not available today — a managed deployment, a shared profile, a machine you cannot reach.

What you can weigh it on: the suite mounts the real @deepseek-ai/dsh-system-prompt service and calls the real renderPrompt, reproduces your message character for character (unknown prompt variable "{{cwd}}" in section "deployment:persona-suffix"; registered variables: provider, model), then renders the same profile again after the mount. 63 tests, 100% line, branch and function coverage on the four source modules, and 33 mutation arms that must all be caught before a release.

[EliotOK]

让Astra大人给我修了一下：

---

我遇到的报错是：

unknown prompt variable "{{cwd}}" in section "deployment:persona-prefix";
registered variables: provider, model

所有模型都会失败，因为错误发生在提示词组装阶段，尚未调用模型接口。

排查后发现两个关键点：

1. 命令行版与桌面版可能不是同一版本。 我这里 PowerShell 的 dsh --version 是 0.1.7-rc.1，正在运行的桌面版是 0.2.1-rc.2。因此，命令行执行 dsh --profile web --dump-config 得到的配置不能直接代表桌面版。
2. 桌面版内置模板已经更新，但本地自定义预设仍使用旧变量。 我的默认出图预设在 @deepseek-ai/dsh-persona 的 config.prefix 中保留了 {{cwd}}。切换模型不会切换预设，所以所有模型都报同一个错。

修复方法是定位当前实际加载的配置／预设，备份文件，然后删除提示词中失效的工作目录插值。例如：

- You are an image-generation and prompt-engineering agent powered by the {{model}} model, working in {{cwd}}.
+ You are an image-generation and prompt-engineering agent powered by the {{model}} model.

如果报错是 deployment:persona-suffix，则检查 personaSuffix 或预设的 config.suffix，是否包含：

Your working directory is {{cwd}}.

删除这句即可，不要删除整个配置文件，也不要删除其他用途的 cwd 配置字段。

修改后完全退出桌面版（包括托盘）并重新启动，再发送消息测试。

验证情况： 使用桌面版自身的配置加载器复查，修改前只有自定义出图预设包含未知变量；修改后配置加载成功，全部已加载人设模板的变量检查通过。实际模型回复仍待重启后验证。

建议排查时同时确认：运行的是哪一份安装、使用哪个 profile、错误模板来自哪个插件或配置层，不要仅凭另一份 CLI 的导出结果判断桌面版配置。

[Cattttt33]

我是小白，我用最傻瓜的方法把报错发给了dsh慢慢改完了

[argszero]

Publication status: @argszero/dsh-legacy-prompt-vars@0.1.0 is on the registry, so the mitigation from my earlier reply is installable rather than only described.

Verified through the registry's version endpoint: dist.shasum = f0cf24ee7d08cbe54110090ed9c0f2cc301d50bf, gitHead = 808e73c2dd49208f373bbe6b077ba5d78fcbe6c8; source https://github.com/argszero/dsh-legacy-prompt-vars

dsh plugin add @argszero/dsh-legacy-prompt-vars

It restores the removed prompt variables at the provider layer instead of rewriting anyone's stored profile, so a config layer that still references {{cwd}} keeps working without the user editing a file they cannot easily find. It never returns undefined, never throws during request assembly, and never takes over a name somebody else registered — those three constraints are what keep it from becoming a second way to fail.

[shan1110]

打开配置文件

搜索dsh-persona 然后删除suffix: Your working directory is {{cwd}}. 就可以了

[ZhaoKe1024]

I resolved this locally by editing the DSH configuration files:

1. Open the local DSH directory in VS Code:

   ~/.dsh/
   

2. Search for the keyword:

   {{cwd}}
   

3. In every configuration file returned by the search, replace:

   Your working directory is {{cwd}}.
   

   with:

   Your working directory is the current workspace.
   

4. Fully quit and restart DSH, then start a new conversation/turn.