Cursor SDK in Public Beta

New in Cursor! · Blog · Docs


We’re excited to introduce the Cursor SDK, a TypeScript interface to create agents from your own code.

Install @cursor/sdk and create agents with a few lines of TypeScript. The same agents that power the desktop app, CLI, and web app are now available programmatically:

import { Agent } from "@cursor/sdk";
const agent = await Agent.create({
  apiKey: process.env.CURSOR_API_KEY!,
  model: { id: "composer-2" },
  local: { cwd: process.cwd() },
});

const run = await agent.send("Summarize what this repository does");
for await (const event of run.stream()) {
  console.log(event);
}

Agents get the full Cursor harness (codebase indexing, semantic search, MCP servers, skills, hooks, and subagents) whether running locally or on Cursor’s cloud. Cloud agents run on dedicated VMs with sandboxing, and keep going when your laptop sleeps or your network drops.

The SDK supports every model available in Cursor, including Composer 2.

Run npm install @cursor/sdk to get started, and use the Cursor SDK plugin so Cursor can help you build. We’ve also published sample projects you can fork and extend. Read more in the blog post and docs!

We’d love your feedback!

  • What are you building (or planning to build) with the Cursor SDK?
  • How’s the local vs. cloud runtime working for your use case?
  • What additional SDK features or language support would be most useful?

If you’ve found a bug, please post it in Bug Reports instead, so we can track and address it properly, but also feel free to drop a link to it in this thread for visibility.

Any plans for an MCP server for the agents api?

a Python sdk would be great too!

Is there a way to get the model that a thread is assigned to? The list endpoint doesn’t seem to return it and neither does it exist in the stream.

No specific plans!

Coming next!

There’s currently no way to retrieve the model a thread/run used after the fact. Will flag this for the team!

I already built one actually, since I was unaware cursor had plans for this. It’s tested and working perfectly. Will likely be releasing it in a day or two to github and pypi.

If you’d like I can post you an update here when I do. Not sure how long it will take cursor to finish theirs.

The python wrapper is now live, for anyone who’s needing a solution for this right now.

You can check it out at:

Be sure to let me know if you run into any issues with it!

Hey Colin & team, quick report from someone wiring the SDK into a downstream tool.

We’re adding @cursor/sdk as a harness in OpenProse, an open-source CLI that runs multi-agent Markdown programs through coding-agent SDKs. Cursor support is in PR #64. Really happy to see a public SDK where the local-mode + settingSources story made the integration clean.

One snag worth flagging: a fresh install of @cursor/[email protected] on Node 22 fails npm audit --omit=dev with 10 vulnerabilities (2 low, 1 moderate, 7 high). All of them trace back to two direct deps:

  1. sqlite3@^5.1.7node-gyp@<=10.3.1 → vulnerable make-fetch-happen, http-proxy-agent, @tootallnate/once, tar, cacache. The sqlite3@5 transitive tree is frozen, so all six advisories are marked “no fix available.” Bumping to sqlite3@^6.0.1 drops node-gyp from the runtime tree entirely and pulls a clean tar.

  2. @connectrpc/connect-node@^1.6.1undici <=6.23.0 (5 high-severity advisories). Bumping to @connectrpc/connect-node@^2.1.1 clears them.

Repro:

npm init -y
npm install @cursor/[email protected]
npm audit --omit=dev   # exits 1, 10 vulns

I tested both bumps locally via npm overrides and audit goes clean (0 vulnerabilities) with no behavior changes we noticed.

Thanks again for putting the SDK out!

@jfmontesdeoca Appreciate the detailed write-up and glad the SDK integration story has been smooth!

We perform reachability analysis to determine which CVEs are actually exploitable under the conditions in which we use a given package, and patch when warranted.

Hi there, just sharing some context. I’ve integrated @cursor/sdk into Helmor, a Tauri desktop app, and use bun build --compile to ship a single binary as a sidecar inside the .app.

The problem is that @cursor/sdk depends on sqlite3, which is a .node native addon, and dlopen() needs a real filesystem inode, it can’t load from any compile-to-binary tool’s virtual FS. I worked around it with a bun:sqlite-backed shim injected via a bun build plugin.

The workaround isn’t exactly elegant and is fragile across SDK upgrades. Is there any plan to migrate to a more modern integration, like node:sqlite or better-sqlite3? It would make single-binary desktop builds way easier.

Thanks @facecw for sharing! Spoke with the team, and custom stores is something we want to implement to solve for this.

Any plans for preview urls for the cloud agents that are active to expose ports? We have our own cloud agents that are powered by Daytona sandboxes and preview urls are the only thing missing to get us to migrate entirely over to Cursor Cloud Agents