DSH plugin uninstall failed? Force clean DeepSeek Harness

When a DSH plugin uninstall fails, read the dsh plugin remove error to locate the cause, then fall back through "command uninstall → manual cleanup → restart to verify".

Overview

Uninstall failures are usually package or dependency problems, not typos in the command. The approach takes three steps: read the error, clean manually, restart and verify. DSH is still in developer preview and the file layout may change — check the official docs before touching files (source). This article breaks down the three common errors, gives the manual cleanup steps for each, and ends with a verification checklist — go in order, don't delete the whole directory first. Find out whether the package is broken or the dependency chain is tangled before acting. Also keep in mind that the root of an uninstall failure is often at install time — a git-distributed package missing build output, for example, is better fixed by switching install source than by fighting the uninstall command.

Common dsh plugin remove uninstall errors

The remove command itself is simple; failures usually come from the package or the dependency state. The command format:

dsh plugin --profile web remove <package-name>

Three common failures (source):

1. Broken package: a git-distributed plugin that does not commit its build output makes pnpm fail to resolve the entry file during removal.
2. Dependency conflict: the plugin is depended on by other plugins, so pnpm refuses to remove it and reports a dependency error.
3. Abnormal profile state: the profile's package.json was manually edited or corrupted, so remove fails immediately.

To tell which type you hit: ERR_MODULE_NOT_FOUND / entry file in the error means a broken package; depends on / peer means a dependency conflict; JSON / parse means an abnormal profile state. The more precisely you locate the error, the less manual cleanup you will need. If you are unsure, run dsh plugin --profile web why <package> first to see the dependency chain — its output tells you directly who depends on this plugin, so you know where to start.

Match your error to the right path: ERR_MODULE_NOT_FOUND ... plugin-a/lib/index.js means plugin-a's package structure is incomplete — usually a git distribution that did not commit build output, so the fix is changing the install source, not repairing the command; Cannot remove plugin-b: plugin-c depends on it means plugin-c still references it, so handle plugin-c first or remove both together; Unexpected token in package.json means the profile file was edited by hand and corrupted — back up and fix the format. The three paths are entirely different: a package problem is fixed by reinstalling from another source, a dependency problem by changing the dependency graph, and a file problem by repairing the file itself.

Manual fallback: delete DSH plugin dependencies and bundles

If the command cannot remove it, clean manually: back up first, then delete the dependency declarations and overlay lines, and finally delete the whole profile as a fallback.

1. Back up: copy ~/.dsh/profiles/web to keep a safety net before touching anything.
2. Delete dependencies: edit the profile's package.json and remove the plugin's dependencies line.
3. Delete overlays: edit cordis.patch.yml to remove the plugin's config lines; also delete the corresponding line from the profile's bundle list (dsh.profile → bundles). Both spots must go together: deleting only the dependency leaves old config read on the next launch; deleting only the config lets the plugin get installed again.
4. Fallback: if you cannot remove it and no longer need it, delete the whole ~/.dsh/profiles/web directory — the built-in web and headless profiles are rebuilt automatically on next launch (source).

Manual editing is plain-text work — a text editor or a node -e script both work; after editing, no install command is needed, since the profile loads the new declarations when dsh web restarts. What exactly to edit: delete the line "@scope/plugin-a": "^1.2.0" from dependencies in package.json, remove the config: block headed by the plugin name in cordis.patch.yml, and drop the package name from the bundles list in dsh.profile. Run pnpm list first to confirm the exact name — a single wrong character in a scoped package name and you are removing a different plugin.

If a plugin installed from DSH Plugin Hub fails to uninstall, the issue is usually the package itself — its detail page shows the source (npm or GitHub), and switching to the npm version avoids the missing-build-output problem of git distribution. Failed uninstalls in the Hub are also logged in the notification center for later review. The difference between npm and GitHub sources is also covered in the plugin-publishing article.

Verify the DSH plugin uninstall succeeded after cleanup

Restart dsh web after deleting, then confirm the plugin's capabilities are gone and the config tree is clean. The verification triple:

1. Restart dsh web; UI plugins no longer change the interface, tool plugins no longer appear in the tool list.
2. Run dsh --dump-config and confirm the merged config tree has no rows for the plugin.
3. Run dsh plugin --profile web why <package> and confirm the dependency is removed (source).

If other plugins misbehave after cleanup, they likely depend on the removed plugin — check the dependency chain with why before deciding; don't delete anything until you see who depends on whom. For the full uninstall flow, see How to uninstall DSH plugin. Once verification passes, delete the backed-up profile directory so stale data does not confuse the next diagnosis.

Source: dsh CLI README, official Quickstart