Cursor's Agent SDK vs Claude Agent SDK: Who Runs the Tools

On October 20, 2026, Cursor stopped being only a coding tool and became another vendor selling an agent SDK. The announcement is precise about some things and silent about others, and the silence is the story: Cursor tells you exactly where your agent’s code runs, and says almost nothing verifiable about who approves what that agent does. If your team is choosing between Cursor’s Agent SDK and Anthropic’s Claude Agent SDK, the deciding question is not whose demo looks better. It is where the control boundary sits: who executes the tools, who enforces permissions, where the sandbox runs, and what it costs to leave.

Here is the practical finding up front. On the evidence available today, Cursor offers the clearer self-hosted execution story, while the Claude side has the more independently documented permission machinery. That is an asymmetry of documentation, not a measured superiority ranking, and it should push you toward a verification step before standardizing, not toward a confident pick.

What Cursor shipped on October 20, and what the announcement does not specify

The release itself is well documented because it is a vendor primary source. “Today, we’re releasing the Agent SDK, the framework we use to build our own managed agents like Bugbot, Security Reviewer, and Rollouts,” Cursor’s announcement opens, adding that “the Agent SDK is generally available today.” Two things in that sentence matter for evaluation. First, this is the same plumbing Cursor uses for its own production agents, so the abstractions have at least one serious internal user. Second, it went GA the day it was announced, which usually means the surrounding documentation, especially the permission and sandbox surface, is thin relative to the marketing.

What the announcement does specify concretely:

• Authoring model. “Prompts are written in Markdown, while tools are defined as TypeScript functions. Because everything is code, changes can go through the same version control and review process as the rest of your software” (Cursor). Agent definitions are files in a repo, not configuration in a web UI.
• Deployment. “When you’re ready to put an agent into use, you can deploy it to Cursor by running agent-sdk deploy from the project directory. The command builds the agent, gives it a URL, and starts it on our infrastructure.” Secrets and integrations are managed from a dashboard.
• Self-hosting. “You can also run the agent on your own infrastructure. Each agent runs as a single Node process that can be packaged in a container.”
• Operations. Built-in evals and event replay, task handoff to specialized subagents with their own tools and sessions, parallel subagents, and triggers from pull-request events on GitHub, GitLab, or Bitbucket, all vendor-stated.
• Model default. The getting-started example configures composer-2.5 with effort and fast parameters. No other model appears in the SDK’s example text, though Cursor’s product page advertises a multi-vendor model menu at the product level.

What the announcement does not document as of October 29, 2026: permission callbacks, approval flows, sandbox internals, and what network, secret, and credential policy applies to tools executing inside either deployment mode. The announcement says a team within Cursor built a “kb-reviewer” agent in about a day, but that is an unedited vendor claim and tells you nothing about control semantics. Treat every Cursor capability below as vendor-stated until the reference documentation is independently checked.

Four questions that decide who runs the tools

The useful comparison frame comes from the control-stack literature rather than from either vendor. The Claude Code Complete User Handbook, a 208-page analysis verified against Claude Code 2.1.241 and re-verified against 2.1.246 in August 2026, states the taxonomy plainly: “instruction, permission enforcement, sandboxing and operating-system isolation are four distinct layers of a control stack, only two of which are enforced, and conflating them is the most common cause of loss of control.” The most common evaluation mistake, conflating an approval prompt with an enforced boundary, is exactly the mistake a feature-list comparison encourages.

So the four questions for any agent SDK, including these two:

1. Who executes the tool? Your process, your container, or the vendor’s infrastructure?
2. Who approves the action? A documented pipeline with auditable decisions, or a policy surface the vendor describes but you cannot inspect?
3. Where does isolation run? An optional sandbox, a container you control, or the vendor’s cloud environment?
4. What does exit cost? Can your agent definitions, tools, and governance policies survive a move to a different harness?

A related warning comes from work on permission manifests for web agents, which found one declarative permission mechanism “non-enforceable by design: it functions as a signaling and coordination tool rather than as an enforcement mechanism.” When either SDK’s docs describe a permission feature, the question to ask is which layer it enforces, not whether it exists.

Cursor’s control surface: vendor deploy versus the self-hosted Node container

