RFC: ACP vs official @cursor/sdk for the Cursor integration #6

RFC: ACP vs official @cursor/sdk for the Cursor integration

I'd like to contribute toward replacing the current direct/private Cursor protocol integration with one of Cursor's documented integration surfaces.

My main goal is compliance with Cursor's Terms of Service and documented APIs/auth flows. I’d also like to keep the implementation reasonably consistent with @openchamber/opencode-claude.

I've already built and tested a private OpenCode 2.x implementation using Cursor ACP, and I've also investigated the official @cursor/sdk route. Before building a larger change, I'd like to understand which direction you would prefer.

ACP vs SDK

ACP

ACP has the strongest credential isolation: Cursor CLI owns authentication and the plugin never needs a Cursor API key.

It also exposes Cursor-native client behavior such as ask, explicit permission requests, plan/question interactions, and other ACP extensions.

The downside is considerably more integration code: child-process lifecycle, JSON-RPC/NDJSON handling, MCP bridging, capability negotiation, model discovery, and cleanup.

SDK

The SDK would be much closer to the architecture now used by opencode-claude:

OpenCode
  → local proxy
  → official vendor SDK
  → vendor service

It would also give us better model discovery, model variants, usage/cost data, persistent agents, and an in-process custom-tool bridge.

The main difference from Claude is authentication: Cursor's SDK is itself the authenticated client. I would keep that entirely SDK-owned — no custom OAuth, credential parsing/copying, token refresh logic, or private Cursor endpoints in the plugin.

One important security requirement would remain:

Cursor reasons; OpenCode controls execution.

For ACP, that is enforced through permission handling and the MCP bridge. For the SDK, I would avoid exposing Cursor's native shell/edit/write tools and expose OpenCode tools through SDK custom tools instead.

Useful pieces from the ACP implementation

Even if SDK is preferred, I think these ideas are worth carrying over:

• tests preventing accidental use of private Cursor APIs/protocols;
• fail-closed tool permissions;
• OpenCode as the sole tool execution authority;
• model refresh/caching and status diagnostics;
• OpenCode Plan → Cursor Plan synchronization;
• safe non-agentic handling of title/compaction/utility requests;
• secret redaction and conservative defaults around ambient Cursor configuration.

Question

Would you prefer the contribution to use:

1. ACP — stronger credential isolation and richer Cursor-native client semantics; or
2. @cursor/sdk — closer alignment with opencode-claude, less transport code, richer model/usage APIs, and simpler tool integration?

I do have a working private ACP reference implementation, but I'm not linking it here yet because it's still rough around the edges and hasn't been cleaned up for public review.

Either direction is practical from my side. I'd prefer to agree on the architecture before opening a large implementation PR.