Tutorial de Cursor Origin: configuración de la CLI, espejo con GitHub y pull requests

¿Qué es Cursor Origin?

Cursor Origin es una forja de Git. Aloja repositorios, refleja proyectos de GitHub y admite pull requests y exploración de código. Los repos de Origin también funcionan con los agentes en la nube y automatizaciones de Cursor.

¿En qué se diferencia Cursor Origin de GitHub?

Origin no cubre todas las funciones de GitHub. No hay documentación de repos públicos y los espejos excluyen GitHub Issues, los workflows de GitHub Actions y los secretos de Actions. GitHub sigue siendo la plataforma más amplia para repos públicos, Issues, Actions y apps de terceros, así que hoy Origin es el servicio más acotado.

La principal diferencia está bajo el flujo de Git de siempre: Cursor ha creado una capa de almacenamiento separada para el volumen de ramas y commits que generan los agentes. Cursor llama a este enfoque "escala de agentes": cargas donde muchos agentes crean ramas, hacen commits y abren pull requests contra el mismo repositorio.

¿Por qué Cursor ha creado su propio host de Git?

El diseño de almacenamiento explica por qué Cursor creó un host de Git nuevo en lugar de añadir otra interfaz sobre uno existente.

La entrada técnica sobre Continuity de Cursor describe que los hosts de Git existentes guardan un repo en varios servidores y confirman un push cuando una mayoría está de acuerdo. Cursor afirma que este modelo se encarece cuando hay miles de repos efímeros o pushes muy frecuentes a un único repo.

¿Cómo funciona el almacenamiento Continuity de Cursor Origin?

Continuity, o "Cnt", es el sistema de almacenamiento detrás de Origin. Guarda un write-ahead log en almacenamiento de objetos compatible con S3 como fuente de la verdad. El repositorio Git en disco local es una caché caliente que se puede reconstruir desde ese log.

Continuity almacena escrituras de Git como objetos. Imagen del autor.

Como el log de objetos es el registro real, Cursor puede añadir réplicas de lectura para repos con mucha carga y retirarlas cuando baje la demanda. En sus pruebas, el rendimiento de lectura aumentó al sumar réplicas, hasta 100 réplicas. El sistema manejó hasta 120 pushes por segundo en S3 estándar, pero esas cifras no han sido verificadas por un benchmark independiente.

Para ti como usuario, el efecto principal es más simple: un repo muy concurrido puede ganar capacidad de lectura, mientras que un repo de vida corta no necesita una copia local permanente en cada servidor.

¿Quién puede acceder a Cursor Origin?

Origin está disponible en los planes Pro, Teams y Enterprise, pero no en el plan gratuito. El acceso se despliega por etapas, así que tener un plan apto no garantiza que la pestaña Codebase aparezca de inmediato. En Pro, tienes un espacio de nombres individual y reclamas el nombre de tu codebase.

Los administradores de Enterprise pueden desactivarlo para su organización. En la visión general de Cursor se dice que cualquier miembro del equipo puede reclamar el primer nombre de codebase, mientras que en la página de Codebase Settings aparece que debe hacerlo un admin del equipo. Comprueba ese permiso en tu equipo antes de configurar nada.

¿Qué es la CLI de Cursor Origin?

Origin incluye su propia herramienta de línea de comandos para autenticación, repositorios, pull requests y configuración de cuenta.

CLI de Cursor Origin vs. CLI de Cursor Agent

La CLI de Origin es un binario separado, origin, distinto de la CLI del agente de Cursor, que se ejecuta como agent. 

Los nombres se pueden confundir porque origin también es el nombre convencional de un remoto de Git. En este artículo, "hacer push a origin" se refiere al remoto de Git, mientras que "ejecutar origin" se refiere a la CLI.

¿Qué plataformas admiten la CLI de Origin?

Cursor documenta macOS, Linux y Windows a través de WSL. En el momento de mi prueba, Windows significaba WSL porque no había instalador nativo.

Si sigues los pasos en Windows, abre la terminal de Ubuntu antes de instalar la CLI. Ejecutar el instalador de shell en PowerShell no es la misma configuración.

Comandos de la CLI de Cursor Origin

La CLI de Cursor Origin tiene ahora mismo nueve grupos de comandos.

La mayoría de los comandos de repositorio leen el destino del remoto de Git llamado origin. La opción -R owner/repo marca el destino directamente, útil en scripts que puedan ejecutarse contra varios repos. Los comandos ruleset solo muestran las reglas de push y merge existentes; no las cambian.

Cómo instalar e iniciar sesión en la CLI de Cursor Origin

Cursor distribuye la CLI mediante un script de shell en lugar de un gestor de paquetes. El comando está en la página de instalación de Cursor.

Cómo instalar la CLI de Cursor Origin

La instalación se reduce a una línea:

curl -fsSL https://downloads.cursor.com/origin/install.sh | sh

El instalador colocó origin en ~/.local/bin/origin. Si en tu equipo se revisan los scripts antes de ejecutarlos, descarga el script primero en lugar de encadenarlo directamente a sh.

