TL;DR: The registry reset the connection mid-download, which is transient network flakiness rather than a broken package. Retry the install; it often succeeds immediately. To stop one reset from killing automated runs, raise npm's fetch retry settings so npm backs off and retries on its own.

```text
npm ERR! code ECONNRESET
```

1. Retry the install once before changing anything.
   Expected: the second run frequently completes, confirming the failure was transient.
2. Make retries automatic: `npm config set fetch-retries 5` and `npm config set fetch-retry-mintimeout 20000`.
   Expected: `npm config list` shows the new values; future resets are retried with backoff instead of failing the run.
3. If you are behind a corporate proxy, check `npm config get proxy` and `npm config get https-proxy`.
   Expected: the values match your organization's proxy, or are empty if you connect directly; a wrong proxy causes repeated resets.
4. Test the registry directly: `curl -sI https://registry.npmjs.org/`.
   Expected: an HTTP 200 response; anything else means the problem is network-wide, not npm-specific.
5. During a confirmed registry incident, temporarily switch to a mirror registry, then switch back afterwards.
   Expected: the install completes; you return to the primary registry once the incident clears.

## Use this when
- Installs fail with the exact ECONNRESET code, intermittently rather than every time.
- An agent's upgrade-verification run has no retry logic and marks the upgrade broken after one reset.
- The failure happens mid-download, not at dependency-resolution time.

## Not for this skill when
- The code is EAI_AGAIN; that is DNS, not a reset connection.
- The registry returns 401 or 403; credentials are wrong.
- The registry returns 404; the package or version does not exist.
- Every run fails identically; that is a consistent configuration problem, not flakiness.

## Variant phrasings
- "npm ERR code ECONNRESET registry.npmjs.org"
- "npm install ECONNRESET retry"
- "npm ERR! network connection reset during install"
- "ECONNRESET npm ci transient failure"

## Why it happens
ECONNRESET means the TCP connection was reset by the peer mid-transfer: an overloaded registry endpoint, a flaky NAT gateway, or an aggressive middlebox timeout. npm's default retry budget is small, so a single reset aborts the whole install. Raising fetch-retries and the minimum backoff lets npm ride out the blip instead of failing.

## Edge cases
- Agents verifying upgrades should wrap installs in their own retry loop as well; npm-level retries cover one command, not a multi-step verification.
- fetch-retry-maxtimeout caps how long backoff waits; raise it too if resets cluster during incidents.
- Some networks flap between IPv6 and IPv4; if resets persist, testing with one family disabled can isolate it.
- Check the registry status page during widespread failures; no retry setting fixes a real outage.

## Provenance

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