Uninstall order: DeepSeek Harness vs dsh plugins

Uninstalling DeepSeek Harness is less about the order of commands than about how deep you intend to cut. A DSH plugin removal that keeps your profile tells a different story from a full wipe, and mixing the two produces leftovers that reappear after reinstall.

A DeepSeek Harness plugin uninstall starts with a depth decision

Decide what should survive before deciding what to remove, because depth determines order, not the other way around.

People ask whether plugins should go before the core. The question sounds procedural, but it is really about the target state. If you plan to reinstall and keep your configuration, plugins and profiles are assets. If you plan to start clean, they are residue.

Depth one is the plugin layer: remove or reset just the plugins. Depth two is the profile layer: keep the core, but replace the configuration set that decides what loads. Depth three is the core layer: remove the runtime itself. Depth four is the residue layer: decide what to do with caches, data directories and build artifacts.

Choosing a depth first makes the command sequence obvious. It also prevents the most common mistake, which is removing the core to solve a plugin problem. That single decision removes most of the ambiguity from the commands that follow.

The sections below walk down through the layers and name what each one keeps. Read them in order; the right stopping point is usually higher than people expect. If a layer seems irrelevant, that is usually a sign you have not needed it yet.

Depth one: the DSH plugin layer

The shallowest removal touches only DSH plugins and leaves the core, the profile and the data directory intact.

This is the right depth when one plugin misbehaves, conflicts with another, or needs a clean reinstall. Remove it through the plugin command rather than deleting its directory, so the host updates its manifest and state. The command also keeps the profile aware of what changed.

Write down the package name and version before removing anything. The installed list is the only reliable inventory you will have afterward, and it disappears with the plugin. A screenshot is enough if you also note the profile it came from.

After removal, restart and confirm the plugin is gone from the list. If it reappears, you removed files but not the registration. Check the profile before removing anything else.

This depth is reversible. Reinstalling the same package at the same version should restore the previous behavior, assuming the configuration still exists. If the previous configuration was deleted, reinstall the package and rebuild the settings from the manifest.

Depth two: the DeepSeek Harness profile layer

A profile reset clears plugin state without removing the core, which makes it the cheapest way to answer whether the problem is the plugin or your configuration.

A profile decides which plugins load and with which parameters. Creating a clean profile with only the minimum plugins isolates configuration problems from package problems. If the clean profile works, the package was fine.

Keep the old profile until you are confident. Copy it rather than editing it in place, and give it a name you will recognize a week later. Name it with the date and the reason, not with a vague label like test.

This depth does not touch the core binary or the data directory. Sessions and credentials usually survive, which is exactly why people reach for it first. That survival is also why a profile reset is a poor substitute for a real cleanup.

The failure mode here is treating a profile reset as an uninstall. It is not; the core is still installed and will still load whichever profile is active. Name the reset in your notes so the distinction survives the next handover.

Depth three: the DeepSeek Harness core layer

Removing the core is a runtime decision, so do it only when the runtime itself is the problem or the machine is being retired.

The core can be installed through npx, a global npm package, or a source checkout, and each method has its own removal step. Using the wrong one leaves the old command on PATH and creates the illusion that the uninstall failed. Match the removal to the installation method before running anything.

Before removing the core, export the plugin manifest and back up the data directory. The uninstall will not delete your configuration, but a later cleanup might. Keeping the backup outside the machine is the safer choice.

After removal, check that the command no longer resolves. A remaining binary in a different prefix is a residue problem, not a failed uninstall. A stale symlink is the most common culprit.

This depth removes the runtime and nothing else. Profiles, sessions and plugin data typically remain, which is either convenient or messy depending on the next step. Decide in advance which of those you want to keep.

Depth four: the DSH plugins residue layer

Residue is anything the uninstall left behind, and it is the layer most likely to make a clean reinstall look dirty.

Residue lives in at least three places: the command path, the package manager cache, and the data directory that holds configuration, sessions and plugin state. Build artifacts from native modules can survive too. Each location has a different safe way to inspect it.

None of these should be cleared blindly. The data directory may contain work you cannot recreate; the cache may be the only copy of an old version you need for rollback. Inspect before you delete, and delete only what you can name.

Clean one location at a time and verify after each. A full sweep makes it impossible to tell which leftover caused the next symptom. Verify by listing the location before and after, not by trusting the cleanup command.

A reinstall is the test. Install the core, restore plugins from the manifest, and compare the result with what you recorded before removal. If the comparison fails, the residue layer is not finished.

Verifying a DeepSeek Harness plugin reinstall at the chosen depth

A reinstall is only clean relative to the depth you chose, so verify against that depth rather than against a generic checklist.

If you chose the plugin layer, success means the plugin list matches the manifest and the rest of the system is unchanged. If you chose the profile layer, success means the new profile loads the expected plugins and old sessions still open. Each depth has its own definition, and mixing them creates false failures.

If you chose the core layer, success means the command resolves to the new install and the data directory is the one you expected. If you chose the residue layer, success means nothing from the old install reappears. A clean command with an unexpected data directory is still a failed reinstall.

1. Confirm the command resolves to the intended install path.
2. Compare the plugin list with the saved manifest, line by line.
3. Open an old session and check that it still reads.
4. Run one real operation per restored plugin.
5. Inspect the data directory for unexpected duplicates.
6. Check the package cache for the old version you meant to remove.
7. Write the depth and the result into your notes.

The comparison is the part people skip. A reinstall that produces the right version but the wrong plugin list is not clean; it is a different installation with the same name. A version match with a missing plugin is still an incomplete reinstall.

That is why the depth decision comes first. Once you know what was supposed to survive, the order, the commands and the verification all follow, and the DSH Plugin Hub entry is only needed to confirm package names and versions. Without that decision, every cleanup looks equally correct.