Your build broke this morning. Not because of a bug or a failed test, but because npm 12 now requires your explicit permission to run install scripts in your dependency tree. Welcome to the new default.
This isn't a regression. It's intentional. Myths about what this change means are spreading faster than the actual documentation.
Why These Myths Persist
Supply chain security changes often feel imposed on you. When a tool you've relied on for years suddenly requires new workflows, the first instinct is to find workarounds or assume the change doesn't apply to you. But npm 12's shift to disabling install scripts by default represents a fundamental rethinking of trust in the dependency chain. Understanding what's actually changed (and what hasn't) determines whether your team adapts smoothly or struggles with the tooling for the next six months.
Myth 1: "This Only Affects New Projects"
Reality: Every project that upgrades to npm 12 gets the new behavior, regardless of when you created it.
The install script default applies at the npm client level, not the project level. If you're running npm 12 and execute npm install in an older codebase, scripts won't run unless you explicitly allow them with --install-scripts. Your existing package.json doesn't grandfather you into the old behavior.
This matters for CI/CD pipelines. If your build agents auto-update npm or you're using a container image that pulls the latest version, your builds will start failing when scripts that previously ran silently now require approval. Check your pipeline definitions now and add the flag where you need it. Better yet, audit which dependencies actually require install scripts and whether you trust them.
Myth 2: "I Can Just Add --install-scripts to Everything"
Reality: You can, but you're defeating the entire security improvement.
The flag exists for backward compatibility, not as a permanent solution. If you globally enable install scripts across all your projects, you've opted back into the exact risk npm is trying to mitigate: arbitrary code execution from dependencies you haven't vetted.
Ask yourself, "Does this package actually need to run a script during install?" Most don't. The ones that do often use install scripts for platform-specific binary compilation or environment setup. Review your dependency tree, identify which packages require scripts, and document why you're allowing them. Use --install-scripts selectively, not as a blanket override.
For packages you maintain, consider whether your install script could become a post-install instruction in your README instead. If you're compiling native modules, you're stuck with scripts. If you're just copying files or setting permissions, you might not be.
Myth 3: "Granular Access Tokens Are Going Away Completely"
Reality: GATs still exist, but their ability to bypass 2FA for sensitive operations ends in August 2026.
GitHub isn't deprecating granular access tokens. They're deprecating the specific configuration that allowed GATs to skip two-factor authentication when performing sensitive actions like publishing packages. Starting August 2026, if you've configured a GAT to bypass 2FA, it won't work for those operations anymore.
This creates an operational challenge for automated publishing workflows. If your CI/CD pipeline publishes to npm using a GAT that bypasses 2FA, you'll need a human in the loop for the 2FA prompt, or you'll need to restructure your authentication approach. The security rationale is sound: automated tokens shouldn't be able to publish packages without additional verification, even if they're scoped tokens.
Your options: implement a manual approval step in your release pipeline where a human with 2FA completes the publish action, or investigate whether your organization's setup supports alternative authentication methods that satisfy the 2FA requirement programmatically (though this is tricky and may not align with npm's intent).
Myth 4: "Supply Chain Attacks Happen to Other People"
Reality: If you're pulling from npm, you're in the supply chain attack surface.
The reason npm made install scripts opt-in is because dependency compromise is common enough to warrant breaking changes to default behavior. Install scripts execute with the same permissions as your build process. If a compromised package runs a script that exfiltrates environment variables, it gets your API keys, your cloud credentials, your database passwords, everything in your CI environment.
You don't need to be a high-value target. Attackers compromise packages with large download counts, then wait for the install scripts to harvest credentials from whoever updates. The attack scales automatically.
Treat every dependency as potentially hostile. That doesn't mean avoiding dependencies, it means understanding what they're doing during install. Run npm ls --all to see your full dependency tree, then check which packages have install scripts with npm explore <package> -- cat package.json | grep scripts. If you don't recognize a package or can't explain why it needs an install script, that's a research task, not a "click yes and move on" moment.
Myth 5: "This Breaks Legitimate Use Cases"
Reality: It changes legitimate workflows, but it doesn't break them.
Yes, some packages legitimately need install scripts. Node-gyp for native modules, platform-specific binary downloads, post-install setup tasks, these are real requirements. The change doesn't make them impossible, it makes them explicit.
If you're using a package that needs an install script, you'll know because the install will fail with a clear message. You add the flag, the script runs, your build continues. The difference is you've now acknowledged that you're allowing code execution from that dependency. That acknowledgment is the security improvement.
For internal packages your team maintains, this is an opportunity to audit whether you actually need install scripts or whether you've been using them out of habit. Can the setup happen at runtime instead? Can you provide a separate setup command users run manually? These alternatives aren't always feasible, but they're worth considering.
What to Do Instead
Start with an audit. Run your builds with npm 12 in a test environment and document which dependencies fail without --install-scripts. For each one, research what the script does (check the package's package.json and the actual script file) and decide whether you trust it.
For CI/CD, update your pipeline configurations now rather than waiting for the failure. If you're using GitHub Actions, update your workflow files to include --install-scripts where needed. If you're using Jenkins or GitLab CI, update your build scripts. Document why each flag is there.
For GATs, check your token configurations before August 2026. If you've got tokens set to bypass 2FA for publishing, plan your transition now. That might mean adding a manual approval gate to your release process, or it might mean rethinking how you handle package publishing entirely.
The goal isn't to make your life harder. It's to make supply chain compromise harder. The difference is whether you're thinking about these scripts before they run or after they've exfiltrated your credentials.
