Cursor CLI — Primeras impresiones sobre la UX
Este post recoge mis primeras impresiones de Cursor CLI desde la óptica de la experiencia de usuario. Uso Cursor IDE a diario, así que tenía curiosidad por ver cómo se traslada ese flujo al terminal.
¿Por qué Cursor CLI?
- Flujos nativos de terminal: cuando ya estás en una shell (local o remota) es cómodo pedir ayuda sin cambiar a un editor.
- Mismo modelo mental del IDE: primero conversas, luego apruebas las ediciones o comandos de shell que propone el agente.
- Reutiliza tus reglas y configuración de Cursor: mantiene la postura de seguridad (aplicar solo con aprobación) y aprovecha tu configuración existente.
- Cambio rápido de modelo: un único slash‑command para elegir o listar modelos disponibles.
Inicio rápido (según la documentación):
# Lanzar el agente
cursor-agent
# Listar modelos disponibles
/model ls
# Cambiar el modelo de la sesión
/model gpt-5
Modelos soportados
Desde el primer día vi:
- OpenAI GPT‑5 — disponible gracias a la colaboración Cursor × OpenAI (gratis durante la semana de lanzamiento).
- Anthropic Claude 4 Sonnet y Claude 4.1 Opus — seleccionables directamente desde el CLI.
Por ahora parece que los modelos listados son los soportados. Espero una configuración más amplia con el tiempo, similar a la que ya tenemos en Cursor IDE.
Cursor CLI vs IDE
- Dónde se ejecuta: aunque es un CLI, puedes abrirlo en cualquier terminal — el terminal del Cursor IDE, el terminal de VS Code, iTerm, etc.
- Ergonomía del contexto: una diferencia notable es que el
@
para adjuntar archivos/carpetas como contexto no se comporta igual que en Cursor IDE (o en otros CLIs). Algo de integración adicional ayudaría. Una extensión ligera para terminales/editores populares podría cerrar esta brecha.
UX de Cursor CLI vs otros (Claude Code CLI, Codex, Gemini CLI, Amazon Q)
- Sensación general: el modelo de interacción resulta familiar si has probado otros CLIs de IA. Eso es positivo: obtienes una experiencia común entre herramientas.
- Lo que aún echo en falta vs Claude Code CLI (en mis pruebas): no encontré
/hooks
,/mcp
ni una forma de definir slash commands personalizados todavía. Si llegan, el CLI ganaría bastante en automatización.
Problemas encontrados (beta temprana)
Según la documentación, el CLI usa la misma configuración MCP que el IDE. En la práctica, me topé con problemas:
- Listar notas de Obsidian vía un MCP que funciona perfecto en el IDE — falló.
- Crear una issue en GitHub mediante el MCP de GitHub — también falló durante mis pruebas.
Capturas de esos intentos:
Si el CLI realmente comparte la configuración de forma idéntica, deberían comportarse igual. Volveré a probar conforme salgan actualizaciones.
Dónde podría destacar
- Pipelines no interactivos: si/cuando exista un modo no interactivo, puede ser ideal para CI/CD o flujos scriptados donde un agente proponga diffs y ediciones, y el pipeline controle las aprobaciones.
- Servidores remotos: ayuda puntual en la propia máquina sin abrir un IDE.
- Complemento del ecosistema: completa lo que Cursor viene construyendo con el IDE, Bug Hunter y Background Agents.
Reflexión final
Cursor CLI es una incorporación bienvenida que se alinea con la filosofía del IDE: prompts concisos, aplicación segura de ediciones y cambio rápido de modelos — ahora en tu terminal. Ya es útil para sesiones ad‑hoc en consola y, con mejor ergonomía para el contexto de archivos y una paridad MCP fiable, puede convertirse en una pieza potente para flujos CLI y CI/CD repetibles.
Veredicto de primeras impresiones: prometedor, familiar y en evolución. Seguiré probando a medida que salgan nuevas builds.