Cursor CLI — First impressions on the UX

This post captures my first impressions of the Cursor CLI from a user-experience lens. I’ve been a daily Cursor IDE user, so I was curious to see how the command‑line experience maps to real workflows.

Why Cursor CLI?

• Terminal‑native workflows: when you’re already in a shell (local or remote), it’s convenient to ask for help without context‑switching to an editor.
• Same mental model as the IDE: chat first, then approve edits or shell commands the agent proposes.
• Reuses your Cursor rules and configuration: the CLI follows the same security posture (ask‑to‑apply) and leverages your existing setup.
• Fast model switching: a single slash command to choose models or list what’s available.

Quick start (per docs):

# Launch the agent
cursor-agent

# List available models
/model ls

# Switch model for the session
/model gpt-5

Supported models

On day one, I saw:

• OpenAI GPT‑5 — available thanks to the Cursor × OpenAI partnership (free during the release week).
• Anthropic Claude 4 Sonnet and Claude 4.1 Opus — also selectable directly from the CLI.

From the current UI it looks like the listed models are the ones supported. I expect broader model configuration down the road, similar to what we already have in Cursor IDE.

Cursor CLI vs IDE

• Where you run it: despite being a CLI, you can open it from any terminal — the Cursor IDE terminal, VS Code terminal, iTerm, etc.
• Context ergonomics: one notable difference is that the common @ to attach files/folders as context does not behave the same as in Cursor IDE (or other CLIs). Some additional integration would help here. A lightweight extension for popular terminals/editors could close this gap.

Cursor CLI UX vs others (Claude Code CLI, Codex, Gemini CLI, Amazon Q, etc.)

• Overall feel: the interaction model is familiar if you’ve tried other AI CLIs. That’s actually positive — you get a common mental model across tools.
• What’s still missing vs Claude Code CLI (from my early testing): I couldn’t find /hooks, /mcp, or a way to define custom slash commands yet. If those appear, the CLI would jump a tier in automation flexibility.

Issues I found (early beta)

According to the docs, the CLI uses the same MCP configuration as the IDE. In practice, I hit problems:

• Listing Obsidian notes via an MCP server that works fine in the IDE — failed.
• Creating a GitHub issue through the GitHub MCP — also failed during my tests.

Screenshots from these attempts:

If the CLI truly shares the identical config, these should behave consistently. I’ll retest as updates roll out.

Where it might stand out

• Non‑interactive pipelines: if/when a non‑interactive mode lands, this could be ideal for CI/CD or scripted workflows where you want a constrained agent to generate diffs and propose edits, then let the pipeline gate approvals.
• Remote servers: quick on‑box assistance without opening an IDE.
• Complement to the ecosystem: it rounds out what Cursor has been building with the IDE, Bug Hunter, and Background Agents.

Final thoughts

Cursor CLI is a welcome addition that aligns with the IDE’s philosophy: concise prompts, safe edit approvals, and fast model switching — now in your terminal. It’s already usable for ad‑hoc terminal sessions, and with improved file context ergonomics and reliable MCP parity, it could become a powerful building block for repeatable CLI and CI/CD workflows.

First‑impressions verdict: promising, familiar, and evolving. I’ll keep testing as new builds drop.