Cursor answers question one more clearly than most. The execution locus is explicit and binary: agent-sdk deploy puts the agent on Cursor’s infrastructure behind a URL, or you run the same agent as a single Node process in a container you operate (Cursor). A single-process-in-a-container model is easy to reason about. You can put it in your own network segment, attach your own secrets manager, and apply your own egress policy. For teams whose compliance posture rules out vendor-hosted execution, this is the strongest concrete point in Cursor’s favor in the available evidence.

Questions two and three are where the announcement goes quiet. The announcement does not document an approval pipeline, a permission-decision event format, or sandbox semantics for tools running inside that Node process. This does not mean those mechanisms do not exist; it means they are not independently documentable from what was available as of October 29, 2026, nine days after launch.

There is also a category difference worth naming. A deploy-to-vendor SDK with a dashboard for secrets and integrations is a different commitment from a library you import into your own process. The dashboard is convenient and is also where operational state accumulates: secret bindings, integration credentials, deployment configuration. That state is part of your exit cost whether or not the agent code itself is portable.

The Claude side: a layered permission pipeline, documented by third parties

The Claude side’s control surface is better documented. The mechanics come from a source-level analysis of Claude Code, the product, not from Anthropic’s Agent SDK reference docs. That analysis describes “an ML-based classifier for automated approval, optional shell sandboxing, and session-scoped permission non-restoration, layering multiple mechanisms rather than relying on a single isolation boundary.” It also finds that Claude Code’s deny-first permission evaluation is internally auditable through session transcripts, and that the tool can export permission decision events, which is the property a security team actually needs to review what an agent was allowed to do.

The same paper makes the argument this whole comparison hangs on: “These details make the safety boundary an execution boundary, not only an approval prompt.” Notably, it reaches that conclusion partly by citing sandboxing reports that include Cursor’s own cloud-agent environment work on network policy, secret redaction, and credential management. Both vendors understand the execution-boundary problem. The difference in the available record is that one side’s machinery has been independently read at source level and the other’s has been announced.

Two hedges belong here. First, the handbook’s finding that only two of four control layers are enforced applies to the Claude stack: richer documented machinery is not the same as complete enforcement. Second, the analysis covers Claude Code; how much of that pipeline is exposed through the Claude Agent SDK’s own API surface is not established by this evidence.

What the OpenHands comparison adds: library-only versus execution-serving SDKs

The one independent feature comparison that names the Claude Agent SDK directly is the OpenHands software agent SDK paper, which assessed Claude Agent SDK v0.1.6, OpenAI Agents SDK v0.4.2, Google ADK v1.17.0, and LangChain v1.0.3 as of October 2025. That version pin matters: it predates Cursor’s SDK entirely, and any claim about current Claude Agent SDK versions should be treated as unverified here.

The paper’s structural observation is the useful part: “Unlike prior library-only SDKs (Anthropic, 2025a; OpenAI, 2024), OpenHands includes a built-in REST/WebSocket server for remote execution and a suite of interactive workspace interfaces for human inspection and control.” Library-only means the execution locus defaults to your process, which answers question one almost by construction, while pushing deployment, remote operation, and inspection onto you. Cursor’s SDK sits on the other branch: execution is served, either by Cursor or by a containerized process the SDK defines. Neither branch is wrong. They are different commitments about who operates the harness.

The same paper contributes the strongest piece of counter-evidence in this whole decision: “Optional isolation. The agent runs locally by default but can switch to a sandboxed environment when additional safety or resource control is required.” OpenHands arrived there the hard way; its earlier V0 assumed every tool call would run inside sandboxed Docker containers, diverging sandbox and agent states corrupted sessions, and V1 retreated to optional isolation. More sandboxing is not automatically better. When you read either vendor’s sandbox story, the question is not “is there a sandbox” but “what breaks when it is on.”

Side by side on the control axes

One row deserves skepticism on both sides. Vendor-run evals certify whatever the vendor’s harness measures, and an executable-contract audit of agent benchmarks found that “the benchmarks certifying them grade what each simulated tool call reports having done, assuming the tool did what its interface advertises.” Built-in evals are useful for regression tracking. They are not evidence that tools behave as advertised in your environment.

The migration-cost worksheet

For a team already wired to one vendor’s harness, switching costs are concrete. Price them in this order:

