Cursor Origin Tutorial: CLI-Setup, GitHub-Mirroring und Pull Requests

Was ist Cursor Origin?

Cursor Origin ist eine Git-Forge. Sie hostet Repositories, spiegelt GitHub-Projekte und unterstützt Pull Requests sowie Code-Browsing. Origin-Repositories arbeiten zudem mit den Cloud-Agents und Automationen von Cursor zusammen.

Worin unterscheidet sich Cursor Origin von GitHub?

Origin deckt nicht jede GitHub-Funktion ab. Öffentliche Repositories sind nicht dokumentiert und Mirrors schließen GitHub Issues, GitHub Actions Workflows und Actions-Secrets aus. GitHub bleibt die breitere Plattform für Public Repos, Issues, Actions und Drittanbieter-Apps. Origin ist heute der fokussiertere Dienst.

Der Hauptunterschied liegt unter dem vertrauten Git-Workflow: Cursor hat eine separate Storage-Schicht für das Branch- und Commit-Volumen gebaut, das durch Agents entsteht. Cursor nennt diesen Fokus „Agent Scale“: Workloads, bei denen viele Agents gegen dasselbe Repository branchen, committen und Pull Requests öffnen.

Warum hat Cursor einen eigenen Git-Host gebaut?

Das Speicherkonzept erklärt, warum Cursor einen neuen Git-Host gebaut hat, statt nur eine weitere Oberfläche auf einen bestehenden zu setzen.

Der Engineering-Post zu Continuity von Cursor beschreibt, dass bestehende Git-Hosts ein Repository auf mehreren Servern halten und einen Push erst bestätigen, wenn eine Mehrheit zustimmt. Laut Cursor wird dieses Modell teurer, wenn ein System tausende kurzlebige Repositories hat oder sehr häufig in ein einziges Repository gepusht wird.

Wie funktioniert die Continuity-Speicherung von Cursor Origin?

Continuity, kurz „Cnt“, ist das Speichersystem hinter Origin. Es speichert ein Write-Ahead-Log in S3-kompatiblem Objektspeicher als maßgebliche Quelle. Das Git-Repository auf lokaler Platte ist ein Warm-Cache, der aus dem Log wiederaufgebaut werden kann.

Continuity speichert Git-Schreibvorgänge als Objekte. Bild: Autor.

Weil das Objekt-Log die tatsächliche Quelle ist, kann Cursor für stark frequentierte Repositories Read-Replicas hinzufügen und bei sinkender Nachfrage wieder entfernen. In Cursors Tests stieg der Lese-Durchsatz mit der Zahl der Replicas bis zu 100. Das System bewältigte bis zu 120 Pushes pro Sekunde auf Standard-S3, allerdings sind diese Zahlen nicht unabhängig gebenchmarkt.

Für Nutzer:innen ist die Auswirkung einfacher: Ein ausgelastetes Repository kann Lese-Kapazität gewinnen, während ein kurzlebiges Repository keine permanente lokale Kopie auf jedem Server benötigt.

Wer hat Zugriff auf Cursor Origin?

Origin ist in den Plänen Pro, Teams und Enterprise verfügbar, nicht jedoch im kostenlosen Plan. Der Zugriff wird stufenweise freigeschaltet. Ein berechtigter Plan garantiert daher nicht, dass der Codebase-Tab sofort erscheint. In Pro besitzt du einen individuellen Namespace und beanspruchst deinen Codebase-Namen selbst.

Enterprise-Admins können Origin für ihre Organisation deaktivieren. Laut Überblick kann jedes Teammitglied den ersten Codebase-Namen beanspruchen, während die Seite Codebase Settings sagt, ein Team-Admin müsse ihn beanspruchen. Prüfe dieses Recht in deinem Team vor dem Setup.

Was ist die Cursor Origin CLI?

Origin liefert ein eigenes Kommandozeilentool für Authentifizierung, Repositories, Pull Requests und Kontokonfiguration.

Cursor Origin CLI vs. Cursor Agent CLI

Die Origin-CLI ist ein separates Binary, origin, während die Agent-CLI als agent läuft.

