"npm ERR! code ECONNRESET" — registry connection reset during the agent's upgrade verification — how to fix

Not specified by the original author.

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.

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

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

Thread query: "npm ERR! code ECONNRESET" - registry connection reset during the agent's upgrade verification - how to fix

TL;DR:

Not specified by the original author.

TL;DR: Back off and retry on the 429; the registry is asking for patience, not refusing the request. Read the Retry-After hint, wait with exponential backoff and jitter, then resume the verification step where it left off. Giving up on the first 429 turns routine rate limiting into a failed upgrade.

agent hit a 429 from the npm registry mid-verification and gave up instead of backing off

1. Read the Retry-After value from the 429 response. Expected: the exact wait the registry asks for, no guessing.

2. Wait with exponential backoff plus jitter before the next request. Expected: retries stop clustering together and stop earning further 429s.

3. Resume the verification step from where it stopped instead of restarting it from scratch. Expected: completed work is not redone, which means fewer requests overall.

4. Reduce request volume going forward: cache tarballs and metadata between verification runs. Expected: fewer requests per verification, fewer 429s in the first place.

Use this when

• The npm registry returned 429 during upgrade verification
• The agent gave up on rate limiting with no retry
• "Gave up instead of backing off" describes the agent's behavior
• Verification failed with "too many requests"

Not for this skill when

• The registry returns 403 (an auth problem, not rate limiting)
• The registry returns 5xx errors (different retry policy, usually shorter backoff)
• The 429 came from the GitHub API rather than the npm registry (different quota model)

Variant phrasings

• npm 429 with no backoff
• rate limited, agent gave up verification
• npm registry too many requests, agent quit
• 429 mid-verification with no retry

Why it happens

The agent treated 429 like a permanent failure. Registries rate-limit aggressively during bulk verification, and 429 is explicitly a "slow down" signal with a built-in resume mechanism (Retry-After) that the agent ignored. The registry was cooperating; the agent was not listening.

Edge cases

• Without a Retry-After header, start with a short wait and double it each attempt.
• Cap total retry time so one throttled PR cannot stall the whole verification queue all day.
• If many agents share one egress IP, coordinate their verification schedules or they will throttle each other.

Provenance

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

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

Thread query: agent hit a 429 from the npm registry mid-verification and gave up instead of backing off and retrying

TL;DR:

Not specified by the original author.

TL;DR

EAI_AGAIN is a DNS resolution failure: npm could not resolve the registry hostname. In CI this is almost always transient infrastructure flakiness (the runner's DNS, a brief network blip) rather than your code. The fix stack: retry with backoff, pin a reliable DNS setup on self-hosted runners, and consider a registry mirror if it recurs. Do not change your package.json to fix it.

The query

how to debug npm ERR! code EAI_AGAIN in CI

Use this when

• npm install fails in CI with code EAI_AGAIN
• Failures are intermittent and retrying helps
• Local installs work fine
• Failures cluster around certain times or runners

Not for when

• npm authentication errors (ENEEDAUTH, 401/403)
• Corrupt cache or lockfile issues
• Registry outages (those give 500s, not DNS errors)

Steps

Step 1: Confirm it is transient, not permanent

Check whether rerunning the job succeeds. EAIAGAIN that clears on retry is infrastructure flakiness; EAIAGAIN that fails every time on one runner is that runner's DNS configuration. Expected output: classified as intermittent (most common) or persistent on specific runners.

Step 2: Add retry logic to the install step

Wrap npm install in a retry with backoff (a few attempts, growing delays). For transient DNS blips this turns red builds green with no other changes. Most CI systems have a retry mechanism or you can script a simple loop. Expected output: transient failures stop failing the build.

Step 3: Check the runner's DNS configuration

On self-hosted runners, inspect the DNS resolver setup: misconfigured or overloaded resolvers cause EAI_AGAIN under load. Point at a reliable resolver and verify resolution of the registry hostname directly from the runner. Expected output: the registry hostname resolves consistently from the runner.

Step 4: Reduce DNS dependence

Use npm's cache aggressively so installs rarely hit the network, and consider a local registry mirror or proxy for heavy CI usage. Fewer DNS lookups means fewer chances for DNS to fail. Expected output: installs succeed from cache most of the time; registry hits are the exception.

Step 5: Track frequency and escalate if it grows

Log EAI_AGAIN occurrences. Occasional blips are normal CI weather; a rising trend means the runner infrastructure or network path is degrading and needs attention from whoever runs it. Expected output: a trend line that justifies either handled by retries or an infrastructure ticket.

Provenance

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

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

Thread query: how to debug npm ERR! code EAI_AGAIN in CI

TL;DR: EAI_AGAIN is a DNS resolution failure: npm could not resolve the registry hostname. In CI this is almost always transient infrastructure flakiness (the runner's DNS, a brief network blip) rather than your code. The fix stack: retry with backoff, pin a reliable DNS setup on self-hosted runners, and consider a registry mirror if it recurs. Do not change your package.json to fix it.