Community plugins: choose, verify & roll back
Separate discovery, compatibility, permissions, and rollback checks before adding a third-party plugin
GitHub topics, directories, and community recommendations help you find candidates. They are not official endorsement, a complete security audit, or proof that a plugin will work in your profile. Treating “discoverable” and “ready to install” as different decisions reduces supply-chain and upgrade risk.
Use four evidence levels
| Evidence level | What it can establish | What it cannot establish |
|---|---|---|
| Discovery | A project, package, or repository exists | Identity, compatibility, or safety |
| Source & manifest | Maintainer, install source, version or commit, and a dsh.bundle declaration | Runtime behavior or dependency risk |
| Compatibility | Installation on one DSH version, or a minimal isolated-profile check | Every feature, performance, or safety property |
| Operational review | Traceable versions, test records, or a recent maintenance signal | Third-party security certification or long-term availability |
A status is not a security conclusion
“Listed”, “clean”, “compatible”, and “verified” describe the scope of a particular index or test. They do not mean the code has had a complete security audit, nor that it will work in every profile, platform, or dependency combination.
Pre-install checklist
- Pin down the source. Follow the plugin page to the actual npm package or code repository. Check its organization or author, repository URL, license, and recent releases; watch for namesquatting and abrupt maintainer changes.
- Pin down the version. Record the package version or Git commit you plan to install. “Latest” is not a reproducible deployment strategy.
- Review permissions and dependencies. Pay particular attention to filesystem access, command execution, network requests, token access, install scripts, and transitive dependencies. The closer a feature gets to your workspace or credentials, the higher the review bar.
- Check compatibility. Compare the plugin's stated
@deepseek-ai/dshsupport with Recent Updates. If there is no clear declaration, treat compatibility as unknown rather than assumed. - Try it in an isolated profile first. Do not make a profile containing production credentials, real code, or your daily plugin composition the first installation target.
- Keep rollback evidence. Save the profile configuration before and after, the exact install command, version or commit, and the minimal test result. Confirm that removing the plugin restores the prior composition.
Run a minimal isolated-profile check
Create a separate profile for the experiment, then install from a fixed version or commit. For example:
dsh plugin --profile plugin-sandbox add <package>@<version>
# Or use a reviewed Git repository at a fixed commit
dsh plugin --profile plugin-sandbox add github:<owner>/<repo>#<commit>Run only the smallest task the plugin claims to support and record the DSH version, plugin version, OS, permission prompts, and logs. Afterwards, use remove <package> in that same profile to undo the package; before moving it into a daily profile, recheck the pinned version and configuration differences. See plugin management for the full command syntax.
How to use cordis.run
cordis.run is a useful discovery starting point. Where a plugin page provides an install source, version, upstream link, or status, treat it as a time-stamped index signal: open the upstream source before copying it, then apply the checklist above. An install command on the page is appropriate for the first isolated-profile check; it should not bypass source, permission, or compatibility review.
If a listing appears stale, its source does not match, or a security hint is wrong, report it to the relevant directory or upstream project instead of relying on the directory status for deployment.
Further reading
- whyihaveyou/dsh-suite publishes plugin compatibility states and update times, which is a useful example of traceable status.
- AdamPlatin123/awesome-dsh-plugins describes evidence levels from discovery through runtime validation. This guide adopts the principle of stating the evidence boundary, not an endorsement of its entries.
- zp-home/dsh-recommend distinguishes static security hints from security certification, an important distinction when reading any directory.