ccdwyer/dependency-bouncer

A Claude Code mod that vets packages before they install.
ccdwyer/dependency-bouncer

A Claude Code mod that vets packages before they install. It watches npm, yarn, pnpm, bun, pip, uv, poetry and pipx install commands, plus edits to package.json, requirements files and pyproject.toml. Each package is checked against the npm or PyPI registry and blocked if it looks hallucinated, typosquatted, brand-new with install scripts, or sourced from a git URL/tarball; risky cases get a caution or hint. Includes /allow-dep, caching, and privacy notes.
Check the author's README for the marketplace and plugin name first. Commands may change as the repository evolves.
claude plugin marketplace add ccdwyer/dependency-bouncer claude plugin install dependency-bouncer

A Claude Code mod that vets packages before they install.
It watches install commands: npm i/install/add/ci/exec/update, npx, yarn add, yarn workspace … add, pnpm add/dlx, bun add/x, npm create, pip install (including -r files and their includes), uv add, uv pip install, uv tool install, uvx, poetry add, uv sync, poetry install and pipx. The command parser handles:
--no-binary, --find-links and --no-indexsudo, env, corepack) and venv paths (.venv/bin/pip)bash -c/-lc, eval, backticks and $(…)cd, and if … then blocksA bare npm install checks the version the lockfile pins for each dependency that isn't already installed at that version. npm ci checks every dependency, because it wipes node_modules and runs every install script again.
It also watches edits to package.json (dependencies, overrides, resolutions, npm: aliases, lifecycle scripts), requirements*.txt, requirements/*.txt and pyproject.toml (PEP 621, dependency groups, Poetry tables). New entries are checked, and so are existing entries whose version or source changed.
Each package is checked against the npm or PyPI registry, at the release that would actually install. npm ranges resolve the way npm resolves them (latest first, then the highest match, with npm's pre-release rules). PyPI specifiers follow PEP 440.
| Signal | Result |
|---|---|
| Package doesn't exist (likely hallucinated) | blocked |
| The requested version or tag isn't published | blocked |
| One typo (swaps included) from a popular package or scope, with under 50k weekly downloads | blocked (possible typosquat) |
| Popular name whose code comes from a git URL or tarball instead | blocked |
| First published under 30 days ago and runs install scripts (npm), or would build from source (PyPI: no wheel, or --no-binary) | blocked |
| New, under 1,000 weekly downloads, install scripts, deprecated, no wheels, or a git/URL source | allowed, with a caution for the model and a toast |
| --extra-index-url or --find-links in play (dependency confusion risk) | caution |
| A requirements file fetched from a URL | blocked |
| A custom registry (--registry, --index-url, --no-index, env vars, requirements-file index options, project or ~/.npmrc) | caution only; the public registry isn't consulted, so private package names don't leak and can't false-positive |
| The project already has a package that does the same job (e.g. adding moment alongside date-fns) | hint |
| A new preinstall/install/postinstall/prepare script in package.json | caution |
Well-known packages pass without a network call. Lookups run in parallel against one 5-second deadline, and whatever has answered by then still counts. Results are cached for 15 minutes. If the registry is unreachable, the install goes ahead with a warning, unless the name is also one typo away from a popular package. Text from the registry, such as deprecation notes, is quoted and marked untrusted before the model sees it.
/allow-dep <name> allows a blocked package for the rest of the session. It normalizes PyPI names the way PyPI does. /allow-dep with no name shows the last check.
Not covered:
npm i some-cli says nothing about its dependency tree.uv.lock and poetry.lock aren't read, and neither are workspace member manifests.pip.conf, requires_python and wheel-compatibility selection aren't modelled.bash x.sh or source, and for loops, aren't followed.cd made in a previous tool call isn't tracked.npm install catches it./plugin marketplace add ccdwyer/claude-mods
/plugin install dependency-bouncer@ccdwyer-mods
/reload-plugins
claude plugin validate .
claude plugin test .
Events this mod hooks, as claude plugin validate reads the module:
session.startcommand.run{command=allow-dep}tool.callEngine calls it makes: $.clock.now (via by, vet), $.clock.sleep (via by), $.command.register, $.env.get (via ambientRegistries, homeDir), $.fs.read (via readOr), $.http.fetch (via getJson), $.state.get, $.state.set, $.ui.toast.
A tool.call hook sits in the middle of every tool call: it can see the call, refuse it, or add context to its result. This mod uses that only for the behaviour described above.
Before a package installs, it sends the package name (and version, when known) to the public registries to check it: registry.npmjs.org, api.npmjs.org and pypi.org. No code, file contents or credentials are sent.
The mod collects no analytics or telemetry, and its author receives no data from it.
Full policy: PRIVACY.md.
MIT