Where DSH plugins end: market install vs package manager

You click Install in the market, wait for the bar to fill, then hunt through Settings for something that is not there; later you click Uninstall and the same card is still sitting in the catalog. Neither experience is usually a broken install or a failed removal — they are what happens when one interface blends a catalog with a machine's package state, a distinction the DSH Plugin Hub makes easy to miss. The useful question is not which button to press next, but which of the two records you are actually looking at.

The missing entry: two records behind every DSH plugin

A plugin with no visible panel has usually registered something other than a panel.

The market card tells you that an entry is associated with the current profile; it says nothing about what the package added. Some plugins contribute a command you can invoke and never touch the sidebar. Others mount a settings group only after a reload, so the page you are staring at predates the install. Reading the plugin's own description is faster than clicking through every menu.

A profile mismatch produces the same silence. The web interface reads one profile, while a terminal command may write to another, and nothing warns you about the split. The plugin is genuinely installed, just not into the profile the browser is rendering. Confirm the profile on both sides before you reinstall anything.

Grouping in the installed view adds a third false negative. Disabled plugins can sit under a collapsed section, and a search term that matches the catalog may not match the list labels. Switch the filter to show everything before concluding that the package vanished.

The useful habit is to ask what shape of entry the plugin promised. Some add a command palette action, some add a settings group, and some run entirely in the background with nothing to open. Knowing which one you installed turns a scavenger hunt into a single check.

What the market controls, and what the package manager does for a DSH plugin

The market is an index with buttons; the package manager is the thing that writes to disk.

Catalog entries carry names, versions, publishers and compatibility ranges, which is exactly what you need before committing. The market turns a click into an add or remove invocation and streams the output back. It can keep listing a package forever, because a catalog describes what could be installed rather than what is installed. For a DeepSeek Harness plugin, that entry may also pin a supported Harness range.

Everything after the trigger belongs to the package manager: resolving the dependency graph, fetching archives, updating the profile manifest, and deleting directories on removal. It has no idea which surface asked it to work. A graphical button and a typed command are the same request dressed differently.

Once you hold those two roles apart, the confusing cases collapse. A card in the market is not proof of a local install. A command-line install is not visible in the interface until something refreshes. Catalog state and install state drift independently, and most ghost reports are just that drift.

The catalog also answers a different question than the manifest. It tells you whether a package exists, who publishes it, and which versions are offered. The manifest tells you what this machine will load the next time it starts. Mixing the two answers is how people install something twice.

Checking both sides: market state and dsh plugin list

Trust the package manager for facts and the interface for presentation, then reconcile them.

A rendered list reflects whatever the front end last fetched, while a command reads the profile directly. When they disagree, start with the command and work backward to explain the stale view. Cache, an unrefreshed page, or the wrong profile will cover nearly every case.

1. Open Settings → Plugin Market → Installed and confirm the package is listed, not merely present in the catalog.
2. Run dsh plugin --profile web list and compare the package name and version.
3. Invoke a command the plugin provides, if it provides one, to prove it resolves.
4. Reload the page or restart dsh web and check whether the entry mounts.

The smallest command-side check is three lines:

dsh plugin --profile web add <package>
dsh plugin --profile web remove <package>
dsh plugin --profile web list

If the package is absent from the list, do not blame the Uninstall button yet. Check the profile in your command and the spelling of the package name first. Only after both are ruled out does the problem belong to the package manager.

If the package is listed but the interface shows nothing, resist installing it again. Look for a required restart, a disabled state, or an entry registered on a page you have not opened. A second install only adds a redundant line to the manifest.

A package that appears in the list but in a surprising version is worth a second look before you touch anything. It may have been installed by a different command or pulled in as a dependency. The manifest is the authority on what is present, not on why it is present.

What uninstalling a DSH plugin actually removes

Removal takes back the dependency and the package directory, not the traces they wrote elsewhere.

The uninstall path calls remove, which drops the entry from the profile manifest and clears the package folder. That part is usually clean and rarely fails. Everything outside the folder — configuration, credentials, sessions, caches — is outside the package manager's contract.

Files under $DSH_HOME are the ones people most often expect to disappear with the plugin. They are keyed by plugin or namespace and survive removal so that a reinstall can pick them up. Sessions and logs follow the same logic: deleting them would erase history, a decision no uninstall button should make for you.

The residue that actually occupies space tends to be caches and indexes: a package cache, thumbnails and search data kept by the market, temporary folders a plugin created. None of it changes behavior. If you want it gone, delete it by path; the uninstall flow will not do it for you.

Some leftover is purely visual. A card that will not disappear, a counter that does not decrement, a greyed-out entry — these are front-end state that has not caught up. Restart dsh web and look again. Only if the ghost survives a restart should you go back to the profile and the package directory.

When a DSH plugin uninstall leaves real residue

Most residue is harmless, but a few leftovers make the next install behave strangely.

File-level conflicts come first. A new version writes over paths an older one left behind, and the loader can end up reading a blend of both. Removing before adding is safer than installing on top. If removal itself fails, the dialog usually names the path that is still in use.

Shared runtimes cause the second kind of trouble. Two DSH plugins may depend on one native module or background service, and removing either can take the shared piece with it. The symptom appears in the plugin you kept: a sudden missing-module error. Reinstalling the removed package generally restores it.

Stale configuration creates a subtler failure. The plugin is gone but its settings remain, so a fresh install inherits the old behavior and looks like it ignored the upgrade. Check the version and where the configuration came from before deciding to wipe anything.

A practical test is whether the leftover participates in loading. Caches that only consume disk can stay; old files that still resolve modules must go. When you cannot tell the difference, back up the configuration and do one clean reinstall as a controlled comparison.

Keeping the boundary straight: DeepSeek Harness plugin installs are reversible

The market shows and triggers, the package manager performs, and residue lives where neither one looks.

Before installing, read the confirmation dialog closely enough to know the package name and its source. After installing, verify with a command, then refresh the interface and look for the entry. Reversing that order is how people end up reinstalling something that was already there.

Before uninstalling, decide how much you want to erase. Making the plugin stop running needs only remove; erasing its settings is a manual cleanup with different consequences. Treating those goals as one action is what creates the feeling that uninstalling did nothing.

A short diagnostic order settles most disputes: interface absent and command present means stale state; command absent and interface present means stale rendering; both absent while the directory remains means genuine residue. Keep that order in mind and DSH plugins stop feeling mysterious, whether they arrive from a market card or a terminal.

The point of the boundary is not bureaucracy. It tells you where to look when the two views disagree, and it keeps a reversible operation reversible. Once the catalog and the manifest are separate in your head, neither a missing entry nor a lingering card is alarming.