DeepSeek Harness ERR_PNPM_ADDING_TO_ROOT: pnpm version

"I configured nothing wrong — a fresh profile, one dsh plugin --profile wprobe add <tgz>, and it reports ERR_PNPM_ADDING_TO_ROOT" — the error looks like a broken plugin, but it is actually decided by the pnpm major version on your machine. dsh generates pnpm-workspace.yaml when initializing a profile, while the pnpm add it forwards carries no --workspace-root; pnpm 9 blocks it and pnpm 11 does not (#10629). Check the version first, then choose a path.

DeepSeek Harness: Step 1: check the pnpm major version

This is a version fork, so looking at whether pnpm on PATH is 9 or 11 is faster than reading any log.

1. Run pnpm --version and note the major.
2. 9.x: a very high chance this is the issue.
3. 11.x: the community comparison succeeded without -w, so you are probably hitting something else.
4. If multiple pnpm installs exist (corepack, nvm, global), use where pnpm or which pnpm to confirm which one actually runs.
5. When the version is unclear, run a minimal reproduction first instead of suspecting the plugin package.

DSH plugin: Step 2: inspect what the profile actually contains

A dsh-generated profile ships with its own workspace declaration, and that is what determines pnpm's behavior.

1. Open ~/.dsh/profiles/<name>/ (on Windows, C:\Users\<user>\.dsh\profiles\<name>).
2. Read pnpm-workspace.yaml: it contains packages: - ., nodeLinker: hoisted, and autoInstallPeers: false.
3. Read package.json: the name looks like dsh-profile-<name>, with private: true and no dependencies.
4. So pnpm treats the profile directory as a workspace root.
5. Meanwhile the actual command in the log is pnpm add "<spec>", without -w.
6. Conclusion: dsh first creates a root, then installs into it with a command pnpm does not welcome at the root.

DeepSeek Harness: Step 3: three fixes, ordered by blast radius

Try the command-level bypass first, then configuration, and upstream code changes last.

1. Command level: add -w yourself, i.e. dsh plugin --profile <name> add -w <spec>; the community measured exit 0.
2. Configuration level: write an .npmrc beside pnpm-workspace.yaml with ignore-workspace-root-check=true.
3. Upstream level: have dsh automatically add --workspace-root when forwarding add/remove; for a managed profile the profile is always the root, so the argument is always correct.
4. Another upstream option: stop generating pnpm-workspace.yaml for single-package profiles at all.
5. Whichever you choose, verify once by creating a clean profile and installing again, avoiding interference from old caches.

DSH Plugin: Controlled comparison: same layout, only the version changes

The community ran the cleanest single-variable comparison, and the conclusion is obvious.

The minimal reproduction is just as direct: use a tarball with no dependencies (to rule out dependency resolution), use a brand-new profile name so dsh creates the directory itself, then run dsh plugin --profile wprobe add D:\probe\dsh-probe-pkg-1.0.0.tgz.

DeepSeek Harness: What the scene looks like: terminal versus log

The terminal shows only a generic failure; the full command is in the log, and comparing the two confirms it.

# terminal
dsh: initialized profile wprobe at C:\Users\<user>\.dsh\profiles\wprobe
ERR_PNPM_ADDING_TO_ROOT  Running this command will add the dependency to the workspace root ... 
dsh: plugin command failed; diagnostics: ...\.plugin-manager\logs\operation-iVz9LN\pnpm.log
[exit code: 1]

# pnpm.log
Command failed with exit code 1: pnpm add "D:\probe\dsh-probe-pkg-1.0.0.tgz"

If pnpm add has no -w after it, cross-check pnpm --version and the case is basically closed.

DSH plugin: Why this error is especially hard to diagnose

The error contains no hint about the pnpm major version, leaving users unable to tell a version support problem from a plugin problem.

1. The terminal shows only dsh: plugin command failed and a log path.
2. The real command and error live in .plugin-manager/logs/operation-*/pnpm.log.
3. The ERR_PNPM_ADDING_TO_ROOT in the log is pnpm's wording and says nothing about dsh.
4. The result: when automation invokes this command, all it can surface is a generic failure.
5. The community notes that a downstream project hit the same trap with a byte-identical symptom.

Should pnpm 9 count as supported?

The community has no verdict, but it affects you: if 9 is out of support, dsh should state the version requirement instead of throwing a pnpm internal error.

1. Ask yourself whether other pnpm-dependent workflows already require 10+.
2. If the team upgrades to pnpm 11 together, the problem disappears.
3. If you must stay on pnpm 9, use the command-level or configuration-level bypass above.
4. Either way, include pnpm --version in the failure report.
5. If upstream adopts it, the minimal change is adding --workspace-root when forwarding, plus a pnpm 9 regression test.

Cautions

Read the log command and the pnpm major before touching the plugin.

1. Do not suspect the plugin package first. A dependency-free tarball fails the same way.
2. Do not read only the terminal output. The real command is in pnpm.log.
3. Do not delete pnpm-workspace.yaml by hand. dsh maintains it and may regenerate it.
4. Do not test on the wrong profile. Reproduce with a brand-new profile name to rule out historical interference.
5. Record the pnpm major version. It is the only basis for separating "compatibility defect" from "unsupported environment".

If your pnpm.log command already contains -w and still fails, this is not the issue — check the network source or package signature.See Fix "pnpm failed in profile directory" for DSH plugins for the related case.