Remove DSH plugin leftovers: DeepSeek Harness Cleanup Guide

After uninstalling a DSH plugin, leftovers sit in two places: the profile directory's dependency declarations and config overrides, and the pnpm store's package files. Clean them with three steps: inspect, clean the profile, clean the cache.

Overview

dsh plugin remove only drops a plugin from the dependencies — it does not guarantee removing every trace. To clean up thoroughly, you need to know where the leftovers are, how to remove each layer, and where the data directory lives on your platform. Back up your session data before deleting anything. This article goes in order — what stays behind, how to clean it, and where the data directory is — with concrete commands and fallbacks for each layer so you don't touch other plugins' data by mistake.

What remains after uninstalling a DSH plugin

Three kinds of leftovers: dependencies, config overrides, and package caches. Concretely:

1. Dependency declarations: dsh plugin --profile web remove <package> forwards to pnpm to remove the dependency (source), but packages depended on by other plugins stay — that is expected, since removing them would break plugins still in use.
2. Config overrides: config lines you wrote for the plugin in the profile's cordis.patch.yml or the home-level ~/.dsh/cordis.patch.yml are not removed on uninstall and can linger. This is the usual reason "it still behaves as if installed": the config is still there, and the framework keeps reading it.
3. Package cache: the pnpm store keeps downloaded package files; pnpm manages it, so manual cleanup is rarely needed. Because pnpm's node_modules is a symlink structure, remove only drops the plugin from the dependency tree while the physical files stay in the global store — "uninstalled but the data is still there" is by design, not a bug.

Back up before touching anything — one command is enough: cp -r ~/.dsh ~/.dsh.bak (on Windows: xcopy /E /I %USERPROFILE%\.dsh %USERPROFILE%\.dsh.bak). Back up the whole ~/.dsh data directory rather than a single profile — it covers dependency declarations, config overrides, and session records at once, and you can copy the whole directory back if a cleanup goes wrong.

Plugins installed from DSH Plugin Hub leave the same traces; its visual uninstall takes effect immediately and every install/upgrade/uninstall is logged in the notification center for later reference.

How to clean DSH plugin config leftovers and caches

Clean in two passes: inspect first, then handle config and cache separately. The order:

1. Inspect: dsh plugin --profile web why <package> shows dependencies; dsh --dump-config shows whether the plugin's rows remain in the merged config tree (source).
2. Clean the profile: edit the profile's package.json to drop leftover dependency lines and cordis.patch.yml to remove the plugin's config lines; back up before editing. Note that package.json holds dependency declarations while cordis.patch.yml holds config overrides — check both, not just one.
3. Clean the cache: for a source-built DSH, run pnpm store prune to remove packages nothing depends on.
4. Fallback: to discard a whole profile, delete its directory (e.g. ~/.dsh/profiles/web); DSH rebuilds the built-in web and headless profiles on next launch (source).

After cleaning, rerun step 1 to confirm: why reports nothing for that plugin and --dump-config has no row for it — only then is the cleanup truly complete. Before editing package.json, run pnpm list to confirm the exact package name and version so you do not delete the wrong line; after editing, no reinstall is needed — the profile loads the new declarations on the next launch.

Once you delete a whole profile directory, the next dsh web launch rebuilds a fresh web profile — third-party plugins you installed need to be reinstalled and runtime settings like models return to defaults. So "delete the whole directory" suits a fresh-start situation; to remove just one plugin, prefer the targeted edits to package.json and cordis.patch.yml so the other plugins do not go down with it.

DeepSeek Harness data directory locations and a full cleanup

The DSH data directory follows the $DSH_HOME environment variable, defaulting to ~/.dsh. Default locations per platform:

• macOS: /Users/<username>/.dsh
• Linux: /home/<username>/.dsh
• Windows: %USERPROFILE%\.dsh

To check the actual path on your machine, run echo $DSH_HOME (or echo %DSH_HOME% on Windows): if it prints something, use that path; if empty, it is the default ~/.dsh.

Inside ~/.dsh you will typically find profiles/ (per-profile plugin dependencies and configs), sessions/ (per-project conversation records), and cache/log files. When you clean up after an uninstall, only profiles/web matters for the plugin's leftovers; touching sessions/ is only needed when you uninstall DSH entirely. Knowing this layout helps you avoid deleting the wrong directory while chasing a leftover plugin.

On Windows, if %DSH_HOME% is not set, the default directory is %USERPROFILE%\.dsh — it is not under AppData, so do not look in %APPDATA%. The path includes your username, so it changes when you move to another machine or user account; be careful about hard-coding it in scripts.

For a full uninstall of the DSH core, the key is clearing this directory: with npx, deleting ~/.dsh is enough; with a source build, also remove the cloned deepseek-harness repo and run pnpm store prune (source). Before deleting, remember: ~/.dsh holds both profile configs and all session records — back up ~/.dsh/sessions first. Once the directory is gone it is really gone: sessions, history, and plugin configs all live inside it, and there is no trash can to recover from.

Source: dsh CLI README, official Quickstart