dsh purge install: first run, rules and verification

Installing dsh purge is not "install and use": put it in the profile, run Apply, restart, and verify state. The name causes confusion; it is not a cache-cleaning tool.

Clarify first: dsh-purge is not a cleaner

dsh-purge is a red-team assessment plugin, not a cache cleaner or uninstaller. It separates model refusal from host-level interception and provides a panel, rules, and rollback (source).

The word purge refers to policy-level handling, not deleting files. If you are looking for cache cleanup, this is the wrong plugin; uninstall and cleanup are different tasks.

Purpose determines installation. Assessment plugins write host policy, so they must go into the profile you actually use and must run Apply; ordinary plugins only need a restart.

Choose a version: source first, then variants

Several same-name or near-name versions exist, such as dsh-purge, dsh-purge-flash, and dsh-purge-community. Similar names do not mean similar behavior.

1. Check owner and repository. Same-name plugins from different authors differ in implementation and maintenance.
2. Read the plugin description. It states the scenario, profile requirements, and risk boundaries; skip plugins without one.
3. Check the last update. A long-dormant version may not support the current core.
4. Do not infer from the name. flash is not necessarily faster, and community is not necessarily more complete.

Pick one and do not install several. Several plugins writing policy at once create override-order problems that are hard to diagnose.

Record the version. Write down package name and version before installing; rollback and comparison depend on it.

Three install steps: profile first

The install action is one command; the hard part is the target.

1. Confirm the profile: web for the web UI, the desktop profile for the desktop app; dsh plugin --profile web list shows the current state.
2. Install: use the Hub or run dsh plugin --profile web add <package>, then confirm the package is listed.
3. Install on both clients if needed: web and desktop are separate profiles; install in each.

The typical symptom of a wrong profile is "the panel exists on A but not B." The plugin is not broken; it is in another environment.

Do not Apply immediately after installation. Confirm the package and version first; applying the wrong version creates an extra rollback.

First run: the Apply order

Apply writes rules into the host and triggers a restart; wrong order produces "installed but inactive."

1. Open the panel and confirm the state is Installed, not Applied.
2. Read the current rules and confirm the assessment scope and authorization boundary.
3. Run Apply and wait for the write and restart prompt.
4. After restart, open a new session instead of reusing an old one.
5. Return to the panel and confirm the state is Active.

A new session is required. Injection happens during session initialization; an old session does not reload and will mislead you.

Do not change rules immediately after Apply. Run a baseline first, confirm behavior, then adjust; otherwise the change and the original issue blur together.

Verify: four states

dsh-purge has more than installed and not installed.

Installed and Active are separated by Apply and a restart. Seeing the panel is the most common false positive.

Pending re-apply is not a failure. After an upgrade overwrites node_modules, the plugin self-checks during startup; if recovery fails, Apply from the panel rather than editing files.

Common install failures

Four failures cover most install-stage problems.

1. Package not listed. Wrong profile, wrong package name, or interrupted install; confirm with list.
2. Panel present but state frozen. Apply was not run or was blocked by permissions; read the panel and system logs.
3. Apply succeeds but behavior unchanged. No restart or no new session; complete both instead of re-applying.
4. State abnormal after upgrade. Files were overwritten and the state is pending re-apply; wait for self-check or re-apply.

The common entry point is panel state plus logs. Read state, then the write and restart records, then suspect the version.

Rollback point: prepare before installing

For assessment plugins, rollback means Restore to official defaults, not uninstall and reinstall.

1. Record the pre-install state: profile, plugin list, and core version in one note.
2. Confirm Restore is available: seeing the entry means the official default copy is ready.
3. Rollback order: Restore, restart, open a new session, verify.
4. Recheck after rollback: the plugin can stay while policy returns to default; confirm behavior before deciding to uninstall.

The goal is restoring behavior, not removing traces. Uninstalling the plugin leaves the policy and the issue; Restore targets policy.

Next steps

Confirm purpose, choose a version, follow the Apply order. For daily Apply and Restore usage, read How to use dsh-purge. For rulesets, read Managing dsh-purge rulesets. To separate cleanup from uninstall, read What dsh purge really clears.

Sources: dsh-purge plugin page (YuJunZhiXue), dsh-purge plugin page (mmparko), DeepSeek Harness docs - Plugins and lifecycle, dsh CLI README