- name
- add-cursor
- description
- Use Cursor (local Agent SDK) as a full agent provider — planning, tool orchestration, MCP tools, session resume — alongside or instead of Claude. Cursor-account sign-in or API key, held by the credential gateway. Per-group via `ncl groups config update --provider cursor`. Distinct from using Cursor as a cloud agent (those run on Cursor VMs and are not this provider).
- metadata
- nanoclaw-provider: cursor nanoclaw-provider-label: Cursor nanoclaw-provider-hint: Cursor — account sign-in or API key nanoclaw-provider-offered: 'true' nanoclaw-provider-image: local-required
Cursor agent provider
Shortcut:
pnpm exec tsx setup/index.ts --step provider-auth cursorperforms this whole install (payload files, barrels, SDK pin, image rebuild) plus auth in one command. The steps below are the same operations, for agent-driven or manual application.
NanoClaw selects each group's agent backend from container_configs.provider (default claude). This skill installs the Cursor provider: copy the payload from this skill's payload/, append one import to each of the five provider and contract barrels, pin @cursor/sdk in the agent-runner tree, rebuild, then run the auth walk-through.
The provider runs @cursor/sdk in-process inside the container (Agent.create / resume / send): native streaming, MCP tools, a local agent store (the continuation is a Cursor agentId). It integrates through the provider contracts only — a data-only host contract declares the composed AGENTS.md, the per-group .cursor-shared state volume at ~/.cursor, the two Cursor-native skill directories and the Cursor model domains; the runtime contract declares the execution stance, model mapping, memory hooks, MCP mapping, and archives each exchange into conversations/ through core's shared exchange archive.
Credentials stay in the credential gateway selected by NANOCLAW_GATEWAY_PROVIDER. The container only ever sees the placeholder CURSOR_API_KEY=cursor_placeholder_nanoclaw, which the SDK sends as a bearer header. Setup stores the key for two exact routes: api2.cursor.sh/auth/exchange_user_api_key, where the SDK swaps it for a short-lived runtime token, and api.cursor.com/v1/models, for model discovery. The runtime token stays in the SDK's memory and rides the same gateway proxy on the agent's Connect RPCs to api2.cursor.sh, which the gateway leaves untouched because the key is scoped to the exchange path. The payload ships cursor.gateway-proxy.test.ts, which proves every request of a real SDK run transits the proxy carrying nothing but the placeholder. Never put a key in chat.
The mechanical steps under Install carry nc: directive fences: an agent reads the prose and applies them, and a parser can apply them deterministically from the same document. Every directive is idempotent, so the whole skill is safe to re-run; anything a parser can't apply falls back to the prose beside it.