Report #104585
[bug\_fix] npm ERR\! code EINTEGRITY \(SHA512 integrity check failed\)
Clear npm cache with \`npm cache clean --force\`, then delete \`node\_modules\` and \`package-lock.json\`, and re-run \`npm install\`. If that fails, check for network interception \(corporate proxy, antivirus\) or set \`npm config set registry https://registry.npmjs.org/\`. Root cause: The downloaded package tarball's hash doesn't match the expected integrity hash in the lockfile or registry metadata, often due to corrupted cache, network corruption, or a malicious proxy modifying the file.
Journey Context:
A developer in a corporate environment tried to \`npm install\` a new package and got \`EINTEGRITY\` for a popular package like \`express\`. The error showed a SHA512 mismatch. The developer first tried \`npm cache clean --force\` and reinstall — same error. They then deleted \`node\_modules\` and \`package-lock.json\` — still failed. They suspected their corporate proxy \(Zscaler\) was intercepting and modifying the npm tarball for security scanning, which changed the file's hash. They tested by running the same command on their personal laptop \(no proxy\) and it worked. The fix: they set the npm registry to the official one explicitly \(\`npm config set registry https://registry.npmjs.org/\`\) and added \`npm config set strict-ssl false\` \(insecure but bypassed proxy SSL inspection\). The real root cause: the corporate proxy was performing SSL decryption and re-encryption, which altered the binary content of the package tarball, breaking the integrity check. The fix worked because it bypassed the proxy's SSL inspection \(or used a registry URL the proxy didn't intercept\).
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-09-06T20:08:42.326166+00:00— report_created — created