Installing a plugin from a tarball URL fails on the second resolve: ERR_PNPM_MISSING_TARBALL_INTEGRITY (bundled pnpm 11.7.0)

[CancerTiN]

Installing a plugin from a tarball URL fails on the second resolve: ERR_PNPM_MISSING_TARBALL_INTEGRITY

Summary

A plugin installed from a GitHub tarball URL — the distribution form the ecosystem's own READMEs document (e.g. dsh-at-file) — installs fine the first time and then fails on every later resolve that reuses the same pnpm store, with an error that blames lockfile tampering:

[ERR_PNPM_MISSING_TARBALL_INTEGRITY] Cannot install package "dsh-set-session-title@https://…/v0.1.1.tar.gz":
its lockfile entry has no "integrity" field, so pnpm cannot verify the downloaded tarball.
The lockfile may be corrupted or have been tampered with. Restore it from a trusted source,
or delete it and re-run installation without --frozen-lockfile to regenerate.

The real trigger is the bundled pnpm 11.7.0 (Contents/Resources/runtime/pnpm), not the profile, the lockfile, or the desktop plugin manager: the same store and URL succeed under pnpm 11.20.0. Both pieces of advice in that message are wrong for this state — the lockfile is neither corrupt nor fixable by deleting it.

Reproduction

Deterministic, two commands, no DSH profile needed (uses the app's own pnpm binary):

APPPNPM=(/Applications/DeepSeek\ Harness.app/Contents/MacOS/DeepSeek\ Harness)   # Electron as node
PNPM="$APPPNPM --expose-internals /Applications/DeepSeek\ Harness.app/Contents/Resources/runtime/pnpm/bin/pnpm.mjs"
URL=https://github.com/CancerTiN/dsh-set-session-title/archive/refs/tags/v0.1.1.tar.gz

for i in 1 2; do
  mkdir -p /tmp/repro-$i && cd /tmp/repro-$i
  printf '{"name":"r","private":true}\n' > package.json
  printf 'packages:\n  - .\n\nnodeLinker: hoisted\nautoInstallPeers: false\n' > pnpm-workspace.yaml
  $PNPM --store-dir /tmp/store-repro add "$URL"; echo "exit=$?"
done

Result:

第 1 次: exit=0    reused 0 downloaded 1        ← lockfile gets integrity
第 2 次: exit=1    ERR_PNPM_MISSING_TARBALL_INTEGRITY, reused 1 downloaded 0

In a DSH profile the same thing happens one level up: the first profile to install the tarball succeeds, and the next profile (or a re-install after remove) fails — which is exactly how this was met. On this machine: headless installed the tarball URL successfully; the desktop profile then failed, and no amount of remove + add or deleting the profile lockfile helped.

Current behavior

#	pnpm	store	spec	result
E1	11.7.0	the polluted one	tarball URL	❌ ERR_PNPM_MISSING_TARBALL_INTEGRITY, reused 1 downloaded 0
E4	11.7.0	same	branch tarball URL (never resolved before)	✅ downloaded, integrity recorded
E5	11.7.0	same	tarball URL + --force	❌ identical failure (--force does not bypass)
E7	11.7.0	same	registry package	✅
E8	11.7.0	same	git spec github:owner/repo	✅ downloaded, integrity recorded
E9	11.7.0	fresh	tarball URL	✅ downloaded, integrity recorded
E13	11.7.0	fresh store, then reused	tarball URL, second run	❌ (the minimal repro above)
E11	11.20.0	the polluted store	tarball URL	✅ re-downloaded, integrity recorded

The lockfile written by a failed run is itself evidence — the resolution is recorded without integrity, which is what the next run then rejects:

packages:
  dsh-set-session-title@https://…/v0.1.1.tar.gz:
    resolution: {tarball: https://…/v0.1.1.tar.gz}
    version: 0.1.1

Against a healthy store the same entry is written as:

    resolution: {integrity: sha512-sno2lG2+…==, tarball: https://…/v0.1.1.tar.gz}

Expected behavior

Installing a plugin from a tarball URL works on every machine and every store, at least as reliably as the git spec that resolves the same content. If a resolution genuinely cannot be verified, the error should name the actual state (a store-cached tarball resolution without integrity), not suggest the lockfile was tampered with.

Environment

Harness	DeepSeek Harness desktop app, @deepseek-ai/dsh-desktop-runtime 0.2.0-rc.2
Bundled pnpm	11.7.0 (Contents/Resources/runtime/pnpm/bin/pnpm.mjs, runtime/versions.json)
System pnpm used for contrast	11.20.0 (Homebrew)
Store	~/Library/pnpm/store/v11
OS	macOS 26 (darwin/arm64)
Profiles	headless (succeeded first), desktop (failed on reuse)

Root cause

pnpm 11.7.0 records a store-side resolution for a remote tarball without the integrity field. A later resolution of the same URL reuses that entry (reused 1 downloaded 0), copies it into the lockfile, and then its own supply-chain verifier refuses the integrity-less entry. Because the entry is in the store, deleting the profile's pnpm-lock.yaml changes nothing, and --force does not drop it either. pnpm 11.20.0 against the identical store re-downloads and records integrity, so this looks version-specific.

Impact

• Breaks the documented third-party distribution channel: dsh-at-file's README installs a …/main.tar.gz URL, and the DSH docs describe dsh plugin --profile <name> add <pnpm args> with git/URL specs in mind. Anyone shipping a plugin as a tarball URL will see their users hit this on the second machine (or the second profile) that shares a store.
• The failure is self-perpetuating: the first successful install poisons the store for every later resolve of that URL.
• It costs real time because the message points at lockfile tampering and at --frozen-lockfile, and both leads are dead ends (CI=1, --no-frozen-lockfile, deleting the lockfile, --force — all tested).

Workarounds

1. Use a git spec instead of a tarball URL — verified working against the same store:

   dsh plugin --profile <name> add github:CancerTiN/dsh-set-session-title

   Worth documenting as the recommended form in plugin READMEs and in the CLI docs.
2. Re-resolve against a clean store (new --store-dir, or prune the store) — correct but not something a user can be asked to do.
3. Hand-supply the integrity field in the profile's lockfile. This is what unblocked the desktop profile here; it works, but no user should need to know it.

Suggested fix

1. Bump the bundled pnpm (11.7.0 → a version whose tarball resolution records integrity; 11.20.0 behaves correctly). Cheapest and fixes the root.
2. If the bundled version must stay, have the plugin manager resolve tarball specs itself and write the integrity into the lockfile before handing off to pnpm — or refuse tarball specs up front with a message that names the limitation and points at the git-spec form.
3. Reword or intercept the surfaced error: ERR_PNPM_MISSING_TARBALL_INTEGRITY on a fresh store-cached resolution is not lockfile corruption.

Note on a hypothesis that was tested and ruled out

An earlier suspicion was the desktop plugin manager's snapshot/repair path (it restores saved profile files and re-runs install --frozen-lockfile on warnings, so a frozen re-install looked like the culprit). The isolated runs above use the bundled pnpm without the manager and fail identically, so the manager only makes the message worse, not the failure. Worth stating so the trail does not get followed twice.