Handledning för Cursor Origin: CLI-installation, GitHub-spegling och pull requests

Vad är Cursor Origin?

Cursor Origin är en Git-smedja. Den hostar repos, speglar GitHub-projekt och stödjer pull requests och kodbläddring. Origin-repon fungerar också med Cursors molnagenter och automationer.

Vad är skillnaden mellan Cursor Origin och GitHub?

Origin täcker inte varje GitHub-funktion. Offentliga repos är inte dokumenterade, och speglar utesluter GitHub Issues, GitHub Actions-workflows och Actions-hemligheter. GitHub förblir den bredare plattformen för publika repos, Issues, Actions och tredjepartsappar, så Origin är den smalare tjänsten i dag.

Den stora skillnaden ligger under det bekanta Git-arbetsflödet: Cursor byggde ett separat lagringslager för gren- och commit-volymen som produceras av agenter. Cursor kallar detta fokus ”agent scale”: arbetslaster där många agenter branchar, committar och öppnar pull requests mot samma repo.

Varför byggde Cursor en egen Git-värd?

Lagringsdesignen förklarar varför Cursor byggde en ny Git-värd istället för att lägga till ännu ett gränssnitt till en befintlig.

Cursors ingenjörsinlägg om Continuity beskriver att befintliga Git-värdar håller ett repo på flera servrar och bekräftar en push efter att en majoritet är överens. Cursor säger att denna modell kostar mer när ett system har tusentals kortlivade repos eller frekventa pushar till ett enda repo.

Hur fungerar Cursor Origins lagring Continuity?

Continuity, eller ”Cnt”, är lagringssystemet bakom Origin. Det lagrar en write-ahead-logg i S3-kompatibelt objektlager som källan till sanning. Git-repot på lokal disk är en varm cache som kan återskapas från loggen.

Continuity lagrar Git-skrivningar som objekt. Bild av författaren.

Eftersom objektloggen är den verkliga journalen kan Cursor lägga till läsrepliker för upptagna repos och ta bort dem när efterfrågan sjunker. I Cursors tester ökade läsgenomströmningen när repliker lades till, upp till 100 repliker. Systemet hanterade upp till 120 pushar per sekund på standard-S3, men dessa siffror har inte granskats av ett oberoende benchmark.

För användaren är huvud­effekten enklare: ett upptaget repo kan få mer läskapacitet, medan ett kortlivat repo inte behöver en permanent lokal kopia på varje server.

Vem kan få åtkomst till Cursor Origin?

Origin finns på planerna Pro, Teams och Enterprise, men inte på gratisplaner. Åtkomst rullas ut i etapper, så en berättigad plan garanterar inte att fliken Codebase visas direkt. På Pro äger du ett individuellt namnrymd (namespace) och registrerar ditt eget codebase-namn.

Enterprise-administratörer kan inaktivera det för sin organisation. Cursors översikt säger att valfri teammedlem kan göra anspråk på det första codebase-namnet, medan sidan Codebase Settings säger att en teamadministratör måste göra det. Kontrollera den behörigheten i ditt team före setup.

Vad är Cursor Origin CLI?

Origin levereras med ett eget kommandoradsverktyg för autentisering, repos, pull requests och kontokonfiguration.

Cursor Origin CLI vs. Cursor Agent CLI

Origins CLI är en separat binär, origin, från Cursors Agent CLI, som körs som agent. 

Jag tyckte namnen var lätta att blanda ihop eftersom origin också är det konventionella namnet för en Git-fjärr (remote). I den här artikeln betyder ”push till origin” Git-fjärren, medan ”kör origin” betyder CLI:t.

Vilka plattformar stödjer Origin CLI?

Cursor dokumenterar macOS, Linux och Windows via WSL. Vid tiden för mitt test betydde Windows WSL eftersom det inte fanns någon inbyggd installerare.

Om du följer med på Windows, öppna Ubuntu-terminalen innan du installerar CLI:t. Att köra shell-installern i PowerShell ger inte samma setup.

Kommandon i Cursor Origin CLI

Cursor Origin CLI har för närvarande nio kommando­grupper.

De flesta repokommandon läser målet från Git-fjärren med namnet origin. Flaggan -R owner/repo sätter målet direkt, vilket är användbart i ett skript som kan köras mot flera repos. Kommandona ruleset visar bara befintliga push- och merge-regler; de ändrar dem inte.

Hur du installerar och loggar in i Cursor Origin CLI

Cursor tillhandahåller CLI:t via ett shellscript snarare än en pakethanterare. Kommandot kommer från Cursors installationssida.

Så installerar du Cursor Origin CLI

Installationen är i praktiken en rad:

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

