Check a plugin
before you install it
Paste an npm package name or link and see within seconds whether a DeepSeek Harness plugin shows risk signals. It reads public npm data only and never downloads or runs a package.
What is this?
Plugin Check is a free web tool that checks the npm package behind a DeepSeek Harness plugin for risk signals before you install it: whether a script that runs at install time was added, whether the publisher changed, whether there is a source repository, and whether the package is brand new. It reads only public npm metadata and gives a red, yellow or green result, with the evidence for each.
Three steps
From paste to evidence usually takes under a second.
Paste
Enter a package name such as lodash, or paste a package link from npmjs.com. A version number is optional.
Check
We read the package's public record on npm, compare it with the previous version, and apply fixed rules one by one.
Read the evidence
You get a red, yellow or green result and every rule that matched, so you can verify it yourself.
What we look for
The rules are open, and the same input always gives the same result.
- This version adds a preinstall, install or postinstall script that the previous version did not have.
- An install script contains download-and-run patterns such as curl, wget, sh -c or eval.
- An install script was added and the publisher differs from the previous version.
- It has an install script, but it is not new.
- No source repository link is listed.
- A new version after more than 90 days of silence that also adds an install script or changes the publisher.
- The publisher differs from the previous version.
- A higher version of the same package is already red.
- None of the rules above matched.
- A package under 7 days old or with only one version gets a note only; the color does not change.
- A missing provenance statement is only a missing bonus and does not lower the result.
A real red example
Version 0.2.1 of the DeepSeek Harness plugin dsh-plugin-blender-3d was published on 26 October 2026. Compared with 0.2.0 it adds a postinstall script that runs automatically on install. Plugin Check rates it red, and this is the key signal.
How it works under the hood
Read only
It reads public npm metadata only. It never downloads package files or runs any code.
No AI
Every result comes from fixed rules, not model guesses. The same input gives the same result.
Evidence for each
Red, yellow and green all list which rule matched. It is not a black-box score.
No sign-in
No account and no email address needed. Our code does not save the package names you check; results sit briefly in a cache, and our hosting provider may keep its own standard access logs.
What it cannot catch
This tool looks only at public npm metadata and signals such as install scripts. It does not analyse the code inside a package. In September 2025, 18 packages including chalk and debug were compromised with a payload hidden in the code rather than an install script, and a check like this one would not catch that. A script-free malicious version published from a hijacked account may also show green. So green only means the rules found no risk signals; it is not a safety guarantee.
Sources: AWS Security Blog · Wiz on Shai-Hulud
FAQ
What does this page do?
You enter an npm package name or link. It reads public npm metadata and applies fixed rules to show red, yellow or green risk signals with the evidence.
Does it download or run the package?
No. It only reads metadata from registry.npmjs.org. It does not download the package or execute any code.
What do red, yellow and green mean?
Red means a high-risk signal, for example a new postinstall script in this version that downloads and runs something. Yellow means something worth a closer look, for example no repository link. Green means no risk signals were found.
Does green mean safe?
No. Green only means these rules found no risk signals. It is not a guarantee, so please confirm the source yourself before installing.
Can it catch every malicious package?
No. It checks metadata and install scripts only. A payload hidden in the package code, or a script-free malicious version published from a hijacked account, may not be detected.
Why look at preinstall, install and postinstall?
They run automatically when a package is installed. The September 2025 Shai-Hulud worm spread through a postinstall script.
Why does a newly added script matter more?
Many normal packages already ship install scripts. One that suddenly appears in a new version, especially after a publisher change or a long gap, deserves a manual look.
Why aren't build, test and prepare counted?
They do not run automatically when you install a dependency from npm.
What should I do if a package is red?
Do not install it. Check its repository and changelog. If you already installed it, rotate any tokens or keys that may have been exposed.
Do you store the package names I check?
Our code does not save them. Results sit briefly in a cache, and our hosting provider may keep its own standard access logs.