What uninstalling a DSH plugin deletes (sessions, settings)

What does uninstalling a DSH plugin delete? The answer depends on who owns the data: the dependency and load layer are cleared by dsh plugin remove, the plugin's settings card vanishes with its namespace, and your session records are untouched. The real traps are the three things that half-leave — files the plugin wrote itself, config overlay blocks you hand-wrote, and other plugins depending on it. Walk the three-tier ownership table below once and you will know exactly what you are giving up before you uninstall.

What survives and what goes after uninstalling a DSH plugin

Sort the data into three tiers by ownership and the blast radius becomes obvious: the DSH root tier, the profile tier, and the plugin's own tier (source). The comparison:

For the last row: before uninstalling, check whether the plugin's docs or source name a data directory; after uninstalling, look under $DSH_HOME for a directory named after the plugin. If there is one, its data exists independently of the package and usually survives a reinstall; if not, the data was written inside the package directory and is already gone.

References that break with a DSH plugin: commands, shortcuts, widgets

What stops working after uninstalling a DSH plugin is far more than "one less item on the settings page" — everything it registered disappears with it, and anything depending on it may error out. Two categories:

Gone with the plugin (normal, nothing to do):

1. The commands and keyboard shortcuts it registered;
2. The widgets and entries it added to the sidebar, dashboard, or status bar;
3. The tools it provided — the model can no longer call them;
4. Its card on the settings page (the namespace is no longer registered).

Not gone on its own (you must handle these):

1. Lines in cordis.patch.yml referencing that plugin: that overlay is not managed by pnpm or the bundle manifest, and remove will not clear it for you; leaving it behind can throw a module-not-found at startup (source).
2. Other plugins depending on it: if another plugin still depends on it, pnpm may refuse the removal, or leave an upper plugin referencing a missing package — the former errors immediately, the latter only surfaces at startup. See what to do when uninstall fails.
3. Leftover config in the profile: data the plugin wrote that fits neither category above — verify it tier by tier with cleaning up leftovers after uninstall.

Reinstalling from DSH Plugin Hub to recover from a mistake

The first step of recovery is not reinstalling but judging which tier you lost: a lost manifest layer can be rebuilt, data lost inside a package cannot be recovered. Do it in order:

1. Confirm the blast radius: run dsh plugin --profile <name> list and dsh --profile <name> --dump-config to see which layer is missing, then ls "$DSH_HOME" for a data directory named after the plugin.
2. Reinstall the same version: open Settings → Plugin Marketplace, i.e. DSH Plugin Hub, and reinstall from the installed plugins list (or rerun the original install command). Reinstalling rebuilds the dependency and load layer, and the settings card and tools come back with it.
3. Restore your overlay block: if you had hand-written a config: block in cordis.patch.yml, a reinstall will not bring it back — rewrite it from your backup.
4. Verify: restart dsh, confirm the card, tools, and commands are back, then run --dump-config once more to check the layer order.

Whether data can be recovered is half-decided at step 1: data living in its own directory under $DSH_HOME is usually readable again after a reinstall; data written inside the package directory is already deleted with the package. So the genuinely safe move is to back up before uninstalling — at minimum copy the profile's package.json and cordis.patch.yml, and if you can, back up the whole $DSH_HOME; see how to reset dsh.

DSH plugin uninstall impact notes

In one line: remove only handles the manifest and the load layer — everything else is either unaffected or yours to finish.

1. Sessions are not carried away by a plugin uninstall: they live in $DSH_HOME/sessions; clearing sessions is a separate job, see how to delete a session.
2. A vanished settings card does not mean deleted config: the namespace goes with the plugin, but the config: block you hand-wrote stays in cordis.patch.yml.
3. Back up both manifests before uninstalling: package.json and cordis.patch.yml, so you can restore everything if something goes wrong.
4. Check first whether another plugin depends on it: when dependencies exist, remove the upper plugin first, or pnpm will refuse the removal.
5. Do not count on a reinstall to recover in-package data: the data location is decided by the plugin author — confirm it before uninstalling.
6. If you only want to pause it, do not uninstall: disabling keeps all data and config; the difference is in disabling a plugin vs uninstalling it.
7. Confirm profile paths per platform: default $DSH_HOME locations per platform are in where the DSH config file lives.

Sources: dsh CLI README, DeepSeek Harness docs - Packaging and installing a plugin, DSH Plugin Hub.