Cursor SDK Bridge Opens Agent Control to Rust, Go, and More

Cursor is opening its agent runtime to more programming languages with an open-source SDK Bridge. In an approved post, Cursor engineer Eric Zakariasson said developers can now build Cursor agents in Rust, Go, or another language by writing a thin adapter that can keep pace as Cursor adds agent features. (Eric Zakariasson on X)

The durable Cursor SDK Bridge repository defines the bridge as a local server plus a stable sdk.v1 protobuf contract. That contract exposes the agent operations an adapter needs without requiring the adapter to depend directly on Cursor's TypeScript @cursor/sdk or Python cursor-sdk packages. (Cursor SDK Bridge on GitHub)

What the bridge changes

Cursor's official SDK already makes its production agent runtime programmable from TypeScript and Python. The bridge adds a language-neutral boundary for teams that want to build their own adapter, service integration, or one-off script in another ecosystem. (Cursor SDK public beta coverage)

The repository describes the basic shape:

• The bridge embeds Cursor's TypeScript SDK as a library.
• It runs as a small local server.
• It exposes the SDK surface over Connect and gRPC-Web using protobuf definitions.
• An adapter starts the bridge and communicates with it through the sdk.v1 contract.
• The bridge communicates with Cursor's API over HTTPS.

The result is not a second agent implementation in every language. It is a stable protocol boundary: language-specific code speaks to the local bridge, while the bridge keeps the Cursor SDK and API connection behind that boundary. (Cursor SDK Bridge on GitHub)

What adapters can control

The sdk.v1 contract covers the core agent workflow. Cursor lists support for:

• Creating and resuming agents.
• Sending messages and streaming runs.
• Reading artifacts and usage information.
• Working with Cursor identity, models, and repositories.
• Registering callbacks for custom tools.
• Registering callbacks for custom agent stores.
• Checking bridge version, health, and shutdown state.

That gives a Rust or Go service access to the same broad agent lifecycle as the official SDKs without making the service a TypeScript application. The exact generated client surface depends on the target language's protobuf and Connect tooling. (Cursor SDK Bridge protocol guide)

How to build an adapter

Cursor's repository recommends treating the protocol as a versioned dependency rather than copying an unpinned moving target. The documented workflow is:

1. Read the protocol guide.
2. Pin the adapter to the newest tagged vX.Y.Z release.
3. Copy the proto/sdk/v1/ definitions from that tag when working outside a repository checkout.
4. Generate code with protobuf tooling for the target language.
5. Implement a bridge manager, transport, authentication, and structured error handling.
6. Add client, agent, and run APIs around the generated service code.
7. Keep a runnable demo or test at each milestone.

The repository explicitly says not to edit the generated proto/ directory. Releases regenerate that content and keep the protocol aligned with the corresponding Cursor SDK versions. (Cursor SDK Bridge on GitHub)

A minimal adapter needs a few runtime pieces:

The repository includes examples and a protocol guide, but it does not present a turnkey official SDK for every language. Teams still need to generate the client, manage the bridge process, and integrate the resulting handles into their own application. (Cursor SDK Bridge examples)

Bridge startup and authentication

The bridge can be bundled, downloaded as a platform archive, or located through an environment override such as CURSOR_SDK_BRIDGE_BIN. Cursor lists archives for Linux, macOS, and Windows combinations and says the same bridge is embedded in the Python SDK wheels. (Cursor SDK Bridge on GitHub)

When an adapter starts the bridge, the repository says it should capture standard error, wait for the cursor-sdk-bridge ready handshake, validate the schema, transport, and protocol fields, and read the bearer token from the reported token-file path. The raw discovery line should not be logged because older bridge versions may include the token inline. (Cursor SDK Bridge protocol guide)

A real agent turn also needs a Cursor API key. Cursor says the key must be present in the bridge environment and passed explicitly in the agent options or per-call request; the environment variable alone is not a reliable substitute for the explicit option across all operations and bridge builds. Local agents additionally require an explicit model, and model catalog calls require a per-call API key. (Cursor SDK Bridge on GitHub)

Constraints to plan around

The bridge is designed for adapters that can use protobuf and an HTTP/1.1 client. Cursor says classic gRPC will not work because the bridge serves HTTP/1.1 only. Requests use Connect-style HTTP POST endpoints and must carry a bearer token for both unary and streaming calls. (Cursor SDK Bridge on GitHub)

Streaming also has lifecycle details worth handling before production use. The repository says a dropped stream does not cancel the underlying run, but live Send offsets and ObserveRun offsets use different numbering. Keepalive frames must be ignored, and an adapter should preserve the terminal result so it can resume observation when a connection drops. (Cursor SDK Bridge protocol guide)

The bridge itself should be shut down when the client closes or the host process exits. Cursor recommends attempting the control-service shutdown or sending SIGTERM, waiting briefly, and killing the process only if it has not exited. That cleanup matters for services that create many short-lived local bridge processes. (Cursor SDK Bridge on GitHub)

Who should use it

The SDK Bridge is most useful when a team already has a service or automation layer in Rust, Go, Java, or another language and wants to add Cursor agents without introducing a TypeScript sidecar for every call. It also creates a path for language-specific integrations that need a stable wire contract and generated clients.

TypeScript and Python developers should start with Cursor's official SDK packages instead. The bridge repository explicitly directs those users to @cursor/sdk on npm and cursor-sdk on PyPI, so the bridge is primarily a compatibility boundary for other languages and service architectures. (Cursor SDK Bridge on GitHub)

For a first integration, keep the scope narrow: pin a protocol tag, run one local agent against a test workspace, consume a complete streamed run, and verify shutdown behavior before adding custom tools, stores, or a long-lived service wrapper. The repository's protocol and examples are the source of truth for the generated client and handshake details. (Cursor SDK Bridge protocol guide)

Bottom line

Cursor's open-source SDK Bridge gives non-TypeScript and non-Python applications a supported path into Cursor agents. Its stable sdk.v1 protocol covers agent lifecycle, streaming, artifacts, custom callbacks, and control operations, while the local bridge handles the Cursor SDK and API connection. The trade-off is that teams must own adapter generation, process lifecycle, authentication, and Connect-over-HTTP/1.1 details rather than receiving a turnkey package for every language. (Cursor SDK Bridge on GitHub)

Sources

• Eric Zakariasson, “You can now build Cursor agents in Rust, Go, or any other language!”, August 5, 2026: https://x.com/ericzakariasson/status/2085033378865451213
• Cursor, sdk-bridge repository: https://github.com/cursor/sdk-bridge
• Cursor SDK Bridge protocol guide: https://github.com/cursor/sdk-bridge/tree/main/docs
• Cursor SDK Bridge examples: https://github.com/cursor/sdk-bridge/tree/main/examples