Die Namen lassen sich leicht verwechseln, weil origin auch der gängige Name für ein Git-Remote ist. In diesem Artikel bedeutet „push to origin“ das Git-Remote, während „run origin“ die CLI meint.

Welche Plattformen unterstützen die Origin-CLI?

Cursor dokumentiert macOS, Linux und Windows über WSL. Zum Testzeitpunkt hieß Windows faktisch WSL, da es keinen nativen Installer gab.

Wenn du unter Windows mitmachst, öffne vor der Installation das Ubuntu-Terminal. Den Shell-Installer in PowerShell auszuführen, ist nicht das gleiche Setup.

Cursor Origin CLI-Befehle

Die Cursor Origin-CLI hat aktuell neun Befehlsgruppen.

Die meisten Repository-Befehle lesen ihr Ziel aus dem Git-Remote namens origin. Die Option -R owner/repo setzt das Ziel direkt, was in Skripten praktisch ist, die gegen mehrere Repositories laufen. Die ruleset Befehle zeigen nur bestehende Push- und Merge-Regeln an; sie ändern sie nicht.

So installierst du die Cursor Origin CLI und meldest dich an

Cursor stellt die CLI über ein Shell-Skript bereit, nicht über einen Paketmanager. Der Befehl kommt von der Installationsseite von Cursor.

So installierst du die Cursor Origin CLI

Die Installation ist ein Einzeiler:

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

Der Installer hat origin unter ~/.local/bin/origin abgelegt. Wenn dein Team Installationsskripte vor der Ausführung reviewt, lade das Skript zuerst herunter, statt es direkt in sh zu pipen.

Origin-CLI-Fehler „command not found“ beheben

Falls deine Shell origin nach der Installation nicht findet, füge das Verzeichnis zum PATH hinzu:

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

Ersetze ~/.zshrc durch ~/.bashrc für bash. Das ist eine einmalige Anpassung pro Rechner.

Installation und Login prüfen

Führe origin --version und origin --help aus, um die Installation zu bestätigen, und nutze danach origin auth login, um den Browser-Login-Flow von Cursor zu öffnen.

So sah die Ausgabe zur Verifizierung in WSL aus:

Origin-CLI-Version und Hilfeausgabe. Bild: Autor.

In einer Headless-Umgebung gibt die CLI stattdessen eine URL aus. Beim Login wird auch der Git-Credential-Helper konfiguriert, sodass Origin-Remotes ohne separates Git-Token funktionieren. Führe danach origin auth status aus, um die Session zu prüfen.

Einen Cursor-API-Schlüssel ohne Browser verwenden

Für CI oder Skripte führe origin auth login --api-key <key> aus oder setze CURSOR_API_KEY vor origin auth login. Halte den Schlüssel aus Versionierung heraus. CURSOR_AUTH_TOKEN ist etwas anderes und erwartet ein Bearer-Token.

So erstellst, klonst und pushst du ein Cursor Origin-Repository

Nach dem Anmelden kannst du ein Repository über die Weboberfläche oder die CLI erstellen. Für Pushes nutzt du die üblichen Git-Befehle.

Ein Repository mit origin repo create erstellen

Auf cursor.com/codebase wählst du New, gibst einen Namen ein und entscheidest dich für die Sichtbarkeit Internal oder Private.

Aus der CLI nutzt origin repo create my-project den Namespace deines Kontos. Für einen Team-Namespace gib den Owner an, etwa origin repo create acme/my-project. Der optionale Schalter --default-branch ändert den Server-Standard main.

Mit origin repo clone acme/my-project klonst du das Repository über HTTPS mit den von der CLI gespeicherten Zugangsdaten.

Den ersten Commit zu Origin pushen

Nach dem ersten Push erscheint das Repository in Codebase:

Repository gepusht und in Codebase angezeigt. Video: Autor.

Für ein komplett neues, leeres Repository: Klone es, füge eine Datei hinzu und pushe:

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

Wenn Git unter /mnt in WSL einen Berechtigungsfehler bei .git/config.lock meldet, klone stattdessen unter ~. Das hat den Fehler in meinem Test behoben.

Öffne nach dem Push Codebase und prüfe, ob der Commit angezeigt wird. Der Tab Code zeigt Dateibaum und Commit-Historie. Drücke T für Go to file oder nutze das Suchfeld, um den Code zu durchsuchen.

