Stuck DeepSeek Harness desktop uninstall: DSH plugin locks

A stuck DeepSeek Harness desktop uninstall or reset is almost never a broken uninstaller; it is a lock problem. The desktop must first take two locks: Electron's process lifecycle single-instance lock, and the package transaction's profiles/desktop/lock. While a Host, Node or pnpm process still holds either one, the uninstall waits at the last step.

This guide walks through four steps: why it hangs, who holds the lock, how to locate a locked file, and how to stop safely. The normal uninstall scope and command registration are covered in How to uninstall DeepSeek Harness desktop; this article only deals with an uninstall that stalls or fails along the way.

Why a DeepSeek Harness desktop uninstall hangs: the single-instance lock on profiles/desktop

The official docs state the desktop acquires a process lifecycle single-instance lock before touching any profile and exclusively holds $DSH_HOME/profiles/desktop plus its package manager state. So as long as a desktop or Host process is alive, a new uninstall or reset is blocked outside that profile, appearing as "nothing happens" or a long stall (source).

Run these four checks to see who is still alive before retrying:

1. Check desktop and Host processes — On macOS / Linux run ps aux | grep -i deepseek-harness; on Windows run tasklist | findstr /i "DeepSeek node". Expected: leftover desktop, Host or Node processes show up, or none remain.
2. Check who holds the profile directory — On macOS / Linux use lsof +D "$DSH_HOME/profiles/desktop"; on Windows search the directory name under associated handles in Resource Monitor. Expected: the process holding the directory appears, which is what blocks the uninstall.
3. Fully quit the desktop from the tray — Closing the window is not quitting; use the tray or menu bar to quit. Expected: the process from the previous step disappears and the single-instance lock is released.
4. Retry the uninstall or reset — Act only after all processes exit. Expected: it no longer stalls at the first step and reaches the package transaction stage.

Step 3 is the most commonly missed: closing the window only hides the app, the single-instance lock stays, and the uninstall waits outside the door. The action that releases the lock is quitting the app, not closing the window.

profiles/desktop/lock: while pnpm runs, the uninstall waits

The package transaction exclusively holds $DSH_HOME/profiles/desktop/lock until the pnpm process exits, and a reset keeps that directory and lock until initialization and Host startup complete. So a stall at the last step usually means the transaction is not finished, not that the progress bar is dead (source).

Use these three commands to tell "still working" from "truly stuck":

1. Check whether the lock file still exists — On macOS / Linux run ls -la "$DSH_HOME/profiles/desktop/lock"; on Windows run dir "%DSH_HOME%\profiles\desktop\lock". Expected: a present lock file means the transaction is unfinished; a missing file means the lock is released and the stall has another cause.
2. Check whether pnpm / Node is still running — On macOS / Linux run ps aux | grep -E "pnpm|node"; on Windows run tasklist | findstr /i "pnpm node". Expected: running processes mean the transaction is active and a slow network makes the uninstall wait; no process with the lock still present means a real stall.
3. Confirm no second dsh process grabs the same profile — The desktop and the CLI may act at once. Expected: only one process should hold that profile; concurrent operations wait on each other's locks and look like an unresponsive uninstall.

Step 2 requires telling two kinds of stalls apart: a patient wait caused by a slow network (pnpm is still fetching packages or writing the store, the process runs with CPU activity) and a mutual wait caused by lock contention (the process runs but shows no IO for a long time). Wait for the first; find the lock-grabbing process for the second. Two common mistakes here:

• Mistake 1: kill the process the moment the bar stops moving — this leaves a half-written store state.
• Mistake 2: delete the whole profiles/desktop directory — the official docs state a failed plugin change keeps partial modifications and does not roll back, so a hard delete of a transaction directory only makes the state harder to recover.

DeepSeek Harness desktop uninstall stuck: locating a locked file you cannot delete or replace

The most common conflict in a desktop uninstall or reset is a file in use that cannot be replaced. The official Windows packaging and smoke validation covers exactly this with "two file-in-use replacement approaches": locate the holder first, then decide whether to end the process or wait for it to exit, and touch files last (source).

Follow the safe order of "check the log first, find the holder, end the process, then touch files":

1. Watch progress in the UI first — Open the DSH Plugin Hub notification center and check whether the uninstall or update task is "in progress" or "restart pending". Expected: an in-progress task means keep waiting; a restart-pending task means the process must exit to finish.
2. Find the holder with system tools — On Windows use Task Manager details or Resource Monitor and search handles by directory name; on macOS / Linux use lsof +D <dir>. Expected: the process actually holding the handle is listed, usually the Host, Node, pnpm, or an editor / file preview.
3. End the holding process — On Windows run taskkill /F /PID <pid>; on macOS / Linux run kill <pid>, or quit normally when possible. Expected: the handle is released and the lock clears.
4. Only then delete / replace files — After the handle is released, let the uninstall continue or clean the directory manually. Expected: deletion no longer reports "file in use" or "locked".

Why step 1 comes first: the worst thing to do when stuck is to click uninstall repeatedly, which stacks concurrent requests and worsens lock contention. Confirm the current task state in the notification center before deciding to wait or intervene.

Notes on a stuck DeepSeek Harness desktop uninstall

1. Closing the window is not quitting: the single-instance lock releases only when the process truly exits, so quit the desktop from the tray or menu bar before uninstalling.
2. A reset also holds the lock: the reset keeps the profiles/desktop directory and lock until initialization and Host startup complete, so do not touch that directory during a reset either.
3. Failures do not roll back: the official docs state a failed plugin change keeps partial modifications and does not roll back, so a hard delete of a busy directory makes recovery harder.
4. Diagnose before retrying: cross-check the lock file, the pnpm / Node process, and directory handles; do not treat a slow network as a true deadlock.
5. Do not mix up the scope: an uninstall only touches the app and executable layer; sessions, settings, credentials and plugins in ~/.dsh remain. See How to uninstall DeepSeek Harness desktop for the uninstall vs reset difference.

A stuck uninstall is often just an unfinished task in the UI. When you reinstall or restore DSH plugins, use the DSH Plugin Hub for less friction: it is the official plugin market with an uninstall confirmation dialog, and uninstall and reinstall progress both show in the notification center so you never guess which step stalled.

Sources: DeepSeek Harness desktop README (official repository), DeepSeek Harness source repository, dshplugin/dsh-plugin-hub