Tutorial su Cursor Origin: configurazione CLI, mirroring con GitHub e pull request

Che cos'è Cursor Origin?

Cursor Origin è una forge Git. Ospita repository, effettua il mirroring di progetti GitHub e supporta pull request e navigazione del codice. I repository di Origin funzionano anche con gli agenti cloud e le automazioni di Cursor.

Qual è la differenza tra Cursor Origin e GitHub?

Origin non copre tutte le funzionalità di GitHub. I repository pubblici non sono documentati, e i mirror escludono le Issues di GitHub, i workflow di GitHub Actions e i segreti delle Actions. GitHub resta la piattaforma più ampia per repository pubblici, Issues, Actions e app di terze parti, quindi oggi Origin è il servizio più ristretto.

La differenza principale sta sotto il workflow Git familiare: Cursor ha costruito un livello di storage separato per la mole di branch e commit prodotta dagli agenti. Cursor chiama questo focus "agent scale": carichi di lavoro in cui molti agenti creano branch, fanno commit e aprono pull request sullo stesso repository.

Perché Cursor ha creato un proprio host Git?

Il design dello storage spiega perché Cursor ha creato un nuovo host Git invece di aggiungere un'altra interfaccia a uno esistente.

Il post tecnico su Continuity di Cursor descrive gli host Git esistenti come sistemi che mantengono un repository su diversi server e confermano un push dopo l'accordo della maggioranza. Cursor afferma che questo modello costa di più quando un sistema ha migliaia di repository di breve durata o push frequenti su un singolo repository.

Come funziona lo storage Continuity di Cursor Origin?

Continuity, o "Cnt", è il sistema di storage dietro Origin. Archivia un write-ahead log in uno storage a oggetti compatibile con S3 come fonte di verità. Il repository Git su disco locale è una cache calda ricostruibile dal log.

Continuity archivia le scritture Git come oggetti. Immagine dell'Autore.

Poiché il log a oggetti è il vero registro, Cursor può aggiungere repliche di lettura per repository molto usati e rimuoverle quando la domanda cala. Nei test di Cursor, la velocità di lettura cresceva con l'aggiunta di repliche, fino a 100 repliche. Il sistema ha gestito fino a 120 push al secondo su S3 standard, ma quelle cifre non sono state verificate da benchmark indipendenti.

Per l'utente, l'effetto principale è più semplice: un repository molto attivo può aumentare la capacità di lettura, mentre un repository di breve durata non ha bisogno di una copia locale permanente su ogni server.

Chi può accedere a Cursor Origin?

Origin è disponibile nei piani Pro, Teams ed Enterprise, ma non nei piani gratuiti. L'accesso viene rilasciato a scaglioni, quindi un piano idoneo non garantisce che la scheda Codebase compaia subito. Su Pro possiedi uno namespace individuale e scegli il nome della tua codebase.

Gli admin Enterprise possono disabilitarlo per la loro organizzazione. La panoramica di Cursor afferma che qualsiasi membro del team può rivendicare il primo nome della codebase, mentre la pagina Codebase Settings afferma che deve farlo un admin del team. Verifica quel permesso nel tuo team prima della configurazione.

Che cos'è la CLI di Cursor Origin?

Origin include un proprio strumento da riga di comando per autenticazione, repository, pull request e configurazione dell'account.

CLI di Cursor Origin vs. CLI dell'agente di Cursor

La CLI di Origin è un binario separato, origin, rispetto alla CLI dell'agente di Cursor, che gira come agent. 

Ho trovato facile confondere i nomi perché origin è anche il nome convenzionale di un remote Git. In questo articolo, "push su origin" indica il remote Git, mentre "eseguire origin" indica la CLI.

Quali piattaforme supportano la CLI di Origin?

Cursor documenta macOS, Linux e Windows tramite WSL. Al momento del mio test, Windows significava WSL perché non c'era un installer nativo.

Se stai seguendo su Windows, apri il terminale di Ubuntu prima di installare la CLI. Eseguire l'installer shell in PowerShell non è la stessa configurazione.

Comandi della CLI di Cursor Origin

La CLI di Cursor Origin attualmente ha nove gruppi di comandi.

La maggior parte dei comandi sul repository legge l'obiettivo dal remote Git chiamato origin. L'opzione -R owner/repo imposta direttamente l'obiettivo, utile in uno script che può operare su più repository. I comandi ruleset mostrano solo le regole di push e merge esistenti; non le modificano.

Come installare e accedere alla CLI di Cursor Origin

Cursor fornisce la CLI tramite uno script shell invece che con un gestore pacchetti. Il comando arriva dalla pagina di installazione di Cursor.

Come installare la CLI di Cursor Origin

L'installazione si riduce a una riga:

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