Installern placerade origin i ~/.local/bin/origin. Om ditt team granskar installationsskript innan de körs, ladda ner skriptet först istället för att pipe:a det direkt till sh.

Åtgärda felet ”command not found” för Origin CLI

Om ditt skal inte hittar origin efter installationen, lägg till dess katalog i PATH:

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

Byt ut ~/.zshrc mot ~/.bashrc om du använder bash. Det är en engångsåtgärd per maskin.

Kontrollera installation och inloggning

Kör origin --version och origin --help för att bekräfta installationen, använd därefter origin auth login för att öppna Cursors inloggningsflöde i webbläsaren.

Så här såg verifieringsutmatningen ut i WSL:

Origin CLI-version och hjälpoutput. Bild av författaren.

I en headless-miljö skriver CLI:t istället ut en URL. Inloggning konfigurerar också Gits cred-helper, så Origin-fjärrar fungerar utan separat Git-token. Kör origin auth status efteråt för att kontrollera sessionen.

Använda en Cursor API-nyckel utan webbläsare

För CI eller skript, kör origin auth login --api-key <key> eller sätt CURSOR_API_KEY före origin auth login. Håll nyckeln borta från committade filer. CURSOR_AUTH_TOKEN är annorlunda och förväntar sig en bearer-token.

Hur du skapar, klonar och pushar ett Cursor Origin-repo

Efter inloggning kan du skapa ett repo från webbsidan eller CLI:t. Push använder standard-Git-kommandon.

Skapa ett repo med origin repo create

Från cursor.com/codebase väljer du New, anger ett namn och väljer synlighet Internal eller Private. 

Från CLI:t använder origin repo create my-project ditt kontos namnrymd. Inkludera en ägare, som i origin repo create acme/my-project, för ett team-namnrymd. Flaggan --default-branch ändrar serverns standard main.

Kommandot origin repo clone acme/my-project klonar repot över HTTPS med inloggningen som sparats av CLI:t.

Push av din första commit till Origin

Efter första pushen visas repot i Codebase:

Repo pushat och visas i Codebase. Video av författaren.

För ett helt nytt tomt repo, klona det, lägg till en fil och pusha:

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

Om Git rapporterar ett behörighetsfel med .git/config.lock under /mnt i WSL, klona istället under ~ . Det löste felet i mitt test.

Efter pushen, öppna Codebase och kontrollera att committen syns. Fliken Code visar filträdet och commithistorik. Tryck T för Go to file, eller använd sökfältet för att söka i koden.

Push av ett befintligt Git-repo till Origin

Om du redan har ett projekt med Git-historik, kör först git remote -v. Kommandot nedan gäller bara när repot inte redan har en fjärr med namnet origin:

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

Om origin redan pekar på GitHub, använd ett annat fjärrnamn som cursor istället för att ersätta den befintliga URL:en. Origin CLI-kommandon kommer inte att härleda repot från det namnet, så skicka -R owner/repo när du kör dem.

Hur du speglar ett GitHub-repo i Cursor Origin

En spegel kopierar ett befintligt GitHub-projekt till Origin och håller de två tjänsterna kopplade.

Krav för GitHub-spegling i Cursor Origin

Du behöver Origin-åtkomst, Cursor GitHub-appen kopplad till den organisation eller det konto som äger repot, och GitHub-administratörsåtkomst till repot. Skrivrättigheter räcker inte.

Starta en GitHub-spegel i Cursor Origin

Från cursor.com/codebase väljer du Sync from GitHub, väljer organisation och repo och bekräftar. CLI-alternativet är origin repo create-mirrored owner/repo, vilket täcks i Cursors spegeldokumentation.

Vad Cursor Origin speglar från GitHub

Origin speglar Git-data, men inte varje GitHub-funktion:

GitHub Actions fortsätter att köra på GitHub. Depot- och Buildkite-integrationer gäller för Origin-hostade repos, inte speglade kopior.

När GitHub förblir källan till sanning

Medan ett repo är speglat passerar pushar via Origin vidare till GitHub. Detach from GitHub, under repo-inställningar, gör Origin-kopian fristående utan att ändra GitHub-repot.

Hur du öppnar och granskar en pull request i Cursor Origin

Origin-pull requests använder samma sekvens för gren, push och granskning som på andra Git-värdar. Vår guide till hur pull requests fungerar förklarar den sekvensen.

Skapa en gren och pusha en ändring

Skapa och pusha arbetsgrenen:

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 har gjort sitt; nästa kommando tillhör Origin.

Öppna en pull request med Origin CLI

Repokommandon härleder målet från Git-fjärren med namnet origin. Kör origin pr create, eller skicka -R owner/repo för att sätta repot direkt. Kommandot skapar en utkast som standard; skicka --status open för en som är redo för granskning.

