Yes—some coding agents can install dependencies when a task and its environment allow it, but behavior varies by product, configuration, and permissions. A README instruction is not proof that a package is authentic, a sandbox is not a package check, and a clean advisory scan does not establish that a dependency is safe. The practical safeguard is to verify a proposed package’s exact name, source, and version before allowing it to run.
Myth 1: Agents never install dependencies without me
There is no universal yes-or-no answer. An agent may read project setup instructions and run an install command if its environment permits that action. Anthropic documents an npm-based installation route for Claude Code, while a security study evaluated agents that followed setup documentation and installed packages in specific scenarios. Neither establishes what every agent will do in every task.
As an Amazon Associate I earn from qualifying purchases.
Before delegating setup, check the particular agent’s execution mode, permission settings, and package-manager access. Anthropic’s Claude Code installation documentation also warns: “Do NOT use sudo npm install -g as this can lead to permission issues and security risks.” Anthropic’s installation guidance is specific to Claude Code; do not treat it as a rule for every tool.
Myth 2: A README instruction proves a package is legitimate
Repository instructions are data to verify, not proof of identity. The study describes attacks that use ordinary setup documentation to steer agents toward an untrusted registry, a known-vulnerable version, or a plausible but incorrect package name. A command can look routine while pointing to a different package or source than the project actually needs.
#1 Best Overall
Before installation, confirm these details against a trusted project source:
- Exact package name: Check spelling and scope, including punctuation and organization prefix.
- Registry or source: Confirm the configured registry, repository URL, or other origin rather than accepting a new source introduced only in setup text.
- Version: Check that the requested version is intended and not an unexplained downgrade or vulnerable release.
- Install behavior: Review the command and any lifecycle scripts that may execute during installation.
In its evaluation, the study found that deterministic checks before installation were an effective mitigation. Its results varied by harness-model configuration, so they should not be read as a universal failure rate or guarantee.
Myth 3: A sandbox makes installation harmless
A sandbox can limit what an agent can reach, but it does not establish that a dependency is authentic or benign. Keep four separate questions in view: can the process access the host, can it reach the network, is the package trustworthy, and what integrations or credentials can it use?
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Network rules matter because package installation usually requires access to a registry or other source. Anthropic documents configurable network access, ranging from no access to package managers or broader domains. GitHub describes its cloud agent as running in an ephemeral, firewalled environment. These are different controls and product designs; neither description means every install is safe.
Allow only the network access the task needs. If installation is not required, disable egress where the product permits it. If it is required, constrain access to the necessary sources and retain package verification as a separate step.
Myth 4: A clean vulnerability scan means a dependency is safe
A scan can find issues within its coverage; it cannot prove a package is harmless. GitHub says its relevant workflow checks newly introduced dependencies against the GitHub Advisory Database for malware advisories and high- or critical-severity vulnerabilities. That is a defined check, not a universal inspection of every package or risk.
Rank #4
Use advisory scanning as one layer alongside package identity and source verification, version review, and appropriate network limits. A clean result means the check did not identify an issue within its stated scope; it does not mean the dependency has no vulnerabilities, malicious behavior, or suitability concerns.
Myth 5: All coding agents install packages the same way
Installation behavior depends on the product and deployment. Compare the specific version and mode you use rather than assuming a behavior documented for another tool applies to it.
Best Value
| Product or mode | What the cited source establishes | What to keep in mind |
|---|---|---|
| Claude Code | Anthropic documents an npm installation route and other installation methods. Source | That documentation does not establish that every Claude Code task installs dependencies automatically. |
| OpenAI Codex cloud, launch configuration | OpenAI’s launch announcement described a cloud setup with pre-installed dependencies and internet disabled. Source | This is the launch configuration described in that announcement, not necessarily current behavior. |
| GitHub Copilot coding agent and CLI | GitHub documents distinct cloud-agent and CLI modes. Source | Check the documentation for the specific mode and its current network and permission settings. |
A broader study also found that install-time security depended on the harness-model combination, not the model alone. It evaluated twelve scenarios, five attack classes, nine harness-model configurations, four harnesses, and seven models; those are evaluation dimensions, not estimates of how often attacks occur across real-world use.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How to stop an agent from installing an unverified package
- Check whether installation is needed. Review the task and repository setup instructions before granting package-manager access.
- Inspect the proposed install. Verify the exact package name, registry or source, and version against a trusted project source. Review install commands and lifecycle scripts where applicable.
- Set permissions deliberately. Use approval prompts or deny install actions if the task does not require them. Do not assume a product’s defaults match another product’s.
- Limit outbound access. Configure network egress for the task’s needs; allow package sources only when installation is necessary and the environment supports that restriction.
- Run advisory checks. Treat their results as a useful additional signal, not a certification of safety.
- Review the resulting change. Check dependency manifests and lockfiles for unexpected names, sources, or version changes before running the project.
These controls reduce distinct risks; none guarantees safety on its own. The study’s package checks address identity and version before execution, while vendor documentation describes controls such as network boundaries and advisory scanning.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Recommended Free Tools
