Was Cavvy an Agenten ändert

Cavvy startet deine Agenten, wie sie sind: das offizielle Claude Code, Codex, opencode und Gemini CLI, mit ihren eigenen Logins und Einstellungen. Wo es etwas hinzufügt, sagt diese Seite, was, im Wortlaut, und wie du es abschaltest. Alle Schalter stehen unter Einstellungen → Agenten → Was Cavvy an Agenten ändert, sind von Haus aus an und gelten für Sitzungen, die danach starten, auf jedem Server.

Claude Code: Werkzeugaufrufe melden

Cavvy gibt Claude Code ein --settings mit vier Hooks mit: PreToolUse, PostToolUse, UserPromptSubmit und Stop. Jeder ruft cavvyd record-tool auf, das den Aufruf für Cavvy vermerkt und immer gelingt; ein Hook blockiert also nie ein Werkzeug.

Was es dir bringt: Fragen und Freigabe-Anfragen von Claude Code stehen lesbar über dem Terminal, und Cavvy weiß genau, wann Claude Code auf dich wartet. Siehe Leitstand.

Aus: Fragen und Freigaben erscheinen erst, wenn Cavvy sie am Bildschirm liest, später und ungenauer. Eine Sitzung, die mit eigenem --settings startet, bekommt nie Hooks.

Claude Code und Codex: Regeln des Tasks anhängen

In einem Task hängt Cavvy Regeln an die Anweisungen des Agenten: bei Claude Code mit --append-system-prompt (außer die Sitzung bringt ein eigenes mit), bei Codex als developer_instructions. Die beiden Schalter Claude Code: Regeln des Tasks anhängen und Codex: Regeln des Tasks anhängen wirken unabhängig voneinander.

In einem Task in einem Repo lauten die Regeln so, mit deinem Basis-Branch an Stelle von main:

You work in a Cavvy task: a git worktree whose branch started from main. Commit your work on this branch. Don’t merge it into main or any other branch, don’t push, and don’t open a merge or pull request, even when the work looks done: the user reviews the task and finishes it in Cavvy, which runs the project’s checks first. If the user asks you to merge, tell them to use Finish… in Cavvy (German: Abschließen…), unless they insist.

In einem Projekt folgt, mit seinem Namen und seinen weiteren Repos:

This task belongs to the Cavvy project “Shop”. Its other repositories: shop-api, shop-docs. If the task needs changes in another repository, run cavvy task add <repo>: it makes a worktree of it on this task’s branch and prints its path; work and commit there, never in the repository’s own folder. Another repository on this machine is taken in by its path (cavvy task add <path>), one that isn’t here yet by cloning it (cavvy task add --clone <url>); it then joins the project. Take in only what the task needs; the user sees every repository you take in. cavvy repos lists them. A part can have a session of its own, which cavvy projects and cavvy task add name. Don’t change such a part yourself, nor through subagents: hand that session the work with cavvy send <id> "…", then cavvy wait <id> for it to finish, and read the result in its worktree.

Ein Agent, dessen Task kein Repo oder mehrere anfasst, arbeitet in einem Task-Ordner und bekommt:

You work on a task in the Cavvy project “Shop”. This folder isn’t a git repository; files directly in it are lost when the task ends. The project’s repositories: shop-web, shop-api, shop-docs. Taken in already: shop-web/, shop-api/. For each repository the work needs, run cavvy task add <repo>: it makes a worktree of it inside this folder on the branch feature/checkout and prints its path; work and commit there, never in the repository’s own folder. Another repository on this machine is taken in by its path (cavvy task add <path>), one that isn’t here yet by cloning it (cavvy task add --clone <url>); it then joins the project. Take in only what the work needs; the user sees every repository you take in. cavvy repos lists them. Don’t merge, don’t push, and don’t open merge or pull requests, even when the work looks done: the user reviews each repository’s part and finishes the task in Cavvy, which runs the checks first. If the user asks you to merge, tell them to use Finish… in Cavvy (German: Abschließen…), unless they insist. A part can have a session of its own, which cavvy projects and cavvy task add name. Don’t change such a part yourself, nor through subagents: hand that session the work with cavvy send <id> "…", then cavvy wait <id> for it to finish, and read the result in its worktree.

