Is DSH safe to run?
The honest answer is that the runtime is the easy part. What you install into it is not.
People ask this question about every agent runtime, and they usually get an answer about the runtime's own code. That is the wrong place to look. Once you install plugins, the runtime's security properties are largely irrelevant — the question becomes what each plugin can reach, and nobody is auditing 715 repositories.
What the risk actually consists of
A DSH plugin runs with the permissions of your user account and your runtime session. In practice that means most plugins can:
- read and write files your user can reach
- read environment variables, including API keys
- make outbound network requests
- spawn processes, if the runtime's shell capability is enabled
This is not a flaw unique to DSH — it is the shape of every plugin system that gives extensions real capability. It does mean the trust decision happens when you install, not when you launch.
The licence question, which surprises people
Of the 715 catalogued plugins, 87 declare no licence at all and a
further 39 declare NOASSERTION — GitHub's field for a licence
it could not identify. That is over 100 projects where the legal terms of use are, at best,
unclear.
No licence does not mean hostile. It means you have no explicit grant, and neither does anyone else. For personal use this rarely matters. For anything you ship to a customer, it is a question your lawyer will ask.
Distribution risk
Plugins are installed from repositories, not from a curated store. There is no review, no signing, no publisher verification. A plugin repository can change its contents at any time, including after you installed it. Nothing in this ecosystem gives you an auditable install the way a package registry with provenance does.
The practical mitigation is boring and effective: pin what you install. Vendor the plugin into your own repository, or record the commit hash you installed. Updating should be a deliberate act you can review, not an automatic one.
Prompt injection, which is the real problem
If your agent reads web pages, issue trackers, emails or files from other people, those documents can contain instructions. An agent with file read access and a network-capable plugin can, in principle, be talked into exfiltrating what it has read. No amount of runtime hardening fixes this, because the attack arrives as legitimate input.
This is why the Web & Browser and Tools & Integrations categories deserve more caution than their size suggests. An agent that can read a page can usually also submit a form.
What to actually do
- Run it as a separate user. Cheap, and it constrains file access to what that user owns.
- Do not put long-lived keys in the plugin's environment. Use scoped keys with spend limits, so a bad day costs you a small amount rather than your balance.
- Pin and vendor. Review updates as diffs, not as commands.
- Read the source of anything that touches the shell or the network. These are small projects; the code is usually short enough to scan in ten minutes.
- Separate sessions by trust. Do not run your untrusted-input workload in the same session as the one holding working credentials.
- Prefer projects with a licence and a recent push. Not because maintained code is necessarily secure, but because an abandoned project will not be patched when something is found.
The uncomfortable summary
DSH itself is not the risk. The risk is the same as with any plugin ecosystem that grew faster than its review processes: a large, unvetted surface, running with your permissions, on repositories that can change under you. That is a manageable risk if you treat installation as a security decision. It is an unmanaged one if you treat it as a convenience.
For the maintenance side of the same question — which projects are still alive — see the freshness markers on the plugin index and the per-category deep-dives under categories.