Local agent shell tool: ECONNRESET in team repo blocklist check crashes the Node process

Support Bug Reports
, , ,
1

Where does the bug appear (feature/product)?

Cursor SDK

Describe the Bug

I run local agents with @cursor/sdk inside a long-lived Node server. A brief network drop reset every HTTP/2 session while an agent was starting a shell command, and my whole process exited. The error came from LocalShellStreamExecutor.execute → shouldEnforceShellInvariantBlocks → checkRepoBlocked → getTeamReposOrEmptyIfNotInTeam: ConnectError “[unknown] [aborted] read ECONNRESET”. It escaped as an unhandled rejection instead of failing that tool call or the run, so Node’s default handling killed every other agent in the process. The lookup appears to run before every shell command, so any transient network error during it is fatal.

Steps to Reproduce

  1. Node 22 with @cursor/sdk 1.0.31: create a local agent in a git repo and send a prompt that makes it run many shell commands one at a time (e.g. “run ls 20 times, one command per tool call”).
  2. While it runs, make outbound HTTPS reset: sudo iptables -I OUTPUT -p tcp --dport 443 -j REJECT --reject-with tcp-reset (undo with -D).
  3. The next shell tool call’s blocklist lookup rejects with ConnectError ECONNRESET and the process exits on an unhandled rejection, rather than the run reporting an error.

I hit this naturally; the iptables step is how I’d expect to force it. Frames: execute (esm/357.js:1:888513) → shouldEnforceShellInvariantBlocks (357.js:1:792084) → checkRepoBlocked (357.js:1:514996) → unary (esm/401.js:1:7655).

Expected Behavior

A failed blocklist lookup should fail only that shell tool call (or apply a fail-open/fail-closed policy) and surface through the run’s result. It should never escape as an unhandled rejection that terminates the host process.

Version Information

@cursor/sdk 1.0.31, Node v22.22.1, Linux (kernel 7.0), local runtime, model claude-opus-5-5

4

Hey, thanks for the detailed report and repro steps. That really helps.

This should be fixed in @cursor/sdk 1.0.34 current latest on npm. In this version, a lookup failure before a shell command shows up as an error for the specific tool call, instead of escaping as an unhandled rejection, so the host process and other agents keep running. It also adds stale-while-revalidate caching for team settings, so a transient network blip mid-run usually won’t fail the call at all.

Can you update (npm install @cursor/[email protected]) and run your iptables repro again? If the process still crashes, send the new stack trace and I’ll take another look.

If you can’t upgrade right now, as a temporary workaround you can add process.on("unhandledRejection", ...) in your host. That will stop Node from crashing the process.

6

Hey @deanrie ,

Thanks for the reply. It would also be nice if you guys would update the SDK changelog at SDK Changelog | Cursor Docs. I track that page to know when there are updates that I want to pull, but it’s still showing the latest as 1.0.31.

Thanks,

James

8

Good catch. The changelog page is actually behind what’s published on npm, latest there is already 1.0.34. I’ll let the team know so they can fix it.

Until the page is updated, the most reliable way to track releases is to check npm directly: npm view @cursor/sdk versions or npm view @cursor/sdk version for latest.

Let me know how 1.0.34 works on your iptables repro.