L'installer ha posizionato origin in ~/.local/bin/origin. Se il tuo team rivede gli script di installazione prima di eseguirli, scarica lo script prima invece di pipearlo direttamente su sh.

Correggere l'errore "command not found" della CLI di Origin

Se la tua shell non trova origin dopo l'installazione, aggiungi la sua directory al PATH:

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

Sostituisci ~/.zshrc con ~/.bashrc su bash. È una correzione una tantum per macchina.

Verificare l'installazione e l'accesso

Esegui origin --version e origin --help per confermare l'installazione, poi usa origin auth login per aprire il flusso di accesso nel browser di Cursor.

Ecco come appariva l'output di verifica in WSL:

Versione della CLI di Origin e output di help. Immagine dell'Autore.

In un ambiente headless, la CLI stampa invece un URL. L'accesso configura anche l'helper delle credenziali di Git, così i remote di Origin funzionano senza un token Git separato. Esegui origin auth status dopo per verificare la sessione.

Usare una chiave API di Cursor senza browser

Per CI o script, esegui origin auth login --api-key <key> o imposta CURSOR_API_KEY prima di origin auth login. Tieni la chiave fuori dai file versionati. CURSOR_AUTH_TOKEN è diverso e si aspetta un bearer token.

Come creare, clonare e fare push di un repository su Cursor Origin

Dopo l'accesso, puoi creare un repository dalla pagina web o dalla CLI. Il push usa i comandi Git standard.

Creare un repository con origin repo create

Da cursor.com/codebase, seleziona New, inserisci un nome e scegli la visibilità Internal o Private. 

Dalla CLI, origin repo create my-project usa lo namespace del tuo account. Includi un owner, come in origin repo create acme/my-project, per lo namespace di un team. Il flag opzionale --default-branch cambia il default del server, main.

Il comando origin repo clone acme/my-project clona il repository via HTTPS con l'accesso salvato dalla CLI.

Eseguire il push del tuo primo commit su Origin

Dopo il primo push, il repository appare in Codebase:

Repository pushato e mostrato in Codebase. Video dell'Autore.

Per un repository nuovo e vuoto, clonalo, aggiungi un file ed esegui il 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

Se Git segnala un errore di permessi su .git/config.lock sotto /mnt in WSL, clona invece sotto ~ . Questo ha risolto l'errore nel mio test.

Dopo il push, apri Codebase e verifica che il commit compaia. La scheda Code mostra l'albero dei file e la cronologia dei commit. Premi T per Vai al file, o usa il campo di ricerca per cercare nel codice.

Eseguire il push di un repository Git esistente su Origin

Se hai già un progetto con cronologia Git, esegui prima git remote -v. Il comando seguente si applica solo quando il repository non ha già un remote chiamato origin:

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

Se origin punta già a GitHub, usa un altro nome per il remote come cursor invece di sostituire l'URL esistente. I comandi della CLI di Origin non dedurranno il repository da quel nome, quindi passa -R owner/repo quando li esegui.

Come effettuare il mirror di un repository GitHub in Cursor Origin

Un mirror copia un progetto GitHub esistente in Origin e mantiene collegati i due servizi.

Requisiti per il mirroring GitHub su Cursor Origin

Ti serviranno l'accesso a Origin, l'app GitHub di Cursor collegata all'organizzazione o all'account proprietario del repository e l'accesso admin su GitHub a quel repository. Il solo accesso in scrittura non basta.

Avviare un mirror GitHub su Cursor Origin

Da cursor.com/codebase, seleziona Sync from GitHub, scegli l'organizzazione e il repository e conferma. L'alternativa via CLI è origin repo create-mirrored owner/repo, descritta nella documentazione sul mirroring.

Cosa effettua il mirror Cursor Origin da GitHub

Origin esegue il mirror dei dati Git, ma non di tutte le funzionalità di GitHub:

Le GitHub Actions continuano a girare su GitHub. Le integrazioni con Depot e Buildkite si applicano ai repository ospitati su Origin, non alle copie in mirror.

Quando GitHub resta la fonte di verità

Finché un repository è in mirror, i push tramite Origin passano attraverso GitHub. Detach from GitHub, sotto Settings del repository, rende autonoma la copia su Origin senza modificare il repository su GitHub.

Come aprire e revisionare una pull request su Cursor Origin

Le pull request di Origin seguono la stessa sequenza di branch, push e review degli altri host Git. La nostra guida a come funzionano le pull request spiega quella sequenza.

Creare un branch ed eseguire un cambiamento

Crea ed esegui il push del branch di lavoro:

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 ha fatto la sua parte; il comando successivo spetta a Origin.

Aprire una pull request con la CLI di Origin

I comandi per i repository deducono l'obiettivo dal remote Git chiamato origin. Esegui origin pr create, oppure passa -R owner/repo per impostare direttamente il repository. Il comando crea per default una draft; passa --status open per una pronta alla review.

