Is this DSH plugin worth installing? Trust signals

Whether a dsh plugin is worth installing needs no ranking list — four signals are enough: last update time, permission scope, dependency count, and whether anyone files issues on its repository. All four are directly checkable in the plugin market and its GitHub repo, and going through them takes two or three minutes to produce a usable score for a plugin you have never seen. This piece offers no recommendations, only the scorecard.

The four signals for judging a DSH plugin

What the four signals share is that they are self-checkable: repository metadata and code facts, requiring no trust in anyone's recommendation (source). How to check each:

1. Last update time: visible right on a plugin card in DSH Plugin Hub. Criterion: UI and session plugins are bound most tightly to the DSH version, and a package untouched for six months often fails to load on a new dsh release.
2. Permission scope: look at what its tools touch — read files, write files, make network requests, or require install-time allowBuilds. Criterion: the smaller the surface the safer, and anything requiring a grant must have readable source.
3. Dependency count: look at how many packages it pulls in and whether it pins an old core package. Criterion: dependencies-heavy plugins fall behind more easily after a DSH upgrade and more easily fight existing plugins over the same core package.
4. Open issues: open the repository's issue list and read the nature, not the number. Criterion: layout breakage or missing icons is low risk; data loss, permission escalation or corrupted sessions is high risk; and zero issues plus zero replies usually just means nobody has used it.

Two more fields sit alongside these in the market: compatibility status (verified / unconfirmed) and the target DSH version (dshTarget). Read together with the last update time, they answer "can it still run today".

Risk tiering for DSH plugin permissions and dependencies

Permission risk tiers by what it can touch and dependency risk tiers by how much it brings in; you need both to judge whether a plugin will change your setup (source). The tiers:

On the dependency side, watch three things: how many packages, whether an old core package is pinned, and whether it shares a core package with another plugin. The first two decide whether it still loads after a DSH upgrade; the third decides whether plugins collide. The full permission breakdown is in DSH plugin capabilities and permission boundary, and the install-time steps are in installing DSH plugins safely.

Two outcomes: which DSH plugins to hold off on, which to try

The scorecard routes rather than ranks — running the four signals naturally drops a plugin into "hold off" or "safe to try". The outcomes:

Four kinds to hold off on:

1. It requires allowBuilds and you have not read its source;
2. Its last update is very old while its compatibility status is still unconfirmed;
3. It pulls in dozens of packages, or pins the core package to an old version;
4. It has unresolved issues involving data loss, permission escalation or corrupted sessions.

Match two or more of the four and switching to a similar plugin beats de-mining this one yourself.

Two kinds to try right away:

1. Read-only tool plugins with verified status that are still being updated — the kind that looks things up, views images or reports usage without changing anything of yours;
2. Plugins with open issues but an author who keeps replying, where the issues are display-level — proof the project is alive and that someone handles problems.

If you want ready-made lists instead, see top dsh plugins and picking dsh plugins by scenario. Those are someone else's screening; this card is for screening on your own.

DSH plugin evaluation notes

The scorecard gives an order of judgement, not a guarantee; passing all four signals is not the same as zero risk.

1. Look at the last update first, everything else second: an unmaintained plugin will break with a DSH upgrade no matter how small its permissions.
2. Compatibility status is a community label, not a promise: verified means someone confirmed it works, not that it will work on your version and platform.
3. allowBuilds really executes at install time: confirm the package name and source before granting, and never hit enter on a package you do not recognise.
4. Read the nature of issues, not the count: a repo with zero issues is not necessarily good — it may simply be unused.
5. Read dependencies at the profile layer: what dsh plugin list prints is the layer actually installed into the profile.
6. When unsure, try it in an unrelated project: a plugin only affects the profile it is installed into, so an isolated profile is the cheapest way to experiment.
7. Re-check after installing: the real confirmation is restarting and running dsh --profile <name> --dump-config to see the config layer attached and the tools present in the tool list.

Source: DSH Plugin Hub, DeepSeek Harness CLI README, docs - publishing a plugin, docs - writing tools.