Einführung der Cursor CLI

 (cursor.com)
5 Punkte von GN⁺ 2025-08-08 | 1 Kommentare | Auf WhatsApp teilen
  • Cursor Agent ist jetzt auch in CLI- oder Headless-Umgebungen einsetzbar, sodass er mit denselben Befehlen in IDE oder Terminal verwendet werden kann
  • Im Terminal sind Code-Überprüfung von Agent-Änderungen, Echtzeit-Arbeitsanleitung und Festlegen benutzerdefinierter Regeln möglich
  • Unterstützung für die Nutzung aktueller KI-Modelle (Anthropic, OpenAI, Gemini usw.), Integration mit gewünschter IDE sowie Erstellung von Skripten und Automatisierungstasks
  • Neben der nativen Umgebung sind paralleles Ausführen von Agenten und Remote-Ausführung möglich, ebenso die Anbindung an verschiedene Entwicklungsumgebungen
  • Die CLI verfügt über die Rechte für Dateien lesen, ändern, löschen und Befehle ausführen, daher wird der Einsatz nur in vertrauenswürdigen Umgebungen empfohlen

Überblick zu Cursor Agent CLI

Unterstützung für CLI- und Headless-Umgebungen

  • Cursor Agent kann in einer CLI- oder Headless-Umgebung ausgeführt werden
  • Integration mit verschiedenen Entwicklungsumgebungen wie IDEs (Neovim, JetBrains etc.), Terminal, Remote-Servern und mehr
  • Dieselbe Befehlssammlung kann an jedem Ort verwendet werden
  • Beispiel: Cursor, JetBrains, Android Studio, Ghostty, Warp, Bash, Xcode

Hauptfunktionen

  • Code-Überprüfung: Änderungen, die der Agent im Terminal vorschlägt, können dort direkt geprüft und übernommen werden
  • Echtzeit-Anpassung: Die Arbeit des Agenten kann während der Ausführung begleitet und angepasst werden
  • Benutzerregeln festlegen: Detaillierte Regeln über AGENTS.md und MCP individuell anpassen
  • Aktuelle KI-Modelle nutzen: Sofortige Nutzung von Anthropic, OpenAI, Gemini und weiteren aktuellen Modellen
  • Automatisierungsunterstützung: Automatische Dokumentenaktualisierung, Auslösung von Sicherheitsprüfungen, Erstellung eines eigenen Coding-Agenten usw.

Produktentwicklung

  • Initial: intelligente, kontextbewusste Textvervollständigung
  • Danach: KI-basierte Fragestellungen und Inline-Codeanpassung (⌘+K)
  • Nach verbesserter Code-Generierungsqualität erweitert auf Datei-Erstellung, Ausführung von Terminal-Befehlen und Durchsuchen der Codebasis
  • 2025: Ausbau des Agent von Editor auf Web, Mobile und Slack
  • Gegenwärtig: Erweiterung auf CLI- und Headless-Umgebungen

Beispiel für Installation und Ausführung der CLI

# Installation  
curl https://cursor.com/install -fsSL | bash  
  
# CLI über Prompt starten  
cursor-agent chat "find one bug and fix it"
  • Die CLI ist noch in der Beta-Version
  • Die Sicherheitsfunktionen werden noch ausgebaut; da sie Dateizugriff und Befehlsausführung erlaubt, sollte sie nur in vertrauenswürdigen Umgebungen verwendet werden

