SDK Agent.send streaming runs terminate RUNNING → ERROR with no diagnostic body (@cursor/sdk 1.0.22)

Support Bug Reports
1

Where does the bug appear (feature/product)?

Cursor SDK

Describe the Bug

Every agent.send() streaming run terminates with status=ERROR immediately after the initial RUNNING event. There are no intermediate content events (assistant_text_delta, thinking_delta, tool events, etc.), no error message on the run object, _result is null, and run.wait() resolves to:

{ "status": "error", "durationMs": ~24000–38000, "model": { "id": "..." } }

The failure is 100% deterministic across two API keys (a legacy key_... and a freshly created crsr_...), model-agnostic (default, composer-2.5, claude-opus-5, gpt-5.6 all fail identically), and client-agnostic (bare @cursor/sdk import in a 30-line Node script reproduces it — no framework involved).

Authentication and every REST endpoint work fine with the same keys. Only the SDK streaming stage fails. Cursor IDE (browser-session auth on the same account) works normally for all these models.

Steps to Reproduce

Minimal Node script (no framework, no wrappers):

// probe.mjs
import { Agent } from "@cursor/sdk";

const apiKey = process.env.CURSOR_API_KEY;
const agent = await Agent.create({
  apiKey,
  model: { id: "default" },        // also fails with composer-2.5, opus-5, gpt-5.x, ...
  local: {
    cwd: process.cwd(),
    force: true,
    settingSources: [],            // also fails with ["project"], ["project","user"]
  },
  name: "repro",
});

const run = await agent.send("Reply with only: pong");
for await (const ev of run.stream()) console.log(ev);
console.log(await run.wait());

Run:

node --version           # v22.23.2
npm ls @cursor/sdk       # @cursor/[email protected]
CURSOR_API_KEY=... node probe.mjs

Actual observed stream output (verbatim):

{ type: "status", status: "RUNNING" }   // t=0ms
{ type: "status", status: "ERROR"   }   // t=24560ms
FINAL status=error  _result=null  duration=34077ms

No content events between RUNNING and ERROR.

Combinations tested — all fail identically:

Variable Values tested
model.id default, composer-2.5, claude-opus-5-thinking-high, gpt-5.6-sol-high
local.cwd /tmp (empty), a real repo checkout with .cursorrules (42 rules loaded)
local.settingSources [], ["project"], ["project","user"]
local.force true, false
Network direct (proxy unset), via corporate HTTPS proxy
API key format legacy key_..., new crsr_... (both belong to the same account)

REST endpoints that DO work with the same keys:

  • GET /v0/me → HTTP 200 with correct account email
  • GET /v0/models → HTTP 200 returning 13 entitled model IDs (incl. default, composer-2.5, claude-opus-5-thinking-high, gpt-5.6-sol-high, etc.)
  • Agent.create({ ... }) succeeds every time and returns an agent id
  • agent.send(...) succeeds every time and returns a run id

Expected Behavior

run.stream() should emit content events (thinking_delta, assistant_text_delta, tool events, etc.) between the initial RUNNING and terminal SUCCEEDED states, and _result should contain the assistant reply. This is exactly what Cursor IDE (browser-session auth) produces for the same account and same models.

Instead we get only two events (RUNNING → ERROR), no diagnostic body, and _result=null.

Operating System

Linux

Version Information

SDK:
@cursor/sdk 1.0.22 (also reproduced on 1.0.20)

Runtime:
Node.js v22.23.2 on Linux (container)

For AI issues: which model did you use?

default, composer-2.5, claude-opus-5-thinking-high, gpt-5.6-sol-high — every model tested fails identically

For AI issues: add Request ID with privacy disabled

Failing run IDs (please pull server-side logs — client sees no diagnostic):

run-f5736435-ae8b-4b63-a085-00eb48674567 req d78a2fd1-0c0c-47af-b151-bef5a6e6f9d1 model=default
run-f9561232-5b9e-448f-b0f9-f01dcffacb4c req 6e82381f-b5ac-4995-8d6c-240dd4219006 model=composer-2.5
run-44999b47-522b-4f2a-96fc-0f30fdc45161 req 950d4866-67a5-41b6-b026-b48381120bf0 model=default
run-bd9adf83-5f0c-433a-969b-7991f8cbf984 req b245ed6b-a415-4473-a777-c23c39f70e3e model=default
run-13291128-c648-4bc6-8129-166e49f54816 req 5bd94fa6-54a9-414b-800f-a6dbaf6114bc model=composer-2.5
run-c4d5e539-c57e-44ec-9530-296289068fd0 req d82ff4ba-5105-4b30-b740-894407242921 model=default
run-60c19d01-65de-4d54-8416-c4c514aa2b9e (2-event stream captured verbatim in the reproduction section)
run-f5ade333-c599-43fc-836a-cae47a326b33 (freshest reproduction after key rotation) model=default

Additional Information

Both keys tested — same failure signature:

  • Key A: legacy key_... prefix (68 chars), 7 months old — fails.
  • Key B: new crsr_... prefix (69 chars), generated fresh during this probe — also fails immediately.

Account is an enterprise seat under a corporate org. All REST endpoints (/v0/me, /v0/models) return HTTP 200 with correct account and entitlement data using the same keys — so auth and entitlement are not the cause.

Requests:

  1. Are streaming SDK runs (Agent.send + run.stream/wait) blocked at the account or team policy level for this seat?
  2. Is there a separate SDK-run quota bucket that is exhausted for this account?
  3. Any account flag / pending review that would cause silent RUNNING → ERROR transitions?
  4. Please attach whatever server-side rejection reason is being suppressed for the run IDs above — the SDK client sees zero diagnostic.

Does this stop you from using Cursor

Yes - Cursor is unusable