Cursor-Bootcamp Teil 3:
Advanced mit Hooks, MCP und Bugbot

Cursor-Bootcamp

Teil 3: Advanced

Foto: viarami / Pixabay

Teil 3 von 3: Die Module für Fortgeschrittene. Voraussetzung sind Teil 1 (Installation, Rules, AGENTS.md) und Teil 2 (Plan Mode, Checkpoints, Cloud Agents).

Du lässt den Agenten inzwischen Pull Requests schreiben. Jetzt stellt sich die Frage, wie du das im Team sicher, günstig und mit wenig Handarbeit betreibst. Dieser Teil liefert sechs Module mit Ziel, Übung und Prüfkriterium. Ein Modul braucht etwa eine Stunde.

Alle Funktionen, Dateinamen und Schlüssel stammen aus der Cursor-Dokumentation, abgerufen am 6. November 2026. Die Oberfläche ändert sich schnell. Abweichungen findest du im Changelog.

Das Wichtigste in Kürze

• Hooks machen Regeln durchsetzbar. Eine Rule bittet den Agenten, ein Hook-Skript kann einen Befehl mit Exit-Code 2 blockieren.
• Subagenten halten den Hauptkontext sauber. Jeder arbeitet in einem eigenen Kontextfenster und kann ein anderes Modell nutzen.
• Parallele Agenten brauchen getrennte Checkouts. Worktrees geben jeder Aufgabe eigene Dateien.
• Bugbot liest eigene Review-Regeln. Sie stehen in .cursor/BUGBOT.md, die Rules aus .cursor/rules gelten dort nicht.
• Auto-review ist kein Sicherheitsrand. Die Dokumentation sagt das ausdrücklich über den Klassifikator.

Offizielle Videos von Cursor (Englisch)

Cursor veröffentlicht seine Videos auf dem eigenen YouTube-Kanal @cursor_ai. Eine offizielle Videoserie für Fortgeschrittene fand die Recherche am 6. November 2026 nicht. Die Tabelle listet ausschliesslich offizielle Inhalte; alle Links öffnen die Videos mit englischer Oberfläche und englischen Untertiteln.

Modul 1: Cursor-Hooks als Leitplanken

Ziel: Ein Skript prüft jeden Shell-Befehl des Agenten, bevor er läuft.

Hooks sind Skripte, die an festen Stellen der Agentenschleife starten. Sie reden über stdin und stdout mit Cursor und tauschen JSON aus. Die Dokumentation nennt als Einsatz unter anderem Formatierer nach Änderungen, das Suchen nach Geheimnissen und das Sperren riskanter Operationen. Dazu gehören Ereignisse wie beforeShellExecution, preToolUse, afterFileEdit und stop.

Dabei liegt die Konfiguration als hooks.json im Ordner .cursor des Projekts oder im Home-Verzeichnis für alle Projekte. Cursor lädt sie bei Änderungen neu. Projekt-Hooks laufen aus dem Projektstamm, deshalb schreibst du dort .cursor/hooks/... als Pfad. Ein Beispiel, das nur bei Netzwerkbefehlen anspringt:

{
  "version": 1,
  "hooks": {
    "beforeShellExecution": [
      {
        "command": ".cursor/hooks/approve-network.sh",
        "timeout": 30,
        "matcher": "curl|wget|nc ",
        "failClosed": true
      }
    ]
  }
}

Dabei liest das Skript das JSON von stdin, nimmt das Feld command und antwortet mit permission als allow, ask oder deny. Exit-Code 2 blockiert die Aktion. Jeder andere Fehlercode lässt sie durch, sofern du nicht failClosed: true setzt. Bei Berechtigungs-Hooks blockiert auch ungültiges JSON die Aktion. Antworten mehrere Quellen, gewinnt deny vor ask und ask vor allow.

Zudem lohnt der Blick auf Cloud Agents. Sie laden Hooks aus dem Repository, aber nicht aus deinem Home-Verzeichnis. Einige Ereignisse gelten dort nicht: sessionStart, sessionEnd, beforeMCPExecution und afterMCPExecution. Sicherheitsrelevante Regeln gehören also ins Projekt und nicht in die persönliche Konfiguration.

