Skip to content
dshdocs

dsh Plugin Remove Bug — DeepSeek Harness Guide

Symptom

Section titled “Symptom”

dsh plugin --profile <X> remove <bundle> sometimes leaves a stale entry in dsh.profile.bundles, in the profile’s package.json, after the package itself is already gone from dependencies. The profile then refuses to boot:

dsh: cannot resolve profile bundle "<bundle>" from the dsh installation or <path>;
run dsh plugin --profile X install if its dependency is not installed

The message’s own advice doesn’t help. Neither dsh plugin --profile X install nor dsh plugin --profile X ls clears the stale entry. As of the reports below, hand-editing package.json is the only recovery.

Cause

Section titled “Cause”

Two reporters root-caused this against 0.1.0-rc.6 source, down to line numbers (#913, with a deeper follow-up in #917):

  1. reconcilePlugins() syncs dsh.profile.bundles against pnpm’s real dependencies, and it runs only when the pnpm subprocess exits 0. If pnpm writes the manifest and then exits non-zero (reporters saw this with transient network errors during remove, e.g. ETIMEDOUT against a git-hosted bundle source), the dependency is gone from package.json but reconcile never ran to strip the matching dsh.profile.bundles entry.
  2. From there the stale entry is permanent. The removal branch fires only when wasDependency is true, meaning the package showed up in dependencies either before or after the pnpm run. With the package gone on both sides, wasDependency is false forever and the branch never fires again. That holds for every later dsh plugin call, install and ls included, since they all funnel through the same reconcilePlugins().
  3. The fix the error message suggests, dsh plugin --profile X install, runs that same logic, so it can’t repair this class of stale entry. The message points you at a dead end.
  4. The same reports note a related symptom. On a brand-new profile, the first dsh plugin add can also fail to populate dsh.profile.bundles, for the same reason: reconcile skipped on a non-zero pnpm exit. A second add backfills it.

The repro is non-deterministic and network-dependent. One reporter got 4/4 passes rerunning the same flow under controlled conditions, which points at a race with pnpm’s exit behavior rather than a reliable trigger.

Solution

Section titled “Solution”

As of these reports, the only confirmed recovery is manual:

  1. Open the profile’s package.json (under $DSH_HOME/profiles/<name>/).
  2. Find the stale bundle name under dsh.profile.bundles.
  3. Delete that entry by hand and save.
  4. Boot the profile again.

Bundles installed with link: were reported to remove cleanly, since no network operation is involved. The bug needs a removal that makes a network round trip, e.g. a github:owner/repo source.

Source

Section titled “Source”
Section titled “Related errors”