Hinweis

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-08-08
Hacker News Kommentare

  • Ich bin mir nicht sicher, wo man das jenseits einer virtualisierten, ungenutzten Umgebung sinnvoll einsetzen sollte. Besser wäre es, wenn es in einer VM mit begrenztem Speicherplatz läuft. Ich werde einem LLM nie mehr Rechte als Lesezugriff auf eine Festplatte geben, die ich besitze oder verwalte.

  • Ich frage mich, wann wir alle auf das AGENT.md-Konzept umstellen und statt Namen wie gemini.md/claude.md/crush.md/summary.md/qwen.md einen Standard verwenden. Siehe agent.md (Weiterleitung: https://ampcode.com/AGENT.md); es gibt auch agent-rules.org.

    • Der Name wirkt intuitiver als das, was ich nutze, aber auch weniger spaßig. Ich nutze aktuell ein Symbolic Link auf eine ROBOTS.md-Datei.
    • Das ist auch einer meiner Kritikpunkte. Ich habe auch auf AGENT.md vereinheitlicht und Claude, Gemini usw. als Aliase gesetzt, die beim Aufruf immer diese Datei lesen. Das Problem ist, dass der Agent das schnell vergisst. Ich glaube, die agentic-Coding-Erfahrung in der CLI könnte so verbessert werden: (1) Es sollte leicht möglich sein, die zuletzt ausgeführten Befehle nachzuvollziehen, und (2) eine Sandbox für unattended Sessions müsste man einfach hochfahren können. Vielleicht braucht man für Code-Generierung nicht einen KI-gesteuerten, sondern einen durch KI unterstützten und deterministischen Codegenerator.
    • Ich glaube, einige Anbieter werden wie Microsoft in den 90ern eine proprietäre Haltung haben und auf neue Konventionen wie eine aufkommende Standardisierung setzen weniger Wert legen. In der CLI gibt es schließlich Workarounds, sodass man alles irgendwie über das Einlesen der System-Guidelines nutzen kann, aber in IDEs ist das Lock-in durch Konfigurationsdateien deutlich stärker. Ich habe kürzlich auch einen Beitrag darüber geschrieben, wie man denselben Guideline-Text an jeden AI-Coder verteilt; deshalb teile ich auch den Case-Study-Link.
    • Die Idee der AGENT.md-Standardisierung gefällt mir. Mir scheint sie passt aber nicht gut zu einer Struktur wie .cursor/rules/, in der mehrere Rules-Dateien je nach Frontmatter-Bedingung eingebunden werden. Ich weiß nicht, ob andere Agents das unterstützen, und bei Cursor ist es schwer vorherzusagen, welche Rule-Dateien genau gelesen werden. Es gibt zwar auch die Möglichkeit, auf zusätzliche Rules-Dateien zu verlinken, aber ich weiß nicht, ob es einen Agenten gibt, der das ordentlich unterstützt.

  • Die Veröffentlichungsgeschwindigkeit von AI-Coding-Agents ist inzwischen genauso hoch wie bei JavaScript-Frameworks. Aber ehrlich gesagt finde ich diese Entwicklung ziemlich erfrischend.

    • Wenn man bedenkt, wie viele JavaScript-Frameworks man heute im Sinne von Vibe-Coding nutzen kann, ist das ziemlich interessant.

  • Ganz überraschend: Ich hätte nicht gedacht, dass ein terminalbasierter Coding-Agent so viel Spaß macht. Man kann einen im Hintergrund laufen lassen und dabei #dayjob machen; der zusätzliche „hackerhafte“ Effekt kommt dazu. 2025 wird vermutlich als das Jahr des Terminals in Erinnerung bleiben. Für meine Prototyping-Zwecke passt das perfekt, und aus dieser Sicht war Claude Code die angenehmste Erfahrung, die ich bisher gemacht habe.

  • Ich halte den aktuellen CLI-Ansatz für eine gute Idee. Der nächste Abstraktionsschritt wird wohl so aussehen, dass jemand in einem GitHub-PR ein Issue oder einen Feature Request erstellt (wahrscheinlich ich) und mit einem Klick löst der Agent die Aufgabe automatisch. Bei GitHub gab es bereits ähnliche Diskussionen, aber deren gh copilot ist so vielfältig, dass ich nicht wusste, ob es GA ist und ob ich Zugriff habe. (Zur Referenz: Die offizielle Doku ist vorhanden, aber nicht so rasant wie gedacht.)

  • Es ist spannend zu sehen, wie AI-Agenten die Definition von IDE neu schreiben. Während der Chat-AI-Phase gab es diesen Trend nicht. Je autonomer ein Agent sich bewegen kann, desto unwichtiger wird die klassische IDE-UI. Ich denke, CLI-Tools können ein neues Ökosystem an Entwicklerwerkzeugen schaffen. Vollständige IDE-Plugins für VSCode, IntelliJ usw. zu bauen ist wirklich schwierig, und die Kompatibilität zwischen IDEs ist ebenfalls nicht ideal. CLI-Tools und MCP dagegen sind deutlich einfacher und deutlich einfacher zu kombinieren/zu portieren.

  • Ich glaube, Cursor wird langfristig das stärkste Toolkit werden.

    1. Durch die enge Integration von CLI, Background-Agent, IDE und GitHub App (bugbot etc.) wird ein End-to-End-Entwicklererlebnis entstehen.
    2. Wenn Frontier-Modelle die Workload-Verteilung internalisieren, verliert Claude Code seinen Sonderstatus.
    3. Es braucht die Philosophie, die Wechselkosten zwischen Modellanbietern so niedrig wie möglich zu halten (Unterstützung für unabhängige Anbieter), damit der Anreiz klar auf die Verbesserung der Modelle gerichtet bleibt. Nicht UI-, Daten- oder Netzwerk-Lock-in sollte Kern des Spiels sein, sondern der Wettlauf zwischen Modellen.
    • Ich setze auf das Gegenteil. Echte Agentic-Harness kommt meiner Meinung nach im Zusammenspiel mit RL-Training hervor, wie bei dem Entstehungsprozess von Tony und dem Suit. Dass Claude Code in Cursor existenziell wichtig ist und dass Cursor so schnell auf Agentic setzten und später sogar mit OpenAI kooperieren wollte, hängt genau damit zusammen. Cursor dürfte es am Ende schwer haben, ohne Partnerschaften mit OpenAI oder Meta.

  • Komische Situation: Ich hatte gehofft, dass Anthropic eine „Claude GUI“ baut.

    • Bei der Claude-Code-Ansprache habe ich gehört, dass sie gesagt hätten, eine GUI mache keinen Sinn, wenn bald alle IDEs überflüssig werden.
    • Ich frage mich, ob das nicht Claude Desktop war.

  • Nun sind viele Frontier-Labs in diesen Markt eingestiegen und geben ihren Consumer-Abos über die CLI frei. In diesem Fall ist mir nicht klar, wie ein Produkt wie Cursor überleben kann. Wenn Funktionen bereits in den OAI/Anthropic/GOOG-Abos enthalten sind, warum sollte man dafür zusätzlich zahlen?

    • Ich habe das Gegenteil gedacht. Wenn Cursor für jede Situation die beste UX bietet (Mobile-/Desktop-Chatbots, Assistant, IDE/CLI/Web-Container-Coding-Agents usw.), könnten durch unterschiedliche Ressourceneinsätze besser ausgearbeitete Produkte entstehen. Wenn Cursor erst einmal Marktanteile aufgebaut hat, werden Modelle faktisch zu Commoditys, und man kann sie in Cursor situativ auswählen. Letztendlich lernen Nutzer Cursor-Befehle und Einstellungen, dadurch werden die Wechselkosten hoch. Schon Installation und Deinstallation anderer Apps/Plugins sind mühselig.
    • Ich denke, Cursor braucht eine aggressive und differenzierte Strategie, um zu überleben. Gleichzeitig wird durch Cursor die Kommodisierung der Modelle der einzelnen Labs gefördert. Ich zahle sowohl für Cursor als auch für ChatGPT. Auf Android hätte ich wahrscheinlich auch Gemini dazugebucht. Chatbots haben (1) eine geringere Subskriptionskonkurrenzkraft als API-Modelle, und (2) im heutigen Markt ist es nicht mehr die Modellqualität, sondern die UX, die entscheidet. Letztlich sind die Gewinner im Chatbot-Markt ChatGPT und standardmäßig integrierte Produkte (Gemini, MSFT Copilot).
    • Das liegt daran, dass man jederzeit das beste Modell wählen kann: Gestern war es Claude Opus 4.1, heute GPT-5. Wenn man nur Anthropic bezahlt, bleibt man auf Claude fixiert.

  • Ich frage mich, worin der Vorteil gegenüber klassischen IDEs liegt und ob das so gebaut wurde, um Claude Code ähnlich zu sein.

    • Ändert man den Denkrahmen leicht: Braucht ein Agent überhaupt eine IDE, wenn er Code schreibt? IDE/Editor ist für mich gedacht und nicht etwas, das ein Agent zwangsläufig nutzen muss. Das heißt nicht, dass ich gezwungen wäre, eine schlecht unterstützte geforkte IDE zu benutzen.
    • Viele Unternehmen haben inzwischen gelernt, dass mainline VSCode im Grunde ein Eintrittstor im Sinne eines Moats ist. Meine Umgebung und mein Umfeld nutzen eher selten Agents, die einen VSCode-Fork brauchen. Der Vorteil ist, dass man eher Jetbrains- und terminalbasierte Editor-Anwender mitnehmen kann.
    • Man kann IDEs jenseits von VSCode nutzen.
    • Man kann Cursor CLI im Terminal der gewünschten IDE starten und muss nicht auf Claude-Modelle beschränkt sein.
    • Ich frage mich immer noch: Warum bringt Cursor diese Funktionen nicht direkt ins Produkt, statt sie separat anzubieten?