Treat every plugin as executable software
A plugin may be able to read files, call external services, execute tools, or change the interface you use to supervise an agent. A useful description and a large star count do not tell you which capabilities it requests.
Start by confirming that the repository you are reading is the same repository referenced by the install command. Watch for renamed packages, copied READMEs, release assets hosted on unrelated domains, and commands that download additional scripts.
Five checks that produce real evidence
- Source: identify the owner, license, default branch, recent commits, releases, and open maintenance signals.
- Install path: locate the exact command or manifest and understand every package, script, and binary it introduces.
- Compatibility: look for a supported dsh version, a reproducible example, or a commit that matches the current harness architecture.
- Access: list filesystem, network, credential, browser, shell, and model permissions the plugin needs.
- Recovery: know how to disable the plugin and restore the last working configuration before the first run.
Use a low-risk first run
Test unfamiliar plugins with non-sensitive files, limited credentials, and the smallest practical permission set. Avoid combining several new plugins in the same first run because failures become harder to attribute.
If a plugin has no documented uninstall or rollback path, treat that as missing operational evidence—not merely missing documentation.
How to read DSHub labels
Official source means the repository is controlled by the official project owner. Human verified means DSHub recorded specific install and compatibility evidence. Source linked means the repository exists and its public facts were checked, but native plugin compatibility has not been independently confirmed.