Solucionar el error "command not found" de la CLI de Origin

Si tu shell no encuentra origin tras la instalación, añade su directorio al PATH:

echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.zshrc
source ~/.zshrc

Sustituye ~/.zshrc por ~/.bashrc si usas bash. Es un ajuste de una sola vez por máquina.

Comprobar la instalación e inicio de sesión

Ejecuta origin --version y origin --help para confirmar la instalación y luego usa origin auth login para abrir el flujo de inicio de sesión en el navegador de Cursor.

Así se veía la verificación en WSL:

Versión de la CLI de Origin y ayuda. Imagen del autor.

En un entorno sin interfaz gráfica, la CLI imprime una URL. El inicio de sesión también configura el ayudante de credenciales de Git, así que los remotos de Origin funcionan sin un token de Git aparte. Luego ejecuta origin auth status para comprobar la sesión.

Usar una clave de API de Cursor sin navegador

Para CI o scripts, ejecuta origin auth login --api-key <key> o define CURSOR_API_KEY antes de origin auth login. Mantén la clave fuera de archivos con control de versiones. CURSOR_AUTH_TOKEN es distinto y espera un bearer token.

Cómo crear, clonar y hacer push a un repositorio de Cursor Origin

Tras iniciar sesión, puedes crear un repositorio desde la web o desde la CLI. Los push usan los comandos estándar de Git.

Crear un repositorio con origin repo create

Desde cursor.com/codebase, selecciona New, elige un nombre y selecciona visibilidad Internal o Private. 

Desde la CLI, origin repo create my-project usa el espacio de nombres de tu cuenta. Incluye un propietario, como en origin repo create acme/my-project, para el espacio de nombres del equipo. La opción --default-branch es opcional y cambia el valor por defecto del servidor, main.

El comando origin repo clone acme/my-project clona el repo por HTTPS con el inicio de sesión guardado por la CLI.

Hacer push de tu primer commit a Origin

Tras el primer push, el repo aparece en Codebase:

Repositorio con push y visible en Codebase. Vídeo del autor.

Para un repositorio vacío recién creado, clónalo, añade un archivo y haz push:

git clone https://origin.cursor.com/{owner}/{repo}.git
cd {repo}
echo "# {repo}" > README.md
git add .
git commit -m "Initial commit"
git push -u origin main

Si Git informa de un error de permisos con .git/config.lock bajo /mnt en WSL, clona en ~ en su lugar. Eso resolvió el error en mi prueba.

Después del push, abre Codebase y comprueba que aparece el commit. La pestaña Code muestra el árbol de archivos y el historial de commits. Pulsa T para Go to file, o usa el campo de búsqueda para buscar en el código.

Hacer push de un repositorio Git existente a Origin

Si ya tienes un proyecto con historial de Git, ejecuta primero git remote -v. El siguiente comando solo aplica cuando el repo aún no tiene un remoto llamado origin:

git remote add origin https://origin.cursor.com/{owner}/{repo}.git
git push -u origin main

Si origin ya apunta a GitHub, usa otro nombre de remoto como cursor en lugar de reemplazar la URL existente. Los comandos de la CLI de Origin no inferirán el repositorio desde ese nombre, así que pasa -R owner/repo al ejecutarlos.

Cómo hacer espejo de un repositorio de GitHub en Cursor Origin

Un espejo copia un proyecto de GitHub existente en Origin y mantiene ambos servicios conectados.

Requisitos para el espejo con GitHub en Cursor Origin

Necesitarás acceso a Origin, la app de GitHub de Cursor conectada a la organización o cuenta propietaria del repo y acceso de admin a ese repositorio en GitHub. El acceso de escritura no basta.

Iniciar un espejo de GitHub en Cursor Origin

Desde cursor.com/codebase, selecciona Sync from GitHub, elige la organización y el repositorio y confirma. La alternativa en CLI es origin repo create-mirrored owner/repo, cubierta en la documentación de mirroring de Cursor.

Qué refleja Cursor Origin desde GitHub

Origin refleja los datos de Git, pero no todas las funciones de GitHub:

GitHub Actions siguen ejecutándose en GitHub. Las integraciones con Depot y Buildkite aplican a repos alojados en Origin, no a copias reflejadas.

Cuándo GitHub sigue siendo la fuente de la verdad

Mientras un repo esté en espejo, los pushes a través de Origin se propagan a GitHub. Detach from GitHub, en los ajustes del repo, hace que la copia en Origin sea independiente sin cambiar el repositorio de GitHub.

Cómo abrir y revisar un pull request en Cursor Origin

Los pull requests en Origin siguen la misma secuencia de ramas, push y revisión que en otros hosts de Git. Nuestra guía sobre cómo funcionan los pull requests explica esa secuencia.

Crear una rama y subir un cambio

Crea y sube la rama de trabajo:

git checkout -b my-change
echo "Example change" >> README.md
git add README.md
git commit -m "Add example change"
git push -u origin my-change

