dsh plugin add fails with ERR_PNPM_ADDING_TO_ROOT on a fresh dsh-initialized profile (pnpm 9 in PATH)

[MK-320]

Environment

dsh	0.2.1-rc.2
Node	v22.22.0
pnpm in PATH	9.15.9
OS	Windows 11

Summary

dsh plugin --profile <name> add <spec> fails with ERR_PNPM_ADDING_TO_ROOT on a freshly initialized profile.

dsh initializes every profile with its own pnpm-workspace.yaml (packages: - .), but the plugin command forwards pnpm add without --workspace-root. On pnpm 9 that is rejected by pnpm's workspace-root guard.

Minimal reproduction

1. Machine where pnpm --version reports 9.x.
2. Build a dependency-free tarball, so dependency resolution cannot be the cause.
3. Use a brand-new profile name (so dsh creates it):

dsh plugin --profile wprobe add D:\probe\dsh-probe-pkg-1.0.0.tgz

Actual

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,
which might not be what you want - if you really meant it, make it explicit by running this
command again with the -w flag (or --workspace-root). ...
dsh: plugin command failed; diagnostics: ...\.plugin-manager\logs\operation-iVz9LN\pnpm.log
[exit code: 1]

.plugin-manager/logs/operation-*/pnpm.log contains:

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

The profile that dsh had just created contains:

# pnpm-workspace.yaml — generated by dsh itself
packages:
  - .

nodeLinker: hoisted
autoInstallPeers: false

// package.json — generated by dsh itself
{ "name": "dsh-profile-wprobe", "private": true, "dependencies": {} }

So dsh creates a workspace root and then immediately runs a command that pnpm refuses to run in a workspace root.

Expected

dsh plugin add should install into the profile it just created.

Control experiments (same layout)

pnpm version	-w passed to pnpm?	Result
9.15.9	no	ERR_PNPM_ADDING_TO_ROOT, exit 1
9.15.9	yes	exit 0, installed
11.28.5	no	exit 0, installed

Notes:

• The failure is pnpm-major dependent: pnpm 9 enforces the workspace-root guard, pnpm 11 does not.
• Passing -w through the plugin command makes the identical command succeed:
  dsh plugin --profile wprobe add -w <tgz> → exit 0.

Why this matters

Tools that automate companion/plugin installation by driving dsh plugin --profile ... add break on machines where pnpm 9 is the one on PATH.

One concrete downstream case: OpenDesign's agent-companion setup invokes exactly this command and can only surface a generic failure to the user (nexu-io/open-design#8919). That report was traced to the same pnpm add call, and the ERR_PNPM_ADDING_TO_ROOT symptom there matches this reproduction byte-for-byte.

It is also worth noting the failure gives no hint about the pnpm major, so a user cannot tell whether they hit a version-support problem or a plugin problem.

Possible fixes (any one would close this)

1. Have dsh plugin append --workspace-root when forwarding add/remove for a managed profile — the profile is the workspace root by construction, so this is always correct for that command.
2. Or write ignore-workspace-root-check=true into an .npmrc next to the generated pnpm-workspace.yaml.
3. Or stop generating pnpm-workspace.yaml for single-package profiles.

Question

Is pnpm 9 outside the supported range for dsh plugin?

If it is supported, the forwarding looks like a bug. If it is not supported, documenting a minimum pnpm major (and warning when a lower one is detected) would already save a lot of debugging time — right now the only signal is an opaque pnpm error inside a log file.

Thanks!

[imRahul05]

I think this is the same underlying issue reported in [Discussion #4680](#4680): the generated profile contains a pnpm-workspace.yaml, so pnpm treats the profile directory as a workspace root.

Your reproduction provides useful additional confirmation. With pnpm 9.15.9, a bare pnpm add fails, while passing -w succeeds. Your pnpm 11.28.5 control test also succeeds without the flag.

If pnpm 9 is intended to be supported, I'd fix this in DSH's managed-profile installation path by explicitly passing --workspace-root when invoking pnpm add. DSH owns both the generated profile layout and the package-installation command, and the intended dependency target is the profile's package.json.

Alternatively, if pnpm 9 is outside the supported range, documenting the minimum supported version and reporting it clearly would prevent users from having to diagnose this through the pnpm log.

I'd add a regression test using pnpm 9.15.9 and a local tarball, verifying that a newly initialized profile receives the dependency successfully. I'd test removal separately before assuming it needs the same change.

One question remains: is pnpm 9 officially within DSH's supported version range? That determines whether this is a compatibility bug or an unsupported-environment issue.