Jede Fassung endet mit:

When the work you were asked for is finished and nothing is left for you to do, run cavvy done as your very last step: only then does Cavvy show the task as ready for review. Don’t run it when you stop to ask something, to report progress, or while work is still open.

Die Regeln sind englisch, gleich in welcher Sprache Cavvy angezeigt wird.

Sinngemäß: Committe auf dem Branch des Tasks. Merge nicht, pushe nicht und öffne keinen Merge oder Pull Request, auch wenn die Arbeit fertig aussieht: Der Mensch prüft den Task und schließt ihn in Cavvy ab, das vorher die Prüfungen des Projekts laufen lässt. Bittet er dich ums Mergen, verweise ihn auf Abschließen… in Cavvy, außer er besteht darauf. Hat ein Teil eine eigene Sitzung, übergib ihr die Arbeit mit cavvy send und warte mit cavvy wait. Ist die verlangte Arbeit fertig, ruf als allerletzten Schritt cavvy done auf, nicht schon, wenn du nur etwas fragst oder einen Zwischenstand meldest.

Was es dir bringt: Der Agent weiß, dass du mergst, welche Repos er für einen Task über mehrere Repos holen kann, und sagt Cavvy mit cavvy done, wann seine Arbeit fertig ist.

Aus: Der Agent kennt weder die Regeln noch die anderen Repos, und Cavvy hält ihn für fertig, sobald er anhält.

Was die Regel ist, und was nicht

Die Regel ist eine Anweisung an den Agenten, kein Schloss. Ein Agent, der sie übergeht oder den du zum Pushen aufforderst, kann in seinem Worktree trotzdem git push ausführen; Cavvy hält ihn nicht auf. Was Cavvy zusichert, ist seine eigene Seite: Cavvy selbst mergt, pusht die Basis oder öffnet einen Merge Request nur, wenn du es unter Abschließen… wählst, in einem Dialog, nie per Kürzel und nie von selbst.

Agenten, die über einen Umweg wie npx starten, bekommen keine Regeln, weil Cavvy nur die Befehle claude und codex erkennt.

Immer, ohne Schalter

Das ändert nichts daran, was ein Agent tut, gehört aber zu jeder Sitzung:

• Der Hintergrunddienst legt sein eigenes cavvy in den PATH der Sitzung und setzt CAVVY_SESSION_ID, damit die CLI weiß, welche Sitzung sie aufruft.
• Claude Code und Gemini CLI starten mit einer Sitzungs-ID, die Cavvy wählt, damit das Gespräch nach einem Neustart weitergehen kann. Siehe Agenten.
• Auf dem Mac finden Sitzungen security unter /usr/bin/security, damit Agenten ihre Logins aus dem Schlüsselbund lesen können. Siehe Schlüsselbund & Diagnose.

opencode und Gemini CLI bekommen weder Hooks noch Regeln.

Die Grundsätze dahinter

• Nichts geschieht unbemerkt. Holt ein Agent ein Repository dazu, steht es sofort in der Liste, ungelesen, mit Mitteilung und im Verlauf.
• Du siehst, wer was veranlasst hat. Jeder Task hat seinen Verlauf, über alle seine Repos.
• Eingreifen geht jederzeit: Task anhalten…, Repo holen, Zurückgeben… mit Notiz, Zeilenkommentare als Prompt.
• Nichts landet ohne dich im Hauptzweig. Mergen hat kein Tastenkürzel, es ist immer ein Dialog.
• Folgenreiches nie von selbst. Bei roter Prüfung heißt der Knopf Trotzdem nach … mergen, in Rot; eine Zweite Meinung läuft von selbst höchstens zweimal.
• Grenzen sind sichtbar und einstellbar, auf dieser Seite.