DeepSeek Harness unknown prompt variable {{cwd}} fix

unknown prompt variable "{{cwd}}" in section "deployment:persona-suffix"; registered variables: provider, model — the error already gives away half the answer: only two variables are registered now, and cwd is not one of them. It is not a typo; upstream deleted it. The deletion landed in 0.2.1-alpha.2, and the leftover line is in your config file, which an upgrade will not clean for you (#11152).

DeepSeek Harness: Before: the old version treated cwd as a built-in

Before alpha.2, cwd was a registered prompt variable, and the default persona suffix used it.

1. The old system prompt had a persona suffix shaped like "Your working directory is {{cwd}}."
2. That suffix was written into the profile's config patch.
3. As long as the version still registered cwd, interpolation worked and you saw nothing unusual.
4. This layer is "historical configuration": it travels with your profile, not with the release package.
5. Remember it: every later problem comes from "config outliving code".

DSH plugin: When: alpha.2 removed the registration and default suffix

Commit 79bd3d8da7 (the first dsh-v0.2.1-alpha.2 tag) removed the cwd registration and the default persona suffix, handing the job to runtime context.

1. After removal, only provider and model remain as prompt variables.
2. The working directory is now supplied by the runtime context entry working-directory:current.
3. This is a design change, not a defect — so it will not be "fixed back in the next version".
4. Interpolation happens during request assembly, where unregistered names are a hard error.
5. So there is no "emit it verbatim" fallback, and the whole turn fails.

DeepSeek Harness: After: the leftover line fails every turn

Upgrades do not rewrite your config, and the config editor writes the whole object back, so the old value is frozen in the profile.

1. The leftover {{cwd}} sits in one of three places: the profile's cordis.patch.yml, a home-level patch, or a preset line.
2. An upgrade replaces release package contents and does not rewrite these files.
3. The config editor writes back the entire config object, not just the field you edited.
4. The result: values materialized by older versions are preserved forever.
5. Every request assembly hits the same unregistered name, which shows up as "every turn fails".

DSH Plugin: The timeline in one sentence

The old config referenced a variable name that was later deleted; the deletion happened in code, the leftover lives in config, and the two can never agree.

DeepSeek Harness: Two fixes: delete a line, or install the shim

The lasting fix is deleting that line; to get running first, install the compatibility plugin.

1. Locate the text first: search for {{cwd}} in the profile's cordis.patch.yml and in preset configs.
2. When found, delete that line (or the whole persona suffix), or switch to runtime context where the working directory is needed.
3. Restart and confirm unknown prompt variable no longer appears.
4. If you cannot change config right now, install the community shim:

dsh plugin --profile <your-profile> add \
  "github:argszero/dsh-legacy-prompt-vars#808e73c2dd49208f373bbe6b077ba5d78fcbe6c8"

5. After installing, --dump-config should show a legacy-prompt-vars mount entry, meaning dsh inserted it itself.
6. The community verified on a clean profile with the 0.2.1-rc.3 runtime: exit code 0 and the entry present.

DSH plugin: The shim's boundary

It only re-registers retired variable names; it does not repair the layer holding the old text.

1. It lets a persona suffix containing {{cwd}} assemble again, so turns stop failing.
2. But it does not know which other old variables your config still has, and unknown names will fail the same way.
3. It is not on npm, so it can only be installed from a git spec with the commit pinned.
4. It is mitigation, not a fix — the line that should be deleted is still in your config.
5. So the advice is: use it to stop the bleeding, then schedule time to delete the config.

One-minute locate the leftover

The section name in the error plus one full search narrows it to a specific file.

1. Note the section in the error, such as deployment:persona-suffix.
2. Search for {{cwd}} in the profile directory, starting with cordis.patch.yml.
3. Then check the home-level patch and preset configs, searching all three.
4. Match what you find against the section name to confirm it is this occurrence and not a same-named copy.
5. Back up files before changing them so you can roll back.

Cautions

Delete the stale reference instead of editing the release package.

1. Do not edit the release package. Variable registration lives in core code, and package edits are lost on the next upgrade.
2. Do not search only one file. Leftovers can sit in the profile patch, a home patch, or a preset.
3. Do not treat the shim as a long-term solution. It maintains a compatibility layer for retired names.
4. Record the section name in the error. deployment:persona-suffix points straight at the leftover.
5. Back up config before upgrading. For this class, the best diagnostic material is the config diff before and after upgrading.

If the variable in your error is not cwd, the logic is identical: first see which variables are registered now, then find the old name in your config.See DeepSeek Harness won't start: triage, Node env, port 3080 for the related case.