dsh-purge DSH plugin setup: Apply, Restore, profiles

The dsh-purge DSH plugin looks finished the moment its panel appears beside a session, which is exactly the wrong moment to trust it. It is a community red-team evaluation plugin, and its work begins when policy is written into the host rather than when files land in a profile. I stopped clicking around and started treating it as four states that move in one direction.

Installed is not active: the first dsh-purge DSH plugin state

Installing dsh-purge only makes the panel visible, and the host policy has not moved yet.

The install itself is ordinary: search the package in DSH Plugin Hub, confirm the author and version, and install into the intended profile. Several authors publish under the same name, so the version and the entry matter more than the label in the panel. Once installed, the dock appears beside the session title and the plugin shows up in the profile's plugin list. None of that changes how the host treats a prompt.

Installed means files are present and the panel can describe what it would do. The Clean page may already show a patch status, but the status describes the package, not the running host. DSH plugins are installed per profile, so a package present in the web profile says nothing about the desktop profile. I confirm this state with dsh plugin list and by checking which profile the panel is reading.

The useful habit is to name the state before touching a button. Installed is a file-system fact, and it is the only state that installation alone can produce. Everything after that is a deliberate transition with a restart and a new session attached.

Applied is a host change made by the DeepSeek Harness plugin

Apply is the transition that writes policy into the host and restarts it, and it must finish without interruption.

Apply lives on the Clean page, and it is the only button that moves the plugin from installed to applied. The plugin writes its rules into the host and triggers a restart as part of the operation. Restarting in the middle of an apply is how people create a half-written state that the panel cannot describe. I wait for the restart to complete before opening anything else.

The apply log is worth keeping, because it records what was written and whether the host accepted it. A successful log is evidence of the transition, not evidence of the outcome. The panel can report applied while the user still sees default behavior, and that gap is the next state to investigate. This is also where the web and desktop split becomes real: each profile applies separately.

An applied plugin is a claim about the host, and claims need a test. The test cannot run in the session that was open before the restart, because that session was built under the old policy. A new conversation is the smallest unit that can demonstrate the change. Without that new conversation, applied and effective look identical in the UI.

Effective is behavior you can observe in a new DeepSeek Harness session

Effective is the only state a user can feel, and a fresh session is the instrument that measures it.

I define the check before applying anything, so the comparison is not invented afterward. Pick one prompt whose response should change when the policy is active, and record the answer under default conditions. After the restart, open a new session and run the same prompt unchanged. A difference in behavior, combined with an applied state in Clean, is what effective means.

1. Record the default answer to one fixed prompt.
2. Install dsh-purge into the correct profile.
3. Run Apply from the Clean page and let the restart finish.
4. Open a brand-new session rather than reusing an old one.
5. Run the same prompt and compare the answer.
6. Confirm the Clean page still reports applied after the comparison.

When applied does not become effective, the cause is usually local rather than mysterious. The plugin may be installed in the other profile, the session may be older than the restart, or the package may not support this harness version. Checking those three in order is faster than reinstalling. The state table already told you which transition is missing, so the diagnosis is a matter of finding where it stopped.

Pending re-apply is the state after npm moves DSH plugin files

An npm upgrade can replace the patched files and push the plugin back to pending re-apply.

Package managers own node_modules, and an upgrade rewrites it without asking what a plugin changed inside. The dsh-purge package is designed to notice this on startup and re-apply its patch automatically. Automatic recovery is convenient, but it is still a transition that deserves verification. If the state does not recover, the Clean page should show a pending state instead of a silent default.

A pending state is easy to miss because the panel still looks installed. The behavior returns to default, which can look like a model change rather than a patch loss. I record the package version before and after every upgrade, then run the same fixed prompt again. If the answer matches the old default, the patch needs Apply rather than a new investigation.

Hand-editing the patched files is the one repair that makes the next upgrade worse. It breaks path detection and confuses the self-check that would otherwise recover the state. The supported path is to let the plugin re-apply, then use Apply again if the panel still reports pending. A re-apply after an upgrade is normal maintenance, not a sign that the plugin failed.

Restore moves the DeepSeek Harness plugin back to defaults

Restore is the mirror image of Apply, and it is the only rollback that keeps the self-check intact.

Restore returns host policies to the official copy, then restarts the host. A new session is required for the same reason as before: old conversations were built under the patched policy. I verify the rollback with the same fixed prompt I used to verify the apply. A matching default answer, plus a Clean page that reports the default state, closes the loop.

Deleting files by hand looks faster and breaks the mechanism that makes the plugin recoverable. The plugin no longer knows which copy is official, and the next upgrade can leave a partial state behind. Restore is also the honest way to compare behavior, because it changes one variable at a time. The panel, the restart and the new session form a repeatable procedure.

State thinking is what keeps this plugin predictable. Installed, applied, effective and pending re-apply are different facts, and each one has its own evidence. Moving between them deliberately beats clicking buttons until something looks different.