Skip to main content
Continuum runs Cursor-backed sessions through the ACP (Agent Client Protocol) harness, driving the cursor-agent CLI in its acp mode.

​
Requirements

cursor-agent must be installed and your Cursor account must be authenticated.
  • Install — Continuum resolves cursor-agent on your PATH (it also accepts the legacy agent binary name). If it is missing, Settings → Providers → Cursor points you at the installer one-liner, curl https://cursor.com/install -fsS | bash.
  • Authenticate — sign in with cursor-agent login, set CURSOR_API_KEY, or rely on Cursor.app’s stored Keychain tokens. Continuum reads the cursor-access-token / cursor-refresh-token Keychain entries directly.
Cursor’s ACP handshake authenticates at session start, so “installed” on the Providers screen means the binary is on PATH — not proof of a live login. If the handshake needs auth, Continuum picks the cursor_login method Cursor advertises at initialize.

​
How it integrates

Continuum spawns cursor-agent acp and speaks ACP over the child’s stdio. The daemon projects Cursor’s event stream into the session’s chat store, so chat, tool runs, turn state, and permission prompts render exactly like the other harness backends (Codex, Grok, and Claude on its Agent SDK backend). The same daemon endpoints used for Claude and Codex handle send, interrupt, and model selection for Cursor sessions. Cursor sessions appear in the Code tab session list and the Usage tab quota panel.

​
Model discovery

Cursor’s visible model list is account-scoped, so Continuum doesn’t ship a fixed list. When the Mac can run cursor-agent, it live-probes your account’s models and renders them in the model picker. If the probe returns nothing, the picker falls back to a single Cursor default / Auto entry — the only model in the bundled catalog, deliberately, so Continuum never claims access to models your account may not expose. Cursor supports in-session model changes: the model is applied over ACP after initialize, so switching mid-session does not respawn the agent.
Cursor’s real binary lives under ~/.local/share/cursor-agent/versions/<rev>/cursor-agent, with ~/.local/bin/cursor-agent as a symlink. The sandboxed Release build is granted read-only access to that tree so the model probe can execute it; without it the picker shows only “Auto”.

​
No Plan mode, no effort dial

Cursor is the one provider with no read-only Plan mode. The composer’s Plan ↔ Code pill is omitted for Cursor sessions, and every Cursor session is normalized to Code at each session boundary. It also exposes no programmatic reasoning-effort control, so its catalog entries report no effort support and the effort dial is hidden. (The “Auto” you may see is the model “Cursor default / Auto”, not an effort level.)

​
File system access

File-system capability follows the permission pole. A Code session gets it: Continuum advertises fs/read_text_file and fs/write_text_file to the agent, bound to the repo root and session cwd. Plan and chat sessions advertise no file-system capability at all, and every file request from one is refused. Since Cursor has no Plan pole, its Code sessions always have it. Each path the agent asks for is validated the safe way — symlinks resolved, .. collapsed, and the canonical result required to sit at or under the repo root — which defeats traversal, absolute-path escape, and symlink escape. The check is TOCTOU-aware: Continuum opens the exact canonical path the gate returns, never re-resolving the agent-supplied string. Every authorized file operation is written to an audit log with a hashed path.
This used to be gated on a per-repo autopilot trust list. That list no longer gates Code permissions anywhere in the app; file-system capability now follows the Plan/Code pole directly.

​
Usage analytics

Cursor token events feed the Usage tab, and a quota panel surfaces your Cursor account’s current billing period. Continuum reads it by calling Cursor’s own dashboard endpoint (api2.cursor.sh/aiserver.v1.DashboardService/GetCurrentPeriodUsage) with the token from your Keychain, and renders the Total / Auto / API usage rows the Cursor web dashboard shows. Cursor’s billing period is its window — there’s no separate weekly meter to surface. The response schema is reverse-engineered and pinned by a fixture, so a Cursor backend change is caught early rather than silently zeroing the gauge.

​
Multiple accounts

Cursor has no documented config-root override, so additional accounts are keyed on an explicit API key (CURSOR_API_KEY) injected at spawn rather than a separate config directory. That’s enough to run a second account’s sessions safely, but not enough to separate their usage readings — the quota panel reports the account whose token is in the Keychain.

​
Broadcast

Cursor can participate in the Chat surface’s multi-provider broadcast mode — one prompt to several providers, answers side by side.
The Chat tab is hidden by default across every client while the product is focused on Code, so broadcast is not reachable from the default UI. See Chat.