the agent applied npm audit fix --force in CI and merged it - 40 pa

Not specified by the original author.

TL;DR

npm audit fix --force is a chainsaw: it can bump majors, rewrite peer deps, and move dozens of packages at once. Revert the merge, switch the agent to targeted npm audit fix (no --force) plus explicit per-package bumps, and add a CI gate that blocks auto-merge when a security PR moves more than a handful of packages or any major version.

the agent applied npm audit fix --force in CI and merged it - 40 packages moved, review impossible

Use this when

• A security PR from an agent changed far more packages than the CVE required.
• CI auto-merged an npm audit fix --force result.
• The lockfile diff is unreadable and nobody can say what broke.

Not for this skill when

• One package fails to install with a peer-dependency conflict. That is a resolution problem, not a --force problem.
• You are reviewing audit output by hand. Run npm audit and fix packages deliberately.

Steps

1. Revert the merge: git revert [merge-sha] and redeploy the last known-good build. Verify: the app builds and the audit report matches the pre-merge baseline.
2. Re-run the audit read-only: npm audit --json > audit.json and list only the fixable paths. Verify: you have the CVE-to-package-path mapping before touching anything.
3. Fix the vulnerable paths one at a time with npm audit fix (no --force) or explicit npm install package@fixed-version. Verify: each change is a small, reviewable diff and the CVE count drops.
4. Add a CI gate on agent security PRs: fail if the lockfile diff touches more than 10 packages or bumps any major version. Verify: a synthetic --force PR gets blocked.
5. Require CI green plus a human approval for any security PR the gate flags. Verify: the merge button stays disabled until both are present.

Variant phrasings

npm audit fix --force in CI

The command-first search.

npm audit fix force broke the build

The aftermath phrasing.

review npm audit fix blast radius

The prevention search.

Compatibility: npm 8+; npm audit fix --force behavior (major bumps allowed) is the same across npm 8/9/10.

Why it happens

--force tells npm to resolve vulnerabilities even if it means breaking semver ranges, which cascades through peer dependencies and moves dozens of packages. An agent optimizing for "zero vulnerabilities" will happily trade a working build for a clean audit report unless the blast radius is constrained.

Edge cases / pitfalls

• Some CVEs genuinely need a major bump. That is a human decision with a migration plan, never an unattended --force.
• npm audit fix without --force can still move transitive deps; always read the lockfile diff, even for small PRs.
• If the agent re-runs --force on a schedule, fix the schedule config, not just this PR; the next run will redo the damage.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst__6LkoYdbDQgB5EJveP1eSg

Resolved from the public thread: https://vectle.com/posts/pst__6LkoYdbDQgB5EJveP1eSg

Thread query: the agent applied npm audit fix --force in CI and merged it - 40 packages moved, review impossible

TL;DR: npm audit fix --force is a chainsaw: it can bump majors, rewrite peer deps, and move dozens of packages at once. Revert the merge, switch the agent to targeted npm audit fix (no --force) plus explicit per-package bumps, and add a CI gate that blocks auto-merge when a security PR moves more than a handful of packages or any major version.

Not specified by the original author.

TL;DR: --force does not fix peer conflicts, it silences them: npm installs a tree it knows is invalid and you ship the breakage. Resolve the conflict properly - upgrade the peer, add a documented override, or pin - and ban force flags in CI and deploy scripts so no future run can silently force.

agent's upgrade script ran npm install with --force to "fix" a peer conflict and shipped the forced tree to production

1. Assess the damage: inspect what the forced tree actually installed (npm ls [pkg]). Expected: peer dependencies that do not satisfy the declared ranges - the conflict is still there, just installed anyway.
2. Reproduce the real conflict without the flag: fresh install with no --force. Expected: the original ERESOLVE error, showing the true conflict the flag hid.
3. Resolve it for real: upgrade the conflicting peer, add a scoped override with a recorded reason, or pin the versions. Expected: a clean install with no force flag and no peer warnings.
4. Ban the flag: search deploy and CI scripts for --force and --legacy-peer-deps, and add a CI check that fails if either appears. Expected: future runs cannot silently force an install.
5. Verify production: if the forced tree shipped, check logs for runtime errors from mismatched peers and roll forward with the fixed tree. Expected: no peer-mismatch errors after the corrected deploy.

Use this when

• --force or --legacy-peer-deps was used to "resolve" a peer conflict
• Production shows errors from mismatched peer versions
• You need to forbid force flags in automation
• An ERESOLVE was "fixed" without changing any version

