dsh plugin update fails with ERR_PNPM_UNEXPECTED_STORE (pnpm store location drifts)

[lyf-yulu]

dsh plugin update fails with ERR_PNPM_UNEXPECTED_STORE — pnpm store location drifts between install and update

Summary

Running dsh plugin --profile web update (the Web UI "update" flow) can fail with:

ERR_PNPM_UNEXPECTED_STORE  Unexpected store location

The dependencies at "<dsd-home>/profiles/web/node_modules" are currently linked
from the store at "<workspace>/.pnpm-store/v10".

pnpm now wants to use the store at "<home>/Library/pnpm/store/v10" to link dependencies.

The profile installs fine the first time, then a later update fails because pnpm resolves a different store location than the one node_modules was originally linked from.

Root cause

dsh plugin is a thin pnpm forwarder (apps/cli/src/plugin.ts → runPlugin) and does not pin store-dir. Starting with pnpm v10, pnpm resolves its content-addressable store location dynamically (store-path / getStorePath):

1. If the process can hard-link from the project directory into $PNPM_HOME, the store is $PNPM_HOME/store/<version>.
2. Otherwise it falls back to <mount-point>/.pnpm-store/<version>.

That hard-link probe is environment-sensitive — it flips depending on whether the process can hard-link into $PNPM_HOME (sandboxes, filesystem layout, whether $PNPM_HOME exists/writable, permissions). So the same profile directory can be:

• installed with store A (probe failed → <mount-point>/.pnpm-store/v10), then
• updated with store B (probe succeeded → $PNPM_HOME/store/v10),

and pnpm then refuses with ERR_PNPM_UNEXPECTED_STORE because the store it now wants no longer matches the one node_modules was linked from.

Reproduction

1. Install a plugin into a profile in an environment where the hard-link probe fails (e.g. a sandboxed run, $DSH_HOME on a different device, or $PNPM_HOME not yet present). The store lands at <mount-point>/.pnpm-store/v10.
2. Later run dsh plugin --profile web update in an environment where the probe succeeds. pnpm now wants $PNPM_HOME/store/v10.
3. pnpm exits with ERR_PNPM_UNEXPECTED_STORE.

Confirmed on macOS with pnpm 10.33.1: pnpm store path returns <cwd>/.pnpm-store/v10 when the hard-link probe is blocked and $PNPM_HOME/store/v10 when it is not.

Proposed fix

Pin store-dir to a stable location under the DSH home so install and update always agree, and hand it to pnpm through npm_config_store_dir (how pnpm reads npm-style config from the environment; a user's explicit --store-dir still wins).

--- a/apps/cli/src/plugin.ts
+++ b/apps/cli/src/plugin.ts
@@ -23,6 +23,7 @@ import {
   writeProfileManifest,
   type ProfileManifest,
 } from '@deepseek-ai/dsh-app-boot'
+import { resolveDshHome } from '@deepseek-ai/dsh-home-paths'
 import { INSTALL_ANCHOR } from './profile-boot.ts'
 
 const NAME = 'dsh'
@@ -111,6 +112,21 @@ function anchorPathSpec(argument: string, cwd: string): string {
   return `${prefix}${resolve(cwd, match.groups.path)}`
 }
 
+/**
+ * pnpm ≥10 resolves its content-addressable store location dynamically: it
+ * probes whether the project directory can hard-link into `$PNPM_HOME`, and
+ * when that probe fails (sandbox, cross-device layout, missing `$PNPM_HOME`)
+ * it falls back to `<mount-point>/.pnpm-store`. The probe can return
+ * different answers across runs, so a profile installed against one store
+ * later fails with `ERR_PNPM_UNEXPECTED_STORE` when an `update` resolves a
+ * different one. Pin the store under the DSH home so install and update
+ * always agree on the same location.
+ * @returns the absolute `store-dir` handed to pnpm.
+ */
+function profileStoreDir(): string {
+  return join(resolveDshHome(), 'pnpm-store')
+}
+
 /**
  * Run one `dsh plugin` invocation: init if needed, forward to pnpm, reconcile.
  * @param profile - the profile name.
@@ -130,6 +146,13 @@ export function runPlugin(profile: string, args: readonly string[]): number {
     cwd: dir,
     stdio: 'inherit',
     shell: process.platform === 'win32',
+    env: {
+      ...process.env,
+      // npm_config_* is how pnpm reads npm-style config from the
+      // environment; a user's explicit `--store-dir` on the command line
+      // still wins over this default.
+      npm_config_store_dir: profileStoreDir(),
+    },
   })
   if (result.error !== undefined) {
     const code = (result.error as NodeJS.ErrnoException).code

Notes for maintainers:

• @deepseek-ai/dsh-home-paths is already a direct dependency of apps/cli, so no manifest change is needed.
• This prevents future drift. Existing installs that were linked from a drifted store will do a one-time relink on their next pnpm install/update (pnpm's own error message already tells users to run pnpm install).

Workaround for affected users

Pin the store at the profile level so pnpm stops guessing, e.g. create <profile-dir>/.npmrc with:

store-dir=/absolute/path/to/stable/store

then run pnpm install once from the profile directory to relink node_modules, and the update will succeed afterwards.

[denial123789]

I turned this report into a source-backed operator runbook with one additional safety constraint: relink the recorded graph with pnpm install --frozen-lockfile before rerunning the DSH-owned update, so store migration does not get mixed with dependency-version drift.

The guide separates the linked, selected, and stable store identities; includes CLI-versus-Web environment evidence; and requires a second no-op mutation to prove the store decision is durable:

https://sandbaseai.github.io/deepseek-harness-handbook/pnpm-unexpected-store.html

Canonical runbook and regression gates:
https://github.com/sandbaseai/deepseek-harness-handbook/blob/main/docs/en/troubleshooting/pnpm-unexpected-store-plugin-update.md

If the proposed npm_config_store_dir repair lands upstream, I will update the page with the exact fixed commit and migration boundary.