[Bug] dsh plugin add fails at the profile workspace root without -w (ERR_PNPM_ADDING_TO_ROOT)

[xmanrui]

Summary

dsh plugin --profile web add <package> fails on affected pnpm versions because DSH initializes the profile directory as a pnpm workspace root, then forwards pnpm add without explicitly targeting that root.

This is not specific to one plugin. Any third-party plugin installation can be blocked in the same environment.

A user first reported the failure while installing @xmanrui/dsh-im: xmanrui/dsh-im#15

Reproduction environment

• @deepseek-ai/dsh: 0.1.0-rc.6
• The published 0.1.0-rc.7 tarball was also inspected and has the same forwarding behavior
• Node.js: v24.13.0
• macOS
• Reproduced with pnpm 9.15.9
• Fresh temporary DSH_HOME

Steps to reproduce

export DSH_HOME="$(mktemp -d)"
dsh plugin --profile web add @xmanrui/dsh-im

Actual result

dsh: initialized profile web at .../profiles/web
ERR_PNPM_ADDING_TO_ROOT Running this command will add the dependency to the workspace root...
dsh: pnpm failed in profile directory .../profiles/web

The command exits with status 1.

Expected result

dsh plugin --profile web add <package> should install the plugin into the selected profile without requiring users or every plugin author to know that the profile is implemented as a pnpm workspace root.

The DSH CLI help itself currently presents this form without -w:

dsh plugin --profile tui add <package>

Root cause

DSH profile initialization writes a pnpm-workspace.yaml like this:

packages:
  - .

nodeLinker: hoisted
autoInstallPeers: false

The plugin command then runs pnpm in that directory and forwards the supplied arguments verbatim. On pnpm versions that enforce the workspace-root safety check, this becomes effectively:

cd "$DSH_HOME/profiles/web"
pnpm add @xmanrui/dsh-im

Since the current directory is the workspace root, pnpm rejects the operation unless -w or --workspace-root is explicit.

The url.parse() deprecation warning sometimes printed in the same report is unrelated to the nonzero exit.

Verified workaround

Only adding -w fixes the failure:

dsh plugin --profile web add -w @xmanrui/dsh-im

With pnpm 9.15.9, the original command exits 1. The command with -w exits 0, fully installs @xmanrui/dsh-im@0.11.0, writes it to dependencies, adds it to dsh.profile.bundles, and passes:

dsh --profile web --dump-config

Compatibility checks:

pnpm	Without -w	With -w
8.15.9	ERR_PNPM_ADDING_TO_ROOT	success
9.15.9	ERR_PNPM_ADDING_TO_ROOT	full install success
10.0.0–10.4.x	ERR_PNPM_ADDING_TO_ROOT	success
10.5+ with the current single-package profile	happens to succeed	success
11.22.0	not used as a compatibility assumption	success

Relying on newer pnpm behavior is less robust than stating the intended root target explicitly.

Proposed fix

Because dsh plugin --profile <name> owns and manages the selected profile directory, DSH should explicitly target the workspace root for profile dependency mutations instead of requiring every plugin README and installer to add a raw pnpm implementation flag.

For example, normalize the forwarded invocation so add and other relevant profile-root mutations include --workspace-root, then update the CLI help example and add regression coverage with pnpm 9 plus the latest supported pnpm.

Suggested regression assertions:

1. Initialize a fresh profile.
2. Run the documented dsh plugin --profile web add <package> command.
3. Assert exit status 0.
4. Assert the dependency is present in package.json.
5. Assert a bundle package is reconciled into dsh.profile.bundles.
6. Assert dsh --profile web --dump-config succeeds.

Impact

This blocks first-time installation for every community plugin on affected pnpm versions. The error occurs before plugin download or plugin code execution, so plugin packages cannot fix the underlying DSH command contract themselves; they can only document -w as a temporary workaround.

[denial123789]

The rc.7 source confirms why the plugin package cannot repair this boundary itself. initProfile() creates a pnpm-workspace.yaml with packages: ['.'], while runPlugin() executes the forwarded arguments through spawnSync('pnpm', args, { cwd: profileDir }). The CLI help simultaneously presents dsh plugin --profile tui add <package> without an explicit root target.

Because pnpm rejects the invocation before download or package execution, the bounded user workaround is correctly scoped to the DSH-owned operation:

dsh plugin --profile web add -w <reviewed-package>

I would avoid recommending a global ignore-workspace-root-check=true; it weakens the safeguard for unrelated workspaces. Also, a zero pnpm exit is only the first gate. A useful verification sequence is: expected dependency in the profile manifest, package resolvable from that profile, a declared bundle reconciled into dsh.profile.bundles, and dsh --profile web --dump-config showing only the intended layer.

For the durable CLI fix, adding --workspace-root only to profile-root mutation verbs preserves user intent while leaving diagnostic verbs and the existing relative path-spec anchoring behavior intact. The regression matrix should include pnpm 9 plus the newest supported release, add/remove symmetry, bundle reconciliation, config dump, and add . / file: checkout anchoring.

Source-pinned runbook and failure routing: https://sandbaseai.github.io/deepseek-harness-handbook/pnpm-adding-to-root.html

Disclosure: independent SandBase community handbook, not official DeepSeek documentation.

[rjn32s]

Traced this to initProfile() in packages/boot/app-boot/src/profile.ts. The generated pnpm-workspace.yaml declares packages: ['.'], making the profile directory its own workspace root, but nothing disables pnpm's "did you mean the workspace root?" guard — so any forwarded pnpm add (not just a specific plugin) hits ERR_PNPM_ADDING_TO_ROOT, matching what's already been found here.

The guard exists to catch an accidental root-level add in a multi-package workspace. A profile has exactly one member (itself), so there's no other package the add could have meant — ignore-workspace-root-check can just always be on for this shape.

Verified fix, tested on pnpm 9.12.0 / Node 22.23.2 against a from-source 0.1.1-rc.2 checkout — a brand-new profile with zero manual workarounds installs cleanly on the first try:

// packages/boot/app-boot/src/profile.ts

const PROFILE_NPMRC = `auto-install-peers=false
ignore-workspace-root-check=true
`

export function initProfile(dir: string, bundles: readonly string[]): void {
  // ...existing package.json / cordis.patch.yml / pnpm-workspace.yaml writes...
  const npmrcPath = join(dir, '.npmrc')
  if (!existsSync(npmrcPath)) writeFileSync(npmrcPath, PROFILE_NPMRC)
}

(The auto-install-peers=false line is there because it's needed for the other half of this — see #984 — and both belong in the same generated file.)

Happy to send a PR with this, but saw the note in CONTRIBUTING.md that external PRs aren't being taken right now, so posting the diff here instead.