Git ya ha hecho su parte; el siguiente comando pertenece a Origin.

Abrir un pull request con la CLI de Origin

Los comandos de repositorio infieren el destino del remoto de Git llamado origin. Ejecuta origin pr create, o pasa -R owner/repo para establecer el repo directamente. Por defecto el comando crea un borrador; usa --status open para uno listo para revisión.

Revisar un pull request de Cursor Origin

La CLI incluye origin pr list, origin pr view, origin pr diff y origin pr checks. Sin ninguna app de CI configurada, origin pr checks imprimió No checks reported. y salió con código 1 en mi prueba.

Ese código de salida importa en scripts de shell que usan set -e, ya que una pestaña Checks vacía puede parar el script aunque el pull request esté correcto.

Revisión de pull request con cuatro pestañas. Imagen del autor.

En la vista web, cada pull request tiene cuatro pestañas: Activity, Commits, Checks y Files Changed, además de solicitudes de revisor, comentarios en línea y un botón de merge. La página web muestra conflictos de merge y origin pr status --conflict-status los informa desde la terminal.

La terminal también permite origin pr merge. Los pull requests creados en un repo alojado en Origin se quedan en Origin, mientras que la actividad en un repo espejado se envía de vuelta a GitHub.

Acceso de equipo y permisos de repositorio en Cursor Origin

Los permisos en Origin existen a nivel de codebase y de repositorio.

Ajustes de codebase vs. ajustes de repositorio

Los ajustes de Codebase son de todo el equipo: quién puede activar Origin, crear repos y configurar apps. Los ajustes de repositorio se aplican a un único repo y cubren General, Permissions, Rules and Protections y Apps, aunque la documentación de Cursor avisa de que las pantallas de Permissions y Rules están siendo rediseñadas.

Si una persona de tu equipo puede usar Origin pero no abrir un repo concreto, revisa los permisos de ese repo en lugar de los ajustes a nivel de equipo.

Repositorios Internal vs. Private

Hay dos tipos de repos con acceso restringido:

• Internal repositories son visibles para los miembros del equipo con acceso al codebase. 
• Private repositories solo son visibles para quienes tienen acceso concedido directamente o a través de permisos del codebase. Al cambiar un repo a private, quien hace el cambio se mantiene como admin.

Cómo comprobar el acceso a un repositorio en Cursor Origin

El comando origin repo list muestra todos los repos visibles para la cuenta actual. Para revisar quién puede acceder a un repo concreto, abre Settings y luego Permissions.

Buenas prácticas con Cursor Origin

Hay tres cosas clave que conviene tener presentes al trabajar con Origin:

• Antes de borrar o reconfigurar un repo, confirma el valor completo de owner/repo e inspecciona sus remotos. 

• Evita -y hasta verificar el destino. 

• Las páginas de permisos de Cursor no son coherentes entre sí; revisa la documentación actual antes de automatizar cambios de acceso.

Cursor Origin vs. GitHub: comparativa de funciones

Origin está ligado al flujo de trabajo con agentes de Cursor, mientras que GitHub cubre un ecosistema de repos más amplio.

Alojamiento Git, pull requests y CI/CD

En lugar de repetir cada sección, este es el resumen corto de la división de funciones:

La fila de agentes es la que necesita contexto.

Cursor Origin vs. GitHub para flujos con agentes

Ambas plataformas permiten que los agentes trabajen contra repos. Origin mantiene ese ciclo dentro de Cursor; GitHub lo ofrece mediante su panel de Agents y herramientas de Copilot, incluida la CLI en disponibilidad general.

Cuándo usar Cursor Origin, GitHub o ambos

• Usa Origin cuando el repositorio sea internal o private, la mayor parte del trabajo con agentes ya ocurra dentro de Cursor y tu despliegue o CI pueda ejecutarse con Vercel, Depot o Buildkite.
• Mantén GitHub como host principal cuando el proyecto sea público, Issues y Actions formen parte del día a día o el equipo dependa del marketplace de GitHub.
• Usa ambos si quieres la navegación de código y el flujo con agentes de Origin sin mover el repo fuente. Un espejo mantiene los pushes y la actividad de PR ligados a GitHub mientras pone el mismo código a disposición en Origin.

Conclusiones

Pasé de una instalación limpia de WSL a un pull request abierto en Origin usando el mismo flujo de ramas, commits y push que uso con GitHub. La CLI no cambió cómo funciona Git; las diferencias de Origin aparecieron en el hosting, los permisos y el espejo.

Tras usarlo, trataría Origin como un complemento de GitHub, no un sustituto completo. El espejo es la vía de entrada más práctica para un repo existente porque GitHub puede seguir siendo la autoridad. Los proyectos públicos y los flujos cargados de Actions siguen teniendo pocos motivos para moverse.

Para ampliar, nuestra guía de Cursor Automations cubre tareas de agentes que se ejecutan contra un repo existente. Nuestra guía sobre qué es GitHub y cómo usarlo explica el flujo de GitHub con más detalle.