Übung: Lege den Hook oben an. Das Skript soll curl auf eine Ausnahmeliste prüfen und alles andere mit deny ablehnen. Bitte den Agenten danach, eine Webseite per curl zu laden.

Geschafft, wenn der Agent den blockierten Befehl meldet und der Hook im Log den Aufruf zeigt.

Modul 2: MCP-Server anbinden

Ziel: Der Agent nutzt ein externes Werkzeug, etwa dein Ticketsystem, über das Model Context Protocol.

Dabei unterstützt Cursor drei Transportarten: stdio für lokale Prozesse, die Cursor startet, sowie SSE und Streamable HTTP für Server, die mehrere Nutzer bedienen. Über das Protokoll erreicht der Agent Tools, Prompts und Resources. Installiert wird über die Seite „Customize“ oder von Hand in mcp.json.

{
  "mcpServers": {
    "ticketsystem": {
      "url": "https://mcp.example.com/mcp",
      "headers": { "API_KEY": "${env:TICKET_KEY}" }
    }
  }
}

Die Schreibweise ${env:NAME} holt Werte aus Umgebungsvariablen, so landet kein Schlüssel im Klartext in der Datei. Verlangt der Anbieter OAuth mit festen Zugangsdaten, trägst du CLIENT_ID, optional CLIENT_SECRET und scopes unter auth ein. Für die Rückleitung nutzt Cursor feste Adressen, etwa http://localhost:8787/callback für den Desktop und https://www.cursor.com/agents/mcp/oauth/callback für Web und Cloud-Läufe.

Dabei trifft MCP auf Modul 1. Der Hook beforeMCPExecution kann Aufrufe einzelner Tools prüfen, läuft aber laut Dokumentation nicht in Cloud Agents. Dort fallen preToolUse und postToolUse mit dem Namen MCP:<tool_name> an, mit eingeschränkten Rechten. Admins verteilen geprüfte Server über einen Team-Marketplace.

Übung: Binde einen Server an, den dein Team nutzt, und lasse den Agenten eine lesende Abfrage ausführen. Prüfe danach, welche Tools der Server freigibt.

Geschafft, wenn der Agent ein Tool des Servers aufruft und du die Anfrage im Verlauf siehst.

Anthropic Academy: Introduction to Model Context Protocol

Modul 3: Subagenten und Skills

Ziel: Ein eigener Prüfer-Agent kontrolliert die Arbeit des Hauptagenten in einem getrennten Kontextfenster.

So sind Subagenten Markdown-Dateien mit YAML-Kopf. Projektweite liegen in .cursor/agents/, persönliche im gleichnamigen Ordner deines Home-Verzeichnisses. Diese Agenten starten mit leerem Kontext und liefern am Ende eine Zusammenfassung. Cursor bringt zwei eingebaute mit: Explore für die Codesuche mit einem schnelleren Modell und Browser für Aufgaben im eingebauten Browser.

---
name: verifier
description: Prüft fertige Arbeit. Nutze ihn, nachdem Aufgaben als erledigt gelten.
model: inherit
readonly: true
---

Du bist skeptisch. Führe die Tests aus, suche Randfälle
und melde, was bestanden ist und was fehlt.

Dabei sperrt readonly: true Dateiänderungen und Befehle, die etwas verändern. Mit is_background: true läuft der Subagent im Hintergrund. Beim Feld model wählst du inherit oder eine feste Modellkennung. So kann ein günstiges Modell die Suche übernehmen und ein stärkeres die Architekturfrage.

Ausserdem trennt die Dokumentation beide Mittel klar:

Cursor findet ihn unter .cursor/skills/ und liest zusätzlich die Ordner von Claude und Codex. Persönliche Exemplare im Home-Verzeichnis erreichen Cloud Agents nur nach einer Synchronisation.

Übung: Lege den Prüfer an und gib einen Auftrag, an dessen Ende der Agent ihn aufruft. Mit /create-subagent erzeugt Cursor die Datei auf Wunsch selbst.

Geschafft, wenn der Prüfer ohne deinen Hinweis läuft und seinen Bericht an den Hauptagenten zurückgibt.

Cursor Learn: Customizing Agents