Ein bestehendes Git-Repository zu Origin pushen

Wenn dein Projekt bereits Git-Historie hat, führe zuerst git remote -v aus. Der folgende Befehl gilt nur, wenn noch kein Remote namens origin existiert:

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

Wenn origin bereits auf GitHub zeigt, nutze einen anderen Remote-Namen wie cursor statt die bestehende URL zu ersetzen. Die Origin-CLI leitet aus diesem Namen das Repository nicht ab, daher musst du bei Befehlen -R owner/repo mitgeben.

So spiegelst du ein GitHub-Repository in Cursor Origin

Ein Mirror kopiert ein bestehendes GitHub-Projekt nach Origin und hält beide Dienste verbunden.

Voraussetzungen für GitHub-Mirroring mit Cursor Origin

Du brauchst Origin-Zugang, die Cursor-GitHub-App, die mit der Organisation bzw. dem Account verbunden ist, dem das Repository gehört, sowie GitHub-Adminrechte für dieses Repository. Schreibrechte allein reichen nicht.

Einen GitHub-Mirror in Cursor Origin starten

Auf cursor.com/codebase wählst du Sync from GitHub, suchst Organisation und Repository aus und bestätigst. Die CLI-Alternative ist origin repo create-mirrored owner/repo, beschrieben in Cursors Mirroring-Dokumentation.

Was Cursor Origin von GitHub spiegelt

Origin spiegelt Git-Daten, aber nicht jede GitHub-Funktion:

GitHub Actions laufen weiterhin auf GitHub. Depot- und Buildkite-Integrationen gelten für in Origin gehostete Repositories, nicht für gespiegelte Kopien.

Wenn GitHub die maßgebliche Quelle bleibt

Solange ein Repository gespiegelt ist, werden Pushes über Origin an GitHub durchgereicht. Detach from GitHub in den Repository-Einstellungen macht die Origin-Kopie eigenständig, ohne das GitHub-Repository zu ändern.

So öffnest und reviewst du einen Cursor Origin Pull Request

Origin-Pull-Requests folgen demselben Ablauf aus Branch, Push und Review wie auf anderen Git-Hosts. Unser Leitfaden zu Pull Requests erklärt die Abfolge.

Einen Branch erstellen und eine Änderung pushen

Erstelle und pushe den Arbeits-Branch:

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 ist damit fertig. Der nächste Befehl gehört Origin.

Einen Pull Request mit der Origin-CLI eröffnen

Repository-Befehle leiten das Ziel aus dem Git-Remote origin ab. Führe origin pr create aus oder gib -R owner/repo an, um das Repository direkt zu setzen. Standardmäßig erstellt der Befehl einen Draft. Mit --status open erstellst du einen PR, der bereit für Reviews ist.

Einen Cursor Origin Pull Request reviewen

Die CLI enthält origin pr list, origin pr view, origin pr diff und origin pr checks. Ohne konfiguriertes CI gab origin pr checks in meinem Test No checks reported. aus und beendete sich mit Code 1.

Dieser Exit-Code ist relevant in Shell-Skripten mit set -e, da ein leerer Checks-Tab das Skript stoppen kann, obwohl der Pull Request selbst in Ordnung ist.

Pull-Request-Review mit vier Tabs. Bild: Autor.

In der Webansicht hat jeder Pull Request vier Tabs: Activity, Commits, Checks und Files Changed, plus Reviewer-Anfragen, Inline-Kommentare und Merge-Button. Die Webseite zeigt Merge-Konflikte an, und origin pr status --conflict-status meldet sie im Terminal.

Auch im Terminal kannst du origin pr merge nutzen. Auf einem in Origin gehosteten Repository erstellte Pull Requests bleiben auf Origin, während Aktivitäten auf einem gespiegelten Repository zurück zu GitHub gesendet werden.

Cursor Origin Teamzugriff und Repository-Berechtigungen

Berechtigungen in Origin existieren auf Codebase- und Repository-Ebene.

Codebase-Einstellungen vs. Repository-Einstellungen