Revisionare una pull request su Cursor Origin

La CLI include origin pr list, origin pr view, origin pr diff e origin pr checks. Senza alcuna app di CI configurata, origin pr checks ha stampato No checks reported. ed è uscito con codice 1 nel mio test.

Quel codice di uscita conta negli script shell che usano set -e, poiché una scheda Checks vuota può fermare lo script anche se la pull request è a posto.

Revisione della pull request con quattro schede. Immagine dell'Autore.

Nella vista web, ogni pull request ha quattro schede: Activity, Commits, Checks e Files Changed, oltre a richieste di reviewer, commenti inline e un pulsante di merge. La pagina web mostra i conflitti di merge e origin pr status --conflict-status li riporta dal terminale.

Il terminale supporta anche origin pr merge. Le pull request create su un repository ospitato su Origin restano su Origin, mentre l'attività su un repository in mirror viene inviata a GitHub.

Accesso del team e permessi dei repository in Cursor Origin

I permessi di Origin esistono a livello di codebase e di repository.

Impostazioni della codebase vs. impostazioni del repository

Le impostazioni della codebase sono a livello di team: chi può attivare Origin, creare repository e installare app. Le impostazioni del repository sono limitate a un singolo repository e coprono General, Permissions, Rules and Protections e Apps, anche se la documentazione di Cursor avverte che le schermate Permissions e Rules sono in fase di redesign.

Se un compagno di team può usare Origin ma non può aprire un repository, controlla i permessi di quel repository invece delle impostazioni a livello di team.

Repository Internal vs. Private

Esistono due tipi diversi di repository con accesso limitato:

• Internal repositories sono visibili ai membri del team con accesso alla codebase. 
• Private repositories sono visibili solo ai membri con accesso concesso direttamente o tramite permessi della codebase. Passare un repository a private mantiene come admin chi ha effettuato la modifica.

Come verificare l'accesso a un repository su Cursor Origin

Il comando origin repo list mostra ogni repository visibile all'account corrente. Per rivedere chi può accedere a un repository, apri Settings, poi Permissions.

Best practice per Cursor Origin

Tre cose sono molto importanti da tenere a mente quando lavori con Origin:

• Prima di eliminare o riconfigurare un repository, conferma il valore completo owner/repo e ispeziona i suoi remote. 

• Evita -y finché non hai verificato l'obiettivo. 

• Le pagine dei permessi di Cursor sono in conflitto, quindi controlla la documentazione attuale prima di automatizzare le modifiche all'accesso.

Cursor Origin vs. GitHub: confronto delle funzionalità

Origin è legato al flusso di lavoro degli agenti di Cursor, mentre GitHub copre un ecosistema di repository più ampio.

Hosting Git, pull request e CI/CD

Invece di ripetere ogni sezione, ecco la versione breve della ripartizione delle funzionalità:

La riga sugli agenti è quella che richiede contesto.

Cursor Origin vs. GitHub per i flussi di lavoro con agenti

Entrambe le piattaforme consentono agli agenti di lavorare sui repository. Origin mantiene quel loop dentro Cursor; GitHub lo offre tramite il suo pannello Agents e gli strumenti Copilot, inclusa la CLI disponibile in GA.

Quando usare Cursor Origin, GitHub o entrambi

• Usa Origin quando il repository è internal o private, la maggior parte del lavoro degli agenti avviene già in Cursor e il tuo setup di deploy o CI può funzionare tramite Vercel, Depot o Buildkite.
• Conserva GitHub come host primario quando il progetto è pubblico, Issues e Actions fanno parte del flusso quotidiano o il team dipende dal marketplace di GitHub.
• Usa entrambi quando vuoi la navigazione del codice e il flusso con agenti di Origin senza spostare il repository sorgente. Un mirror mantiene le attività di push e pull request legate a GitHub rendendo lo stesso codice disponibile in Origin.

Considerazioni finali

Sono passato da un'installazione WSL fresca a una pull request aperta su Origin usando lo stesso flusso di branch, commit e push che uso con GitHub. La CLI non ha cambiato il funzionamento di Git; le differenze di Origin sono emerse su hosting, permessi e mirroring.

Dopo averlo usato, tratterei Origin come un compagno di GitHub, non un sostituto completo. Il mirroring è il punto di ingresso più pratico per un repository esistente perché GitHub può restare autoritativo. I progetti pubblici e i flussi di lavoro pesanti su Actions hanno ancora pochi motivi per spostarsi.

Per approfondire, la nostra guida a Cursor Automations copre attività degli agenti che operano su un repository esistente. La nostra guida su cos'è GitHub e come usarlo spiega il workflow di GitHub in maggior dettaglio.