Anthropic Academy: Introduction to subagents

Modul 4: Parallel arbeiten mit Worktrees

Ziel: Zwei Agenten bearbeiten dasselbe Repository gleichzeitig, ohne sich zu stören.

So ist ein Worktree ein getrennter Git-Checkout. Jeder Auftrag bekommt eigene Dateien, Abhängigkeiten und Änderungen, während dein Hauptordner unberührt bleibt. Die Oberfläche dafür gibt es im Agents Window. Im Editor nutzt du die Worktree-Skills. Ebenfalls dort laufen viele Cloud Agents parallel und lassen sich zwischen lokal und Cloud verschieben.

Damit ein frischer Worktree arbeiten kann, braucht er Abhängigkeiten und Konfiguration. Das steuert .cursor/worktrees.json:

{
  "setup-worktree": [
    "npm ci",
    "cp $ROOT_WORKTREE_PATH/.env .env"
  ]
}

Für Unix und Windows gibt es eigene Schlüssel, setup-worktree-unix und setup-worktree-windows. Der generische Schlüssel dient als Rückfall. Die Dokumentation rät davon ab, Abhängigkeiten per Symlink einzubinden, weil das den Hauptordner stören kann. Schnelle Paketmanager wie pnpm, bun oder uv sparen Zeit.

Übung: Starte zwei Aufträge in getrennten Worktrees, etwa Tests für Modul A und eine Doku für Modul B. Prüfe die Ergebnisse einzeln im Diff.

Geschafft, wenn beide Agenten fertig sind, dein Hauptordner unverändert ist und du beide Ergebnisse getrennt übernehmen kannst.

Modul 5: Bugbot und Automations

Ziel: Jeder Pull Request erhält ein automatisches Review nach deinen Regeln.

Dabei liest Bugbot die Diffs eines Pull Requests und kommentiert Fehler, Sicherheitsprobleme und Qualität. Er läuft bei jedem Update oder auf Zuruf mit cursor review oder bugbot run als Kommentar. Verbunden wird er über das Cursor-Dashboard mit GitHub, GitLab, Bitbucket, Azure DevOps oder Origin. Auf GitHub schaltet das Verbinden die gewählten Repositories sofort frei, bei den anderen Anbietern aktivierst du jedes Repository einzeln.

Deshalb sind seine Grenzen wichtig. Zu grosse Pull Requests überspringt Bugbot und bittet um eine Aufteilung. Als linguist-generated markierte Dateien lässt er aus. Die Prüfung erscheint als Check „Cursor Bugbot“ mit diesen Ergebnissen:

Wer Merges blockieren will, schaltet die Option für fehlschlagende Checks ein, sofern sie die Organisation anbietet, und verlangt den Check im Branch-Schutz.

Daher schreibst du seine Regeln in eine BUGBOT.md im Ordner .cursor. Die Datei im Projektstamm gilt immer, dazu kommen Fassungen aus den Unterordnern der geänderten Dateien. Cursor-Rules (*.mdc) gelten für Bugbot nicht. Mit @cursor remember [Fakt] im Kommentar speichert er Hinweise als gelernte Regel. Pro Regel gelten 30.000 Zeichen, insgesamt 100.000.

Automations laufen als Cloud Agents nach Zeitplan oder bei Ereignissen aus GitHub, GitLab, Slack, Linear oder per Webhook. Du legst sie im Agents Window, auf cursor.com/automations oder mit dem Skill /automate an. Dabei bestimmt die Einstellung „Run as“ die Abrechnung: Auf „Me“ zahlst du, bei einem Dienstkonto zahlt der Team-Pool.

Übung: Aktiviere Bugbot für ein Test-Repository und schreibe eine BUGBOT.md mit zwei Regeln. Öffne dann einen Pull Request mit einem absichtlichen Fehler.

Geschafft, wenn Bugbot den Fehler kommentiert und dabei deine Regel nennt.

Cursor Learn: Reviewing and Testing Code

Modul 6: Sicherheit und Kosten im Blick

Ziel: Du kennst deinen Ausführungsmodus, deine Nutzung und die Obergrenze, die niemand überschreitet.