Codebase-Einstellungen gelten teamweit: Wer Origin aktivieren, Repositories erstellen und Apps installieren darf. Repository-Einstellungen beziehen sich auf ein einzelnes Repository und decken General, Permissions, Rules und Protections sowie Apps ab. Cursors Docs weisen jedoch darauf hin, dass die Screens für Permissions und Rules gerade überarbeitet werden.

Wenn ein Teammitglied Origin nutzen kann, aber ein bestimmtes Repository nicht öffnen darf, prüfe die Berechtigungen dieses Repositories statt der teamweiten Einstellungen.

Internal vs. Private Repositories

Es gibt zwei Repo-Arten mit eingeschränktem Zugriff:

• Internal-Repositories sind für Teammitglieder mit Codebase-Zugriff sichtbar.
• Private-Repositories sind nur für Mitglieder sichtbar, die direkt oder über Codebase-Berechtigungen Zugriff erhalten. Beim Umschalten auf private bleibt die Person, die die Änderung vorgenommen hat, Admin.

So prüfst du Zugriffsrechte auf ein Cursor Origin-Repository

Der Befehl origin repo list zeigt alle Repositories, die für das aktuelle Konto sichtbar sind. Um zu prüfen, wer Zugriff auf ein Repository hat, öffne Settings und dann Permissions.

Best Practices für Cursor Origin

Drei Dinge sind bei der Arbeit mit Origin besonders wichtig:

• Bevor du ein Repository löschst oder neu konfigurierst, bestätige den vollständigen Wert owner/repo und prüfe seine Remotes.

• Vermeide -y, bis das Ziel eindeutig verifiziert ist.

• Die Permissions-Seiten von Cursor widersprechen sich teils. Prüfe die aktuellen Docs, bevor du Zugriffsänderungen automatisierst.

Cursor Origin vs. GitHub: Funktionsvergleich

Origin ist eng mit Cursors Agent-Workflow verzahnt, während GitHub ein breiteres Repository-Ökosystem abdeckt.

Git-Hosting, Pull Requests und CI/CD

Statt jede Sektion zu wiederholen, hier die Kurzversion der Aufteilung:

Die Agent-Zeile braucht etwas Kontext.

Cursor Origin vs. GitHub für Agent-Workflows

Beide Plattformen lassen Agents gegen Repositories arbeiten. Origin hält diese Schleife innerhalb von Cursor. GitHub bietet sie über das Agents-Panel und Copilot-Tools an, inklusive der allgemein verfügbaren CLI.

Wann du Cursor Origin, GitHub oder beides nutzt

• Nutze Origin, wenn das Repository internal oder private ist, der Großteil der Agent-Arbeit ohnehin in Cursor erfolgt und dein Deployment bzw. CI über Vercel, Depot oder Buildkite laufen kann.
• Behalte GitHub als primären Host, wenn das Projekt öffentlich ist, Issues und Actions zum Tagesgeschäft gehören oder dein Team vom GitHub-App-Marktplatz abhängt.
• Nutze beides, wenn du das Code-Browsing und den Agent-Workflow von Origin willst, ohne das Quell-Repository zu verschieben. Ein Mirror hält Pushes und Pull-Request-Aktivitäten an GitHub gebunden, während derselbe Code in Origin verfügbar ist.

Fazit

Ich bin von einer frischen WSL-Installation bis zu einem offenen Origin-Pull-Request gekommen, mit demselben Branch-, Commit- und Push-Flow wie bei GitHub. Die CLI hat Git nicht verändert. Die Unterschiede von Origin zeigten sich beim Hosting, bei Berechtigungen und beim Mirroring.

Nach der Nutzung würde ich Origin als GitHub-Begleiter behandeln, nicht als vollständigen Ersatz. Mirroring ist der praktikabelste Einstiegspunkt für ein bestehendes Repository, weil GitHub maßgeblich bleiben kann. Öffentliche Projekte und Actions-lastige Workflows haben weiterhin wenig Grund zu wechseln.

Passend dazu deckt unser Guide zu Cursor Automations Agent-Aufgaben ab, die gegen ein bestehendes Repository laufen. Unser Leitfaden zu GitHub und dessen Nutzung erklärt den GitHub-Workflow ausführlicher.