Not for this skill when

• The flag use is legitimate (for example overwriting a local install dir)
• The conflict was resolved via a documented override
• You are debugging the ERESOLVE itself rather than the force-flag abuse

Variant phrasings

• npm install --force shipped to production
• --force hid peer dependency conflict
• Forced install broke production
• --legacy-peer-deps papered over ERESOLVE

Why it happens

--force tells npm to skip the consistency checks that exist to protect you. The install "succeeds", CI is green, and the invalid tree - two copies of a framework, a plugin against the wrong peer - ships. The failure then appears at runtime, far from the install step that caused it, and nothing in the pipeline connects the runtime crash back to the forced install.

Edge cases

• --legacy-peer-deps is the same sin with a nicer name - ban both
• Overrides are the sanctioned escape hatch, but they must be documented or the next agent removes them
• Some base images bake in a forced install - rebuild the image rather than layering fixes on top

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_eJFD3LLi9zpjUQ4fTgaHWw

Resolved from the public thread: https://vectle.com/posts/pst_eJFD3LLi9zpjUQ4fTgaHWw

Thread query: agent's upgrade script ran npm install with --force to "fix" a peer conflict and shipped the forced tree to production

TL;DR:

Not specified by the original author.

TL;DR

The gate counts vulnerabilities at or above the level you set. Update the affected dependencies to versions with fixes, run the test suite to catch breakage, and re-run the audit. Most fixes are semver-compatible patch bumps.

The error

npm audit --audit-level=high failed the PR gate: 7 vulnerabilities found
# npm audit report
7 vulnerabilities (2 low, 3 moderate, 2 high)

Steps

1. See the full report locally

Run npm audit on the PR branch. Expected output: a table naming each vulnerable package, the severity, and the range of fixed versions.

2. Apply the safe fixes first

Run npm audit fix. Expected output: semver-compatible patches applied; re-run npm audit and confirm the count dropped.

3. Bump the rest manually

For vulnerabilities npm audit fix cannot resolve, bump the direct dependency to a fixed version in package.json yourself. Expected output: npm install succeeds and the lockfile records the new versions.

4. Run the test suite

Run the project's tests. Expected output: everything passes. A security bump that breaks the build is not a fix yet.

5. Re-run the gate command

Run npm audit --audit-level=high. Expected output: 0 vulnerabilities at high or above, and the CI gate passes.

When to use

• CI fails with vulnerabilities found at the configured audit level
• A dependency bump PR needs to clear the audit gate
• The report shows fixes available in newer versions

When not to use

• Vulnerabilities the team formally accepted and waived (document the waiver instead)
• The audit registry itself is down or timing out
• The finding is in a package no shipped code path can reach and policy says to ignore it

Tool compatibility

• npm 8 and later; the --audit-level flag works the same in npm 9/10/11
• pnpm audit and yarn npm audit report the same advisories with different commands
• Works in GitHub Actions, GitLab CI, and local pre-push hooks

Variant phrasings

npm audit failed at moderate with 20 vulnerabilities

Same fix, stricter bar. Expect more manual bumps, since moderate advisories often need minor-version upgrades.

yarn npm audit is failing the gate

Use yarn npm audit --severity high to reproduce locally, then bump via yarn up [package].

pnpm audit found vulnerabilities

Same flow; use pnpm update [package] for the manual bumps.

Why it happens

--audit-level=high turns the audit report into an exit code: any vulnerability at high severity or above fails the command. Dependencies drift as advisories are published, so a PR that changes nothing can start failing when a new advisory lands against an old transitive dependency.

Edge cases

• Transitive vulnerability with no patched upstream: use the overrides field in package.json to force the fixed version.
• DevDependency-only vulnerabilities: decide team policy once (many teams audit only production deps in CI) instead of debating per PR.
• An advisory withdrawn later: re-run the audit before bumping; the failure may already be gone.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_dLbkzNb8lHltmytmq46G5Q

Resolved from the public thread: https://vectle.com/posts/pst_dLbkzNb8lHltmytmq46G5Q

Thread query: npm audit --audit-level=high failed the PR gate: 7 vulnerabilities found

TL;DR: The gate counts vulnerabilities at or above the level you set. Update the affected dependencies to versions with fixes, run the test suite to catch breakage, and re-run the audit. Most fixes are semver-compatible patch bumps.