Skip to main content

​
Cursor Provider

CCS now treats Cursor as a first-class CLIProxy OAuth provider. Use this page for the current ccs cursor auth and account-management flow.
The older local Cursor daemon bridge is still available only as deprecated compatibility under ccs legacy cursor. Do not use the old ccs cursor auth/status/start/... examples from earlier docs for new setups.

​
Quick Start

# Authenticate the current provider path
ccs cursor --auth

# Inspect accounts
ccs cursor --accounts

# Open provider config flow
ccs cursor --config

# Run a task through Cursor's CLIProxy route
ccs cursor "review this diff"

​
Authentication Model

Cursor uses a browser-driven polling flow through CLIProxyAPIPlus:
  • no local callback port is required
  • CCS opens the upstream Cursor login page and polls for completion
  • token refresh is delegated to CLIProxy

​
Backend Requirement

Cursor is a plus-only provider. 
cliproxy:
  backend: plus
If you force --backend original, Cursor auth will not be available.

​
Config And Storage

Cursor is the only CLIProxy provider that stores its provider settings in a dedicated namespace so it does not collide with the deprecated local bridge files:
PathPurpose
~/.ccs/cliproxy/auth/shared OAuth token directory
~/.ccs/cliproxy/providers/cursor.settings.jsoncurrent Cursor provider settings
~/.ccs/cursor.settings.jsondeprecated local Cursor IDE bridge settings

​
Commands You Will Actually Use

ccs cursor --auth
ccs cursor --accounts
ccs cursor --use <account>
ccs cursor --nickname <name>
ccs cursor --config
ccs cursor --logout

​
Current Scope

CCS documents Cursor here as a provider-auth and routing surface. The provider is current and supported, but it does not currently participate in the same local static model-catalog sync flow used by agy, claude, codex, gemini, ghcp, iflow, kimi, kiro, and qwen. Use the legacy bridge page only if you still need the reverse-engineered local Cursor daemon compatibility path.