Unter Settings > Agents > Approvals & Execution wählst du den Modus. Teil 2 hat die Wahl zwischen Auto-review, Allowlist und Run Everything erklärt. Fortgeschrittene steuern Auto-review über eine Datei permissions.json. Sie liegt im Home-Verzeichnis für alle Projekte oder im Projekt für ein ganzes Team, und Cursor führt beide zusammen. Du kannst dem Agenten auch direkt sagen, welche Befehle immer eine Freigabe brauchen. Er ändert die Datei selbst.

Die Dokumentation warnt: Auto-review ist keine Sicherheitsgrenze, denn der Klassifikator macht Fehler. Er benötigt ein kleines Cursor-Modell und als Rückfall Haiku. Auf Team-Tarifen musst du deshalb das Haiku-Modell in den Team-Einstellungen freigeben, sonst ist der Modus grau.

Zudem gilt für Cloud Agents der Datenschutz. Sie laufen im Privacy Mode. Cursor trainiert nach eigener Angabe nicht auf Code, Prompts oder Antworten, und der alte Privacy Mode wird nicht unterstützt. Admins erzwingen den Standardmodus für das ganze Team.

Zur Nutzung: Bezahlte Tarife enthalten einen wöchentlichen Pool für Cursor-eigene Modelle, der für Editor, CLI und Cloud-Läufe gemeinsam gilt. Modelle von Anthropic, OpenAI oder Google rechnet Cursor ab Premium zum Listenpreis der Anbieter aus deinem Guthaben ab. Ein monatliches Limit für zusätzliche Nutzung deckelt die Ausgaben, egal wie viel Guthaben vorhanden ist. Deine Restmenge steht in den Editor-Einstellungen.

Übung: Öffne die Nutzungsanzeige, lege das monatliche Limit fest und schreibe in permissions.json eine Regel für einen Befehl, den du immer prüfen willst.

Geschafft, wenn du aus dem Kopf sagen kannst, welchen Modus du nutzt, was ein Cloud-Lauf kostet und wo dein Limit steht.

Cursor Learn: Tokens & Pricing

Achtung, Modell wechselt von selbst: Öffnest du ein neues Fenster, einen neuen Tab oder einen neuen Chat, kann Cursor das gewählte Modell austauschen, zum Beispiel von Composer 2.5 Fast auf ein teureres Modell. Das läuft ohne Rückfrage, und wer nicht hinschaut, bezahlt die nächsten Aufträge mit dem höheren Preis. Im Cursor-Forum ist das als Fehler gemeldet, etwa unter „Opening a New Tab Automatically Switches Model“ und „Auto model is overridden … on new agent chats“. Prüfe deshalb vor jedem Auftrag in einem neuen Kontext die Modellauswahl und setze das Standardmodell in den Einstellungen fest.

Kostensteuerung und das Optimieren von Agenten bekommen einen eigenen Artikel, den wir bereits planen.

Einordnung: Was das für Entwickler und Admins heisst

Der Sprung von Teil 2 zu Teil 3 verschiebt den Aufwand vom einzelnen Auftrag zur Umgebung. Wer Hooks, Review-Regeln und Limits einmal sauber setzt, kann mehrere Agenten laufen lassen und verliert trotzdem nicht den Überblick. Das spart Nacharbeit und senkt das Risiko, dass ein Agent etwas ausführt, das niemand wollte. Admins sollten Modul 6 zuerst angehen, weil Limit und Datenschutz für alle anderen Module gelten.

Fazit

Teil 3 macht aus dem einzelnen Agenten einen kontrollierten Betrieb. Beginne mit einem Hook für Befehle und einem Limit für die Ausgaben. Danach lohnen sich Subagenten und Bugbot. Parallele Worktrees und Automations folgen, sobald die Leitplanken stehen. Weitere Artikel zum Werkzeug sammelt der Cursor-Fahrplan.

Zurück zu Teil 1 und Teil 2.

Quellen: Hooks, MCP, Subagents, Skills, Worktrees, Agents Window, Bugbot, Automations, Run Modes, Cloud-Agent-Sicherheit, Modelle und Preise. Foto: viarami / Pixabay. Stand: 6. November 2026.

Geschrieben von Andreas Brauckmann · So arbeitet die Redaktion