1. Agent definitions. Cursor’s everything-as-code model (prompts as Markdown, tools as TypeScript functions in version control) is genuinely helpful here: definitions in a repo can be diffed, reviewed, and moved. A library-based Claude integration lives in your codebase already. Score both well, but check how much behavior lives in SDK-specific primitives versus plain functions.
2. Tool surface. This is where exits go to die. A useful rubric comes from Tool Forge, which argues a production tool should be “a capsule: a composition of intent, capability contract, implementation, dependency policy, tests, documentation, runtime validation evidence, lifecycle state, credential bindings, and routing metadata.” Whichever SDK you pick, the more of that capsule lives in portable form (contracts, tests, credential bindings you control) rather than in SDK-specific decorators, the cheaper your exit. MCP-based tools travel better than SDK-native function tools, which is one reason MCP’s de facto standard status matters to this decision.
3. Operational state. Secrets in a vendor dashboard, deployment URLs, event-replay history, eval suites, and permission event logs all have to be exported, rebuilt, or abandoned. List them explicitly before you standardize; they never appear in the getting-started guide.
4. Governance coupling. The cleanest mitigation comes from Agentic Configuration Management: keep “governance policies… formulated over a stable configuration representation rather than being coupled to framework-specific execution abstractions.” In practice: your approval rules, capability grants, and audit requirements should exist as documents and policy files your org owns, with the SDK as one consumer, not as the system of record.

None of this is exotic. It is the same discipline as treating a database schema as yours even when a managed service runs it, applied to a younger and less standardized layer. And the layer is young: as one agent platform paper put it, “the field lacks standardized tools for development, deployment, distribution and discovery of agents.” That gap is precisely what the vendor SDKs are moving to fill, on their own terms.

Model access and vendor risk

Cursor’s product page advertises a choice of models from OpenAI, Anthropic, Gemini, SpaceXAI, and Cursor, but that is a product-level claim; the SDK announcement shows only composer-2.5. Whether the SDK exposes the full menu is not established by the available evidence, and if your architecture depends on model routing, that is a question for the docs, not an assumption.

What I would do before standardizing

Decide on the control boundary, not the demo. Concretely:

• If vendor-hosted execution is disqualified by your compliance posture, Cursor’s self-hosted single-Node-container path is the clearest documented option in this evidence set, with the caveat that its permission and sandbox semantics need verification in the reference docs before you trust them.
• If auditable permission enforcement is the binding constraint, the Claude side currently has the deeper independently documented surface (ML-classifier approvals, deny-first evaluation, exportable decision events), but confirm how much of it the Agent SDK, as distinct from Claude Code, actually exposes, and against a current version rather than the October 2025 v0.1.6 pin.
• In both cases, write down answers to the four questions (who executes, who approves, where isolation runs, what exit costs) from each vendor’s current SDK documentation, keep agent definitions and governance policy in version control under your ownership, and treat built-in eval scores as regression signals rather than behavioral proof.

The honest limitation of this comparison is that it is asymmetric by necessity. Every Cursor capability cited here is vendor-stated from a single nine-day-old announcement; every Claude capability is independently documented but sourced from analysis of the Claude Code product and a comparison frozen at v0.1.6. The verdict this evidence supports is conditional, and it stays conditional until someone reads both SDKs’ current docs side by side. What is not conditional is the broader shift: agent plumbing is moving from bespoke harness code into vendor SDKs, which lowers the cost of a first agent while pushing the hard problems, permissions, isolation, and exit, into territory the vendor now owns. Choose the vendor whose answers to those four questions you can verify, and keep your own copy of the answers.

Frequently Asked Questions

How does Cursor’s Agent SDK handle self-hosted deployment?

You can also run the agent on your own infrastructure. Each agent runs as a single Node process that can be packaged in a container.

What permission enforcement mechanisms are documented for the Claude side?

The mechanics come from a source-level analysis of Claude Code, the product, not from Anthropic’s Agent SDK reference docs. That analysis describes “an ML-based classifier for automated approval, optional shell sandboxing, and session-scoped permission non-restoration, layering multiple mechanisms rather than relying on a single isolation boundary.” It also finds that Claude Code’s deny-first permission evaluation is internally auditable through session transcripts, and that the tool can export permission decision events, which is the property a security team actually needs to review what an agent was allowed to do.

What is the primary difference between library-only SDKs and execution-serving SDKs?

Library-only means the execution locus defaults to your process, which answers question one almost by construction, while pushing deployment, remote operation, and inspection onto you. Cursor’s SDK sits on the other branch: execution is served, either by Cursor or by a containerized process the SDK defines.