429 too many requests with clean npm install on free plan

[CodeWithOz]

I got rate-limited for trying to use the cli to install all packages from my package.json:

⠏ Looking up data for 760 packages(node:67363) MaxListenersExceededWarning: Possible EventTarget memory leak detected. 31 abort listeners added to [AbortSignal]. MaxListeners is 30. Use events.setMaxListeners() to increase limit
(Use `node --trace-warnings ...` to show where the warning was created)
⠹ npm error Socket API POST request failed (429): Too Many Requests
npm error A complete log of this run can be found in: /path/to/.npm/_logs/2025-11-28T13_17_29_504Z-debug-0.log

Seems very unusual that such a basic npm feature doesn't work. I'm on a free plan, could that be it?

[jdalton]

Hi Uche Ozoemena (@CodeWithOz). It could be a variety of things What command were you using, (socket npm install?)

[CodeWithOz]

Yes exactly that's the command I ran.

[kamranayub]

It is frustrating since otherwise the Free plan is pretty generous. But, for example, I get the same thing trying to run socket npm install (this is for about 20 packages).

3514 verbose stack Error: Socket API POST request failed (429): Too Many Requests
3514 verbose stack     at Object.getAlertsMapFromPurls (C:\Users\subka\AppData\Roaming\fnm\node-versions\v24.11.1\installation\node_modules\socket\dist\utils.js:6837:17)
3514 verbose stack     at process.processTicksAndRejections (node:internal/process/task_queues:103:5)
3514 verbose stack     at async getAlertsMapFromArborist (C:\Users\subka\AppData\Roaming\fnm\node-versions\v24.11.1\installation\node_modules\socket\dist\shadow-npm-inject.js:82:10)
3514 verbose stack     at async SafeArborist.reify (C:\Users\subka\AppData\Roaming\fnm\node-versions\v24.11.1\installation\node_modules\socket\dist\shadow-npm-inject.js:251:23)
3514 verbose stack     at async Install.exec (C:\Users\subka\AppData\Roaming\fnm\node-versions\v24.11.1\installation\node_modules\npm\lib\commands\install.js:150:5)
3514 verbose stack     at async Npm.exec (C:\Users\subka\AppData\Roaming\fnm\node-versions\v24.11.1\installation\node_modules\npm\lib\npm.js:208:9)
3514 verbose stack     at async module.exports (C:\Users\subka\AppData\Roaming\fnm\node-versions\v24.11.1\installation\node_modules\npm\lib\cli\entry.js:67:5)
3515 error Socket API POST request failed (429): Too Many Requests

I also see this if I try a few times:

 Looking up data for 591 packages(node:272900) MaxListenersExceededWarning: Possible EventTarget memory leak detected. 31 abort listeners added to [AbortSignal]. MaxListeners is 30. Use events.setMaxListeners() to increase limit
(Use `node --trace-warnings ...` to show where the warning was created)

Besides this 429 issue (which I've hit multiple times), the main limitation I have with the Free plan is being limited to 1,000 dependencies, whereas the next step up for $300/yr is 1MM dependencies. Either the free limit should be increased so it's not a 100X multiplier (e.g. 10k dependencies) or there should be a Solo/Individual plan that's in-between Free and Team (because I don't have a team so there's no value there, but I'm still willing to pay for being able to scan more dependencies).

[kamranayub]

Just want to follow-up again: this is easily reproducible at least on my machine with many repos. Just today I cloned modelcontextprotocol/inspector and tried once more to do npx socket npm install and it failed.

I think this really prevents people from reaching the time to value with Socket and should be addressed, especially if it's not intentional. We want to be able to safely install dependencies but Socket is not usable like this.

This is on Windows 11 with Node 22.22.0.

Workaround

As a workaround, I tested Socket Firewall and that seems to work nicely so I'll use that instead for npm installs.

[jdalton]

Diagnosed. The CLI sends every package in one go: getAlertsMapFromPurls hands the whole purl list to the SDK's batchPackageStream, and we pass neither of its throttling options, so it defaults to 10 concurrent POSTs of up to 1024 purls each — that is what the MaxListenersExceededWarning about 31 abort listeners is showing you. There is also no retry on a 429 anywhere in that path, so the first rate-limited chunk aborts the whole install with the raw API message instead of backing off and continuing. The fix is backoff that honors Retry-After around each chunk plus a lower default concurrency, which I'm writing up; the separate question of the free-plan dependency quota is a plan decision rather than a CLI bug.