Granska en pull request i Cursor Origin

CLI:t inkluderar origin pr list, origin pr view, origin pr diff och origin pr checks. Utan konfigurerad CI-app skrev origin pr checks ut No checks reported. och avslutade med kod 1 i mitt test.

Den utgångskoden spelar roll i shellskript som använder set -e, eftersom en tom Checks-flik kan stoppa skriptet även om själva pull requesten är okej.

Granskning av pull request med fyra flikar. Bild av författaren.

I webbvyn har varje pull request fyra flikar: Activity, Commits, Checks och Files Changed, plus granskarförfrågningar, radkommentarer och en merge-knapp. Webbsidan visar merge-konflikter, och origin pr status --conflict-status rapporterar dem från terminalen.

Terminalen stödjer också origin pr merge. Pull requests som skapas på ett Origin-hostat repo stannar på Origin, medan aktivitet på ett speglat repo skickas tillbaka till GitHub.

Teamåtkomst och repo-behörigheter i Cursor Origin

Origin-behörigheter finns på codebase- och repo-nivå.

Codebase-inställningar vs. repo-inställningar

Codebase-inställningar gäller teambrett: vem som kan slå på Origin, skapa repos och installera appar. Repo-inställningar är begränsade till ett repo och täcker General, Permissions, Rules and Protections och Apps, även om Cursors dokument varnar för att Permissions- och Rules-sidorna görs om.

Om en lagkamrat kan använda Origin men inte kan öppna ett repo, kontrollera det repots behörigheter snarare än de teamvida inställningarna.

Internal vs. Private-repos

Det finns två olika typer av repos med begränsad åtkomst:

• Internal repos är synliga för teammedlemmar med codebase-åtkomst. 
• Private repos är synliga endast för medlemmar som har beviljats åtkomst direkt eller via codebase-behörigheter. Att växla ett repo till private behåller den som gjorde ändringen som administratör.

Hur du kontrollerar repo-åtkomst i Cursor Origin

Kommandot origin repo list visar alla repos som är synliga för det aktuella kontot. För att granska vem som kan komma åt ett repo, öppna Settings och sedan Permissions.

Best practices för Cursor Origin

Tre saker är mycket viktiga att ha i åtanke när du arbetar med Origin:

• Bekräfta hela owner/repo-värdet och inspektera dess fjärrar innan du tar bort eller konfigurerar om ett repo. 

• Undvik -y tills målet är verifierat. 

• Cursors behörighetssidor motsäger varandra, så kontrollera aktuell dokumentation innan du automatiserar åtkomständringar.

Cursor Origin vs. GitHub: Funktionsjämförelse

Origin är knutet till Cursors agentarbetsflöde, medan GitHub täcker ett bredare repo-ekosystem.

Git-hosting, pull requests och CI/CD

Istället för att upprepa varje avsnitt kommer här den korta versionen av funktionsuppdelningen:

Raden om agenter är den som behöver kontext.

Cursor Origin vs. GitHub för agentarbetsflöden

Båda plattformarna låter agenter arbeta mot repos. Origin håller den loopen inom Cursor; GitHub erbjuder den via sin Agents-panel och Copilot-verktyg, inklusive den allmänt tillgängliga CLI:n.

När du ska använda Cursor Origin, GitHub eller båda

• Använd Origin när repot är internt eller privat, det mesta agentarbetet redan sker i Cursor och din deploy- eller CI-setup kan köras via Vercel, Depot eller Buildkite.
• Behåll GitHub som primär värd när projektet är publikt, Issues och Actions är del av det dagliga arbetet eller teamet är beroende av GitHubs appmarknadsplats.
• Använd båda när du vill ha Origins kodbläddring och agentarbetsflöde utan att flytta källrepot. En spegel håller push- och pull request-aktivitet knuten till GitHub samtidigt som samma kod är tillgänglig i Origin.

Avslutande tankar

Jag gick från en ny WSL-installation till en öppen Origin-pull request med samma gren-, commit- och push-flöde som jag använder med GitHub. CLI:t ändrade inte hur Git fungerade; Origins skillnader syntes kring hosting, behörigheter och spegling.

Efter att ha använt det skulle jag se Origin som ett komplement till GitHub, inte en full ersättare. Spegling är den mest praktiska ingången för ett befintligt repo eftersom GitHub kan förbli auktoritativt. Publika projekt och arbetsflöden som är tunga på Actions har fortfarande liten anledning att flytta.

För relaterad läsning täcker vår guide till Cursor Automations agentuppgifter som körs mot ett befintligt repo. Vår guide till vad GitHub är och hur man använder det förklarar GitHub-arbetsflödet mer i detalj.