Local Cursor SDK agents fail with opaque RUNNING -> ERROR on local repos

Where does the bug appear (feature/product)?

Somewhere else…

Describe the Bug

Cursor SDK local agents fail inside Agent.send(). Agent.create() succeeds, but when send(“hi”) is called on a local repo, the run only emits RUNNING and then ERROR. No assistant message is produced,
onDelta/onStep never fire, and run.wait() returns a generic error result with no useful payload.

Steps to Reproduce

`1. Set CURSOR_API_KEY and CURSOR_USE_HTTP1=1 in the environment.
2. Run a minimal local SDK script:
const agent = await Agent.create({ apiKey: process.env.CURSOR_API_KEY, model: { id: “gpt-5.3-codex” }, local: { cwd: “/Users/ankurtayal/workspace/cns/cursor-sdk-poc” } });
const run = await agent.send(“hi”);
for await (const event of run.stream()) console.log(event);
console.log(await run.wait());
error detail.

Expected Behavior

Agent.send() should start a local run and produce either assistant output or a structured error that explains why execution failed. The run should not go straight from RUNNING to ERROR with an empty
conversation, no onDelta/onStep events, and no actionable error detail.

Operating System

MacOS

Version Information

About Cursor CLI

CLI Version 2026.05.09-0afadcc
Model Auto
Subscription Tier Enterprise
OS darwin (arm64)
Terminal apple-terminal
Shell zsh

bun.lock
@cursor/sdk”: “1.0.12”,
Tested with bun - Bun 1.3.14
Tested with - Node v24.10.0

For AI issues: which model did you use?

gpt-5.3-codex
also tested: composer-2, gpt-5.5, claude-sonnet-4-6, gemini-3.1-pro

For AI issues: add Request ID with privacy disabled

agent.platform.listRuns: {
items: [
DetachedStoreRun {
id: ‘run-fee6a295-4be1-4f3a-98d3-9a44aa3d2cdd’,
agentId: ‘agent-044e4e27-a9bb-4a44-8e6c-333f0cb2510f’,
currentStatus: ‘error’,
result: undefined,
durationMs: 5212,
streamFactory: [Function (anonymous)],
git: undefined,
createdAt: 1778734573481,
model: {
id: ‘gpt-5.3-codex’
}
}
],
nextCursor: undefined
}

Does this stop you from using Cursor

Yes - Cursor is unusable

I’m seeing a similar intermittent issue with local Cursor SDK agents.

In my case it is not deterministic and not tied to the first run. It can happen after several successful turns.

Observed pattern:

- `agent.send()` succeeds and returns a run.

- Run starts as `running`.

- It transitions to `error` shortly after.

- `run.wait()` returns `status: “error”` with empty `result`.

- No `onDelta` or `onStep` events fire.

Example failed run:

- SDK: `@cursor/[email protected]`

- Model: `claude-opus-4-7`

- Params: `thinking=true`, `context=300k`, `effort=high`

- Agent ID: `agent-e94d4da6-1069-4d54-88d0-2b7c41901c95`

- Run ID: `run-5be3bb29-2fc4-4a28-a99d-c492f3cd252c`

This is a known bug. The SDK’s local agent streaming currently requires HTTP/2 to function, and the CURSOR_USE_HTTP1=1 environment variable you’re setting forces an HTTP/1.1 transport that can’t support the bidirectional streaming the SDK needs. That’s why Agent.create() and other non-streaming calls succeed but agent.send() fails immediately with an empty error.

Our team is actively working on adding HTTP/1.1 fallback support to the SDK (the same fallback the CLI already has). In the meantime, a few options_

  1. Remove CURSOR_USE_HTTP1=1 if your network supports HTTP/2 directly. The SDK works fine over HTTP/2.

  2. Use the Cursor CLI instead, which already supports HTTP/1.1 via a fallback transport. Set "useHttp1ForAgent": true in ~/.cursor/cli-config.json.

  3. Use the Cloud Agents REST API which uses standard HTTPS and doesn’t require HTTP/2 bidirectional streaming.

  4. Ask your IT team if they can allow HTTP/2 for Cursor’s API endpoints specifically (*.cursor.sh).

For reference: Cursor SDK docs

Your issue looks different from the one reported here. You’re seeing intermittent failures after several successful turns (not deterministic failures on every run), and you’re not using the HTTP/1.1 flag. Could you create a new thread with the following details so our team can investigate your specific issue properly?

  1. Whether CURSOR_USE_HTTP1 or any proxy-related environment variables are set

  2. Your OS and Cursor CLI version (cursor --version)

  3. A minimal code snippet that reproduces the intermittent failure

  4. Whether this happens with other models besides claude-opus-4-7

  5. The run ID you shared (run-5be3bb29-2fc4-4a28-a99d-c492f3cd252c) is helpful — we can trace it server-side

I was using bun 1.3.14 and http/2 was not supported so had to fallback on Https/1. Please check if this suggestion is applicable to bun as well.
Checked with nodejs and working fine with http/2
Thanks for workaround.

This is the issue on bun 1.3.14 and http/2
Some test/script is working fine with nodejs but failing on bun

/

/ Fetch requests can only be canceled with an AbortController.

           // We detect that condition by looking at the name of the raised

           // error object, and translate to the appropriate status code.

              return new ConnectError(reason.message, Code.Canceled);

            }

71 |             return new ConnectError(reason.message, code, undefined, undefined, reason);

                    **^**

ConnectError: [internal] Stream closed with error code NGHTTP2_FRAME_SIZE_ERROR

rawMessage: “Stream closed with error code NGHTTP2_FRAME_SIZE_ERROR”,

   code: 13,

metadata: Headers {},

details: \[\],

  at ***from*** (node_modules/.bun/@[email protected]+04b61edcd3bd2530/node_modules/@connectrpc/connect/dist/esm/connect-error.js:71:20)

  at ***connectErrorFromNodeReason*** (node_modules/.bun/@[email protected]+282c3e156e5c7d8f/node_modules/@connectrpc/connect-node/dist/esm/node-error.js:52:29)

  at ***reject*** (/node_modules/.bun/@[email protected]+282c3e156e5c7d8f/node_modules/@connectrpc/connect-node/dist/esm/node-universal-client.js:293:63)

  at ***h2StreamError*** (/Users/ankurtayal/workspace/pi-agentic/devreactor/node_modules/.bun/@[email protected]+282c3e156e5c7d8f/node_modules/@connectrpc/connect-node/dist/esm/node-universal-client.js:182:22)

  at ***emitError*** (node:events:43:23)

  at ***emitErrorNT*** (internal:streams/destroy:88:12)

  at ***emitErrorCloseNT*** (internal:streams/destroy:69:14)

error: Stream closed with error code NGHTTP2_FRAME_SIZE_ERROR

code: “ERR_HTTP2_STREAM_ERROR”

  at unknown:1:1

  at emitStreamErrorNT (node:http2:1955:47)

  at processTicksAndRejections (native:7:39)

Glad Node.js is working for you! The NGHTTP2_FRAME_SIZE_ERROR you’re seeing is a known limitation in Bun’s HTTP/2 client — it doesn’t fully support bidirectional streaming the way Node.js does, and that’s exactly what the SDK uses for local agent runs.

For now, Node.js is the supported runtime for the Cursor SDK. The HTTP/1.1 fallback our team is working on (which will remove the HTTP/2 requirement entirely) will also resolve the Bun compatibility issue once shipped. Until then, running your SDK scripts with Node.js is the way to go.