Best Practices für Claude Code

Holen Sie mehr aus Claude Code heraus: Sagen Sie Claude, was es nicht sehen kann, geben Sie ihm eine Prüfung zum Ausführen, und setzen Sie die Regeln durch, die keine Ausnahmen haben dürfen.

Claude Code ist so aufgebaut, dass in den meisten Fällen bereits Ihr erster einfacher Prompt in einer neuen Sitzung das Richtige tut, ohne dass Sie etwas einrichten müssen.

Zum Beispiel:

• Damit Befehle sicher ausgeführt werden, ohne dass Sie jeden einzeln genehmigen, starten neue Terminal- und VS Code-Sitzungen im Auto-Modus, in dem ein Klassifikator alles Riskante prüft, bevor es ausgeführt wird.
• Damit Ihre Hauptkonversation fokussiert bleibt, während unabhängige Arbeit parallel erledigt wird, delegiert Claude an Subagenten und meldet sich nur, wenn es nötig ist.
• Damit eine lange Sitzung weiterläuft, ohne dass Sie sich darum kümmern müssen, wird Ihre Konversation automatisch komprimiert, bevor sich das Kontextfenster füllt.

Diese Seite behandelt, was zu tun ist, wenn die Standardeinstellungen nicht ausreichen. Das passiert meist, wenn Ihr Projekt Wissen, Regeln oder Einschränkungen hat, die Claude allein aus dem Code nicht erkennen kann:

• Ein Deploy-Prozess, der nur im Kopf einer Person existiert
• Eine Datei, die niemals gelesen werden darf
• Eine Prüfung, die bestanden sein muss, bevor etwas als erledigt gilt
• Ein Budget, das Sie einhalten müssen

Keine Standardeinstellung kann diese Dinge über Ihr Projekt wissen, daher lohnt sich hier ein wenig Einrichtung auf Ihrer Seite.

Wenn eine Sitzung nicht so verläuft, wie Sie es erwartet haben, liegt es fast immer an einem dieser Punkte:

• Claude hat etwas anderes gebaut, als Sie im Sinn hatten, oder muss zu Beginn jeder Sitzung dieselbe Tatsache neu herausfinden. Ihm fehlen Informationen, die es durch Lesen des Repos nicht bekommen kann. Siehe Sagen Sie Claude, was es nicht sehen kann.
• Claude sagte, es sei fertig, und das stimmte nicht ganz, meist weil es keine Möglichkeit hatte, die eigene Arbeit zu prüfen. Siehe Geben Sie Claude eine Prüfung zum Ausführen.
• Claude hat etwas getan, das in diesem Repo niemals passieren darf, oder einen Schritt übersprungen, der immer passieren muss. Ein Prompt allein kann keines von beidem garantieren. Siehe Setzen Sie die Regeln durch, die keine Ausnahmen haben dürfen.
• Claude hat es richtig gemacht, aber es hat mehr Zeit, Token oder Berechtigungsabfragen gekostet, als die Aufgabe wert war. Siehe Ändern Sie eine Standardeinstellung.

Lassen Sie Claude ohne Sie arbeiten wendet dieselben vier Punkte auf unbeaufsichtigte Läufe an, und Was Sie nicht mehr tun müssen listet die Ratschläge auf, die aktuelle Modelle überflüssig gemacht haben.

[!NOTE]

Die Einrichtung für ein ganzes Team wird auf einer eigenen Seite behandelt: Claude Code für Ihre Organisation einrichten.

Deterministische und nicht deterministische Anweisungen

Jede Anweisung, die Sie Claude Code geben, gehört zu einer dieser Arten:

1. Nicht deterministisch: Sie schreiben die Anweisung, und Claude (das Modell) liest sie. Das kann Ihr Prompt, CLAUDE.md oder ein Skill sein. Das Modell entscheidet dann, was es mit dieser Information macht. Es folgt Ihren Anweisungen in der Regel, und aktuelle Modelle verstehen Ihre Absicht auch ohne viel Kontext gut, aber es gibt keine Garantie, dass es Ihren Anweisungen folgt. Es kann trotzdem entscheiden, Dinge nicht zu tun oder andere Dinge zu tun.
2. Deterministisch: Sie konfigurieren die Anweisung, und Claude Code (der Harness) muss sie ausführen. Das kann ein Hook, eine deny-Regel oder eine verwaltete Einstellung sein. Claude Code wendet dies jedes Mal an, unabhängig davon, was das Modell entschieden hat.

Die meisten Dinge in Claude Code gibt es in beiden Formen:

Meistens möchten Sie, dass Claude entscheidet. Fast jede Richtlinie hat Ausnahmen, und aktuelle Modelle können den vorliegenden Code gut lesen und beurteilen, ob eine Richtlinie zur Situation passt. Mit dem tatsächlichen Code vor Augen ist Claude meist besser in der Lage, diese Entscheidung zu treffen, als eine Regel, die Sie im Voraus geschrieben haben.

Die deterministische Art ist für Fälle gedacht, in denen Sie sicherstellen möchten, dass bestimmte Dinge immer passieren (oder nie), unabhängig davon, was das Modell entscheidet. Das muss nichts Dramatisches sein. Der Auto-Modus blockiert die dramatischen Dinge bereits, etwa ein Production-Deployment oder einen Force-Push über die Arbeit anderer. Meist ist es etwas, das speziell Ihr Projekt betrifft, und es kann so speziell sein, wie Sie möchten:

• Den generierten Client in src/gen/ nie bearbeiten
• Nach dem Erstellen einer Datei immer das Lizenz-Header-Skript ausführen

Sie hätten beides als Zeile in CLAUDE.md oder in Ihrem Prompt schreiben können, und Claude würde dem fast jedes Mal folgen. Aber egal wie nachdrücklich Sie es formulieren: Ob Claude dieser Zeile in einem bestimmten Turn folgt, bleibt Claudes Entscheidung.

[!TIP]

Wenn Sie einer Zeile in CLAUDE.md immer mehr Nachdruck verleihen und Claude sie trotzdem übersieht, ist das ein Zeichen, dass die Zeile in einen Hook gehört. Umgekehrt gilt es ebenso: Wenn Sie Hooks für Dinge haben, die nur Vorlieben sind, löschen Sie sie und lassen Sie Claude entscheiden.

Sagen Sie Claude, was es nicht sehen kann

[!TIP]

Schreiben Sie nur auf, was Claude beim Lesen des Repos nicht finden kann oder was es sonst in jeder Sitzung erneut herausfinden müsste.

Claude beginnt jede Aufgabe damit, Ihren Code zu lesen, und aktuelle Modelle sind darin sehr gut. Sie finden Ihre Dateistruktur, Ihre Konventionen, Ihr Test-Framework und wie bestehende Komponenten aufgebaut sind, meist schneller, als Sie es erklären könnten. Das heißt, Claude weiß bereits das meiste von dem, was Sie vielleicht für es aufschreiben wollten.

Was es nicht finden kann, sind Informationen, die nie im Repo standen:

• Eine Entscheidung, die Ihr Team in einem Meeting getroffen hat
• Ein Deploy-Prozess, der nur im Kopf einer Person existiert
• Die Umgebungsvariable, die Ihre Integrationstests benötigen

Es gibt auch Informationen, die zwar im Repo stehen, deren Suche aber ein paar Minuten dauert, und Claude muss diese Suche zu Beginn jeder Sitzung wiederholen.

Ein guter Test, bevor Sie etwas für Claude aufschreiben:

1. Könnte es das durch Lesen des Codes finden?
2. Würde es tatsächlich nachsehen?

Wenn beides zutrifft, lassen Sie es weg.

Schreiben Sie einen spezifischen Prompt

Ein spezifischer Prompt hilft aus demselben Grund, denn er gibt Claude Informationen, die es noch nicht hat. Wenn Sie die Datei nennen, das Symptom beschreiben und von vornherein sagen, wie „behoben“ aussieht, ersparen Sie sich meist später eine Korrekturrunde.

Dasselbe gilt für eine Vorliebe zwischen zwei vernünftigen Ansätzen: Claude kann sie nicht aus dem Code ablesen. Wenn es Ihnen also wichtig ist, welchen es wählt, sagen Sie es von vornherein.

Wenn Sie bereits haben, was Claude braucht, übergeben Sie es direkt, statt es zu beschreiben:

• Eine Datei: Geben Sie @ und den Pfad ein, um den Dateiinhalt in Ihre Nachricht aufzunehmen.
• Ein Bild: Fügen Sie den Screenshot des Designs oder des Fehlers in den Prompt ein.
• Befehlsausgabe: Leiten Sie sie aus Ihrer Shell mit cat error.log | claude -p "what's going on here" weiter.

Formulierungen wie think step by step oder be thorough sind gewöhnlicher Prompt-Text und keine Schlüsselwörter. Die wichtigste Steuerung dafür, wie intensiv Claude nachdenkt, ist die Effort-Stufe, die unter Ändern Sie Modell und Effort behandelt wird. Solche Formulierungen können Claude innerhalb seiner Effort-Einstellung zwar noch etwas anstoßen, heben es aber nicht darüber hinaus.

Eine Formulierung, die weiterhin hilft, ist be ambitious. Claude neigt dazu, eine Anfrage zurückhaltend zu lesen und das Kleinste zu bauen, das sie erfüllt, da es nicht sehen kann, wie viel Sie sich erhofft haben. Wenn Sie die umfassendere Version möchten, mit behandelten Edge Cases und dem naheliegenden nächsten Schritt, sagen Sie es:

build the settings page from the mockup. be ambitious: empty and error states, the save flow wired up, keyboard navigation, not just the layout

Damit teilen Sie Claude den Umfang mit, den nur Sie kennen, und nicht, wie intensiv es nachdenken soll.

Und wenn Sie erkunden, statt etwas Bestimmtes zu beheben, ist ein vager Prompt wie what would you improve in this file? völlig in Ordnung. Sie korrigieren unterwegs etwas mehr, und das ist der Kompromiss.

Brainstormen Sie zuerst mit Claude

Wenn Sie noch nicht genau wissen, was Sie möchten, müssen Sie nicht alles ausarbeiten, bevor Sie einen Prompt schreiben. Bitten Sie Claude stattdessen, Sie zu interviewen:

I want to add rate limiting to the public API but haven't thought it through yet. Interview me until you could write the spec, then write it to SPEC.md.

Claude kommt mit Multiple-Choice-Fragen zu den Teilen zurück, die Sie noch nicht festgelegt haben: Limits pro Benutzer oder pro Schlüssel, was mit Anfragen über dem Limit passiert, was außerhalb des Umfangs liegt. Es fragt so lange weiter, bis sich aus den Antworten eine Spezifikation ergibt.

Sobald SPEC.md existiert, starten Sie eine neue Sitzung, um danach zu bauen, damit die Umsetzung mit einem sauberen Kontext und einer schriftlichen Definition von „fertig“ beginnt. Es ist auch die Datei, auf die Sie später den Reviewer verweisen, in Geben Sie Claude eine Prüfung zum Ausführen.

Halten Sie CLAUDE.md kurz

Claude Code lädt CLAUDE.md in jede Sitzung, das heißt, jede Zeile darin beansprucht bei jeder Aufgabe ein wenig von Claudes Aufmerksamkeit, ob sie relevant ist oder nicht. Deshalb funktioniert die Datei am besten, wenn sie nur enthält, was Claude nicht selbst aus dem Code erschließen könnte:

• Wie Arbeit in diesem Repo bestätigt wird: die genauen Test-, Typecheck- und Lint-Befehle und wie eine einzelne Testdatei ausgeführt wird
• Stellen, an denen der Code irreführend ist: ein altes Muster, das überall vorkommt, das neuer Code aber nicht kopieren darf, oder ein Verzeichnis, das ungenutzt aussieht, es aber nicht ist
• Entscheidungen, die nicht im Repo stehen: auf welchen Fehler-Helper sich das Team geeinigt hat, wie Deploys funktionieren, was ein Migrations-Review braucht
• Alles, was Sie bereits zweimal korrigieren mussten

Eine CLAUDE.md, die diesen Test besteht, bleibt kurz:

# Commands
- Install: pnpm install
- Run one test file: pnpm vitest run path/to/file.test.ts
- Typecheck: pnpm tsc --noEmit

# Conventions
- Use the error helpers in src/lib/errors.ts, never throw raw strings
- src/legacy/ is still live but don't copy its patterns into new code

# Gotchas
- Integration tests need DATABASE_URL set, see .env.example

Führen Sie in einer Sitzung /context aus, um zu bestätigen, dass Claude die Datei geladen hat.

Beachten Sie, dass die Typecheck-Zeile nur den Befehl enthält. Claude muss den Befehl kennen, um die eigene Arbeit unterwegs prüfen zu können. Wenn Claude Code außerdem einen bestandenen Typecheck erzwingen soll, bevor Claude fertig ist, ist das eine Aufgabe für einen Stop-Hook. Eine Zeile wie Always typecheck before you finish in dieser Datei funktioniert meistens, aber nicht jedes Mal.

Sie müssen die Datei nicht von Grund auf schreiben:

• /init erzeugt eine erste Version aus Ihrer Codebasis. Danach besteht die Arbeit meist im Entfernen von Zeilen. Der Memory-Leitfaden empfiehlt, unter 200 zu bleiben.
• /doctor schlägt Kürzungen für alles vor, was Claude bereits aus dem Code erschließen kann.
• /doctor prompt-audit kennzeichnet Anweisungen, die für ältere Modelle geschrieben wurden, auf nicht mehr vorhandene Dateien verweisen oder einander widersprechen.

Ihre persönlichen Vorlieben gehören in CLAUDE.local.md statt in CLAUDE.md, und Sie fügen diese Datei zu .gitignore hinzu, damit sie nicht ins Repo gelangt.

[!NOTE]

Wenn Claude eine Zeile, die durchaus in CLAUDE.md steht, immer wieder ignoriert, wird IMPORTANT das wahrscheinlich nicht beheben. Entweder ist die Datei so lang geworden, dass die Zeile untergeht, oder die Zeile ist eine Regel, die keine Ausnahmen haben darf; dann gehört sie in einen Hook.

Beschränken Sie Regeln auf einen Teil der Codebasis

Wenn eine Regel nur in einem Teil der Codebasis wichtig ist, legen Sie sie in .claude/rules/ mit einem paths:-Filter ab, damit sie nur geladen wird, wenn Claude tatsächlich dort arbeitet. Diese .claude/rules/api.md wird zum Beispiel für TypeScript-Dateien unter src/api/ geladen:

---
paths:
  - "src/api/**/*.ts"
---
- Validate request bodies with the zod schemas in src/api/schemas/, don't hand-roll checks
- Every new endpoint needs an entry in openapi.yaml, CI fails without it

Legen Sie Team-Abläufe in Skills ab

Ein leistungsfähigeres Modell weiß mehr über Softwareentwicklung, aber nicht, wie Ihr Team ein Release durchführt, was in Ihrem Incident-Runbook steht oder wie Sie API-Dokumentation geschrieben haben möchten. Diese Art von Wissen gehört in einen Skill: einen Ablauf oder ein Stück Teamwissen, gespeichert unter .claude/skills/<name>/SKILL.md.

Skills belasten den Kontext für diese Art von Inhalten auch weniger als CLAUDE.md. Bei einem Skill, den Claude selbst starten kann, sieht es in jeder Sitzung den Namen und die Beschreibung, liest die vollständige Datei aber nur, wenn die Aufgabe es erfordert. Ein langer Release-Ablauf in einem Skill belastet Ihre unabhängige Fehlerbehebung nicht so, wie er es in CLAUDE.md tun würde.

[!NOTE]

Die CLAUDE.md-Regel gilt auch für Skills: Schreiben Sie nur auf, was Claude nicht selbst finden kann.

Für einen Workflow mit Nebenwirkungen, etwa das tatsächliche Erstellen dieses Releases, fügen Sie disable-model-invocation: true hinzu. Claude kann den Skill dann nicht selbst starten, und er läuft nur, wenn Sie selbst /release eingeben. Gespeichert als .claude/skills/release/SKILL.md könnte er so aussehen:

---
name: release
description: Cut a new release. Bumps the version, writes the changelog entry, tags it and pushes the tag so CI can publish.
disable-model-invocation: true
---
1. Make sure you're on main with a clean tree. If not, stop and ask.
2. Run `pnpm changeset version` and commit the result.
3. Summarize the PRs merged since the last tag into CHANGELOG.md, one line each, user-facing changes only.
4. Tag `v<new version>` and push the tag. CI publishes from there, never publish from your machine.

Verbinden Sie die Tools, die Claude braucht

Manches von dem, was Claude nicht sehen kann, liegt ganz in einem anderen System, etwa Ihrem Issue-Tracker oder Ihrem Fehler-Dashboard. Wenn dieses System eine CLI hat, ist das meist der einfachste Zugang. Wenn gh installiert und angemeldet ist, öffnet Claude zum Beispiel Pull Requests und liest Review-Kommentare, ohne dass Sie etwas erklären müssen. Bei einer CLI, die es noch nicht kennt, genügt ein Hinweis auf --help.

Für Systeme ohne CLI gibt es MCP. Sie fügen einen Server aus Ihrer Shell hinzu:

claude mcp add --transport http notion https://mcp.notion.com/mcp

Der Server erscheint dann in einer Sitzung unter /mcp. Verbundene Server fügen ihre Tool-Namen und Anweisungen dem Kontext hinzu, auch wenn Sie sie nicht verwenden. Es lohnt sich daher, dort die nicht benötigten zu deaktivieren.

Und wenn Sie in einer typisierten Sprache arbeiten, lässt ein Code-Intelligence-Plugin Claude direkt zu einer Definition springen, statt viele Dateien zu durchsuchen, um sie zu finden.

Geben Sie Claude eine Prüfung zum Ausführen

Claude hört auf, wenn die Arbeit erledigt aussieht. Wenn es nichts ausführen kann, das ihm sagt, ob die Arbeit tatsächlich erledigt ist, bleibt ihm nur „sieht erledigt aus“. In der Praxis werden dadurch Sie zur Test-Suite, und jeder Fehler bleibt bestehen, bis Sie ihn zufällig bemerken.

Wenn Sie ihm etwas geben, das mit Bestanden oder Fehlgeschlagen zurückkommt, kann Claude diese Schleife selbst schließen. Es nimmt die Änderung vor, führt die Prüfung aus und liest bei einem Fehler die Ausgabe und behebt ihn, bevor es die Prüfung erneut ausführt.

[!TIP]

Geben Sie Claude etwas, das es ausführen kann und das mit Bestanden oder Fehlgeschlagen zurückkommt. Sobald es das hat, kann es selbstständig weiterarbeiten, und Sie müssen nicht zusehen.

Die Prüfung kann fast alles sein, solange Claude das Ergebnis lesen kann:

• Eine Testdatei
• Der Exit-Code eines Builds
• Ein Linter
• Ein Skript, das die Ausgabe per Diff mit einem Fixture vergleicht
• Ein Browser-Screenshot neben dem Mockup

Wenn Ihr Repo bereits eines davon hat, ist die mit Abstand nützlichste Zeile in Ihrer CLAUDE.md der Befehl, der es ausführt.

Wie streng Sie die Prüfung gestalten, liegt bei Ihnen. Die Optionen reichen davon, dass Claude selbst entscheidet, bis dahin, dass Claude Code sie durchsetzt:

• Im Prompt: run the auth tests after, and keep going until they pass. Claude entscheidet selbst, wann es zufrieden ist. Das funktioniert heute für jede Aufgabe, ohne Einrichtung.
• Als Ziel: /goal all tests in tests/auth pass and lint is clean legt eine Bedingung fest, die ein separates Modell nach jedem Turn anhand der Konversation prüft, und Claude arbeitet weiter, bis sie erfüllt ist. In der Sitzung selbst brauchen Sie das selten. Wichtig ist es bei langen Hintergrundläufen, in denen Claude einen Turn manchmal mit einer Fortschrittszusammenfassung beendet, obwohl noch Punkte offen sind, und das Ziel es zurückschickt.
• Als Stop-Hook: Ein Stop-Hook führt Ihr Skript aus, wann immer Claude versucht, seinen Turn zu beenden, und schickt Claude zurück an die Arbeit, wenn das Skript mit Code 2 endet. Dies wird von Claude Code (dem Harness) durchgesetzt, sodass der Turn erst endet, wenn der Typecheck besteht oder das Blockierungslimit erreicht ist. Es gibt ein Beispiel weiter unten.
• Durch jemanden, der den Code nicht geschrieben hat: Im Terminal prüft /code-review den Diff in einem neuen Subagenten, der Ihre Konversation nie gesehen hat. Er lässt sich nicht von der Argumentation beeinflussen, die den Code hervorgebracht hat.

Welche Option Sie auch verwenden, bitten Sie Claude um Belege: den ausgeführten Befehl und seine Ausgabe oder den Screenshot. „Alle Tests bestanden“ allein sagt Ihnen sehr wenig, und die Ausgabe zu lesen geht schneller, als die Prüfung selbst erneut auszuführen. Bei einer Sitzung, die Sie nicht beobachtet haben, ist es außerdem der einzige Beleg, den Sie haben.

[!TIP]

Sobald Claude sagt, dass es fertig ist, können Sie in der Sitzung auch /verify ausführen. Damit baut und startet Claude die App und sieht sich das Ergebnis an. So werden Probleme erkannt, die Tests und Typechecks übersehen.

Prüfen Sie anhand Ihrer Spezifikation

Wenn das Review die Arbeit lieber anhand Ihres Plans prüfen soll, statt allgemein nach Fehlern zu suchen, schreiben Sie den Review-Prompt selbst:

use a subagent to review the rate limiter diff against SPEC.md, check every requirement is implemented and the listed edge cases have tests, report gaps that affect correctness and skip style

[!NOTE]

Lassen Sie den Teil skip style in diesem Prompt nicht weg. Ein Reviewer, der Probleme finden soll, findet immer etwas. Wenn Sie jeden Befund beheben, landen Sie bei zusätzlichen Abstraktionsebenen und Tests für Fälle, die nicht eintreten können.

Setzen Sie die Prüfung mit einem Stop-Hook durch

Die Stop-Hook-Version der Typecheck-Regel besteht aus ein paar Zeilen in .claude/settings.json. Exit-Code 2 blockiert das Beenden. Was der Befehl auf stderr ausgibt, geht als Grund, warum es noch nicht fertig sein kann, an Claude zurück. Deshalb wird die Compiler-Ausgabe dorthin umgeleitet:

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          { "type": "command", "command": "pnpm tsc --noEmit 1>&2 || exit 2" }
        ]
      }
    ]
  }
}

Um es in Aktion zu sehen, bitten Sie Claude um eine Änderung, die einen Typ bricht: Statt fertig zu werden, erhält es die Compiler-Fehler zurück und arbeitet weiter, bis tsc besteht. Wenn der Hook acht Beendigungen hintereinander ohne Tool-Aufruf dazwischen blockiert, überschreibt Claude Code die nächste Blockierung und beendet den Turn. Um die Obergrenze anzuheben, setzen Sie CLAUDE_CODE_STOP_HOOK_BLOCK_CAP.

Setzen Sie die Regeln durch, die keine Ausnahmen haben dürfen

[!TIP]

Wenn etwas jedes Mal passieren muss, machen Sie daraus einen Hook, eine deny-Regel oder eine verwaltete Einstellung. CLAUDE.md ist für Richtlinien da, und Claude darf entscheiden, dass eine Richtlinie nicht zutrifft.

Nehmen Sie drei Regeln, die Sie heute vielleicht in CLAUDE.md haben: Never read .env, Always run the formatter after editing, Don't touch the migrations folder. Claude befolgt diese fast jedes Mal. Für die wenigen, bei denen „fast“ nicht gut genug ist, verschieben Sie sie aus CLAUDE.md in eine Konfiguration, die Claude Code (der Harness) selbst anwendet. Ab dann hängt das Ergebnis nicht mehr davon ab, woran sich das Modell erinnert oder was es entscheidet.

Erzwingen Sie Schritte mit Hooks

Hooks führen etwas von Ihnen an festen Punkten in Claudes Schleife aus: vor oder nach einem Tool-Aufruf, wenn Claude versucht aufzuhören, wenn eine Sitzung startet und so weiter. Dieses Etwas kann sein:

• Ein Shell-Befehl (der übliche Fall)
• Ein POST an einen HTTP-Endpunkt
• Ein Tool-Aufruf auf einem Ihrer MCP-Server
• Ein prompt- oder agent-Hook, bei dem ein Modell entscheidet

Ein prompt- oder agent-Hook lässt ein anderes Modell entscheiden und ist daher ebenfalls nicht deterministisch. Für echte Durchsetzung verwenden Sie einen command- oder http-Hook und fügen onFailure: "block" hinzu, wenn die Aktion auch dann gestoppt werden soll, wenn der Hook selbst abstürzt oder in ein Timeout läuft. Bei einem Hook, der Commits etwa nach Secrets durchsucht, blockieren Sie den Commit lieber, als ihn ungeprüft durchzulassen, während der Scanner ausgefallen ist.

Hier ist die Formatter-Regel als PostToolUse-Hook. Er läuft nach jedem Edit oder Write, und ob Claude sich an die Regel erinnert, spielt keine Rolle mehr, weil nicht Claude sie ausführt:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          { "type": "command", "command": "npx prettier --write --ignore-unknown \"$(jq -r '.tool_input.file_path')\"" }
        ]
      }
    ]
  }
}

Um den Hook zu testen, bitten Sie Claude, einer Datei, die Prettier formatiert, eine schlecht eingerückte Zeile hinzuzufügen. Die gespeicherte Datei kommt mit korrigierter Einrückung zurück.

Die Migrations-Regel wird zu einem PreToolUse-Hook, der für jeden Pfad unter migrations/ mit Code 2 endet. Sie müssen ihn nicht selbst schreiben: write a hook that blocks edits to the migrations folder funktioniert als Prompt, und /hooks zeigt das Ergebnis. Übertreiben Sie es aber nicht: Ein Hook ist für eine Regel mit null Ausnahmen gedacht, und Prefer named exports hat viele, also bleibt diese in CLAUDE.md.

Beschränken Sie den Zugriff mit Berechtigungsregeln und der Sandbox

Berechtigungsregeln legen fest, was Claude ausführen, lesen und abrufen darf. deny-Regeln gelten in jedem Berechtigungsmodus, einschließlich Auto und bypassPermissions, und genau deshalb gehört die .env-Regel dorthin:

{
  "permissions": {
    "allow": ["Bash(pnpm tsc --noEmit)"],
    "ask": ["Bash(git push *)"],
    "deny": ["Read(./.env)", "Read(./.env.local)", "Read(./secrets/**)"]
  }
}

Wenn dies gespeichert ist, schlägt die Frage an Claude, was in .env steht, fehl, sowohl über das Read-Tool als auch über cat .env.

Regeln erfassen Tool-Aufrufe, nicht Absichten. Es lohnt sich also zu wissen, wo die Grenzen liegen:

• Die Read-Regel erfasst cat .env durchaus, weil Claude Code die gängigen Befehle zum Lesen von Dateien erkennt.
• Sie erfasst kein Skript, das die Datei öffnet.
• Eine WebFetch-deny-Regel für eine Domain bewirkt nichts gegen curl an dieselbe Domain, es sei denn, die Sandbox ist aktiv.

Für eine Begrenzung des Dateisystem- oder Netzwerkzugriffs auf Betriebssystemebene aktivieren Sie die Sandbox mit /sandbox in einer Sitzung. Sie schränkt Claudes Shell-Befehle unter macOS, Linux und WSL2 ein und übernimmt auch Ihre Read-deny-Regeln und WebFetch(domain:...)-Regeln. Für alles Sicherheitsrelevante möchten Sie daher beides.

Standardmäßig kann Claude weiterhin darum bitten, einen blockierten Befehl außerhalb der Sandbox erneut zu versuchen, und diese Anfrage durchläuft den normalen Berechtigungsablauf. Der strikte Sandbox-Modus im Tab Overrides von /sandbox schaltet diesen Wiederholungsversuch ab.

[!WARNING]

Der Auto-Modus ist ein Klassifikator-Modell, das jede Aktion beurteilt, keine feste Regel. Darin ist er gut, aber wie jede Ermessensentscheidung kann er danebenliegen. Sie können außerdem anpassen, was er als riskant einstuft, und Ihre Organisation kann ihn ganz abschalten. Ihre „Niemals“-Regeln gehören daher in deny-Regeln oder Hooks.

Legen Sie fest, für wen eine Regel gilt

Wo eine Regel liegt, entscheidet, für wen sie gilt:

• .claude/settings.local.json und ~/.claude/settings.json gehören nur Ihnen. Wenn Sie für einen Befehl Yes, and don't ask again auswählen, speichert Claude Code diese Regel in der lokalen Datei.
• .claude/settings.json und die Hooks darin gehören zum Repo. Sobald Sie sie committen, gelten sie für alle, die im Repo arbeiten. Die deny-Regeln darin gelten sofort. Die allow-Regeln greifen erst, wenn die jeweilige Person den Vertrauensdialog für diesen Ordner akzeptiert, und das Workspace-Vertrauen entscheidet auch, wann die Hooks auf ihrem Rechner ausgeführt werden.
• Verwaltete Einstellungen gehören der Organisation. Sie stammen aus der Admin-Konsole, aus MDM oder aus einer managed-settings.json-Datei, und keine persönliche Einstellungsdatei kann sie überschreiben. Damit sind sie der einzige Ort für die Richtlinien eines Sicherheitsteams. Wenn Sie diejenige Person sind, die sie festlegt, siehe Claude Code für Ihre Organisation einrichten.

Unabhängig vom Geltungsbereich sollten Sie die durchgesetzten Regeln klein halten. Jeder Hook und jede deny-Regel wird gelegentlich auslösen, wenn es nicht sollte, und jemand muss sie alle pflegen. Wenn Sie irgendwann bei vierzig davon angekommen sind, sind die meisten wahrscheinlich Vorlieben, die Claude selbst hätte abwägen können.

Ändern Sie eine Standardeinstellung

[!TIP]

Die Standardeinstellungen sind gut genug, um sie unverändert zu lassen, bis eine Aufgabe mehr Zeit, Token oder Unterbrechungen kostet, als sie sollte. Führen Sie in diesem Fall /usage in der Sitzung aus, um zu sehen, wohin der Verbrauch gegangen ist.

Eine neue Sitzung trifft bereits eine Handvoll Entscheidungen für Sie:

• Interaktive Terminal- und VS Code-Sitzungen starten im Auto-Modus.
• Auf den meisten Plänen und bei den meisten Anbietern läuft Claude Opus 5.5 mit mittlerem Effort.
• Claude delegiert Arbeit an Subagenten, wenn es einen Grund dafür sieht.
• Die Konversation wird komprimiert, wenn sie wächst.

Meistens denken Sie nie darüber nach. Wenn eine Aufgabe doch mehr kostet, als sie sollte, ist meist einer dieser vier Punkte der Grund.

Ändern Sie den Berechtigungsmodus

Beide Enden des Berechtigungsspektrums haben ihren Preis:

• Manual-Modus: Sie genehmigen jede Bearbeitung und jeden Befehl, der nicht nur lesend ist, selbst. Sicher, aber nach der zehnten Abfrage genehmigen Sie, ohne zu lesen, und nichts geht voran, während Sie nicht an der Tastatur sind.
• bypassPermissions: genehmigt alles, was Ihre deny- und ask-Regeln nicht abdecken. Das ist nur in einem Wegwerf-Container sinnvoll.

Der Auto-Modus liegt zwischen beiden, und in ihm starten interaktive Terminal- und VS Code-Sitzungen. Claude arbeitet, ohne für alltägliche Genehmigungen anzuhalten, und ein separates Klassifikator-Modell prüft Aktionen in einer festen Reihenfolge, bevor sie ausgeführt werden. Es konzentriert sich auf die Dinge, bei denen Sie möchten, dass eine Person eingreift:

• curl | bash
• Production-Deployments und Migrationen
• Force-Pushes über die Arbeit anderer
• Sensible Daten, die an externe Endpunkte gesendet werden
• Aktionen, die eher von Inhalten gesteuert wirken, die Claude gelesen hat, als von Ihnen

Wenn er etwas blockiert, erhalten Sie eine Benachrichtigung, und die Aktion erscheint unter Recently denied in /permissions, wo Sie sie mit einer manuellen Genehmigung erneut versuchen können. Nach drei Blockierungen hintereinander (oder zwanzig insgesamt) pausiert der Auto-Modus und fragt wieder Sie.

Nichts davon ersetzt Ihre deterministischen Kontrollen, weil es nach ihnen läuft. deny- und ask-Regeln sowie PreToolUse-Hooks greifen, bevor der Klassifikator etwas sieht. Eine deny-Regel blockiert im Auto-Modus also genauso wie überall sonst. Die Sandbox schränkt weiterhin die Shell-Befehle ein, die sie umschließt.

[!NOTE]

Sie können in der Konversation auch don't push until I've reviewed sagen, und der Klassifikator wertet das als Blockierungssignal. Es ist aber weiterhin ein Modell, das das Transkript liest, und der Satz kann bei der Komprimierung der Konversation verloren gehen. Alles, was wichtig ist, gehört daher in eine deny-Regel.

Das umgekehrte Problem ist, dass der Klassifikator wiederholt etwas stoppt, das in Ihrer Umgebung alltäglich ist. Statt es jedes Mal manuell zu genehmigen, fügen Sie es zu autoMode.allow hinzu oder beschreiben Ihre vertrauenswürdige Infrastruktur in der Auto-Modus-Konfiguration. Diese wird in natürlicher Sprache statt in Mustern geschrieben, und /auto-mode-setup kann den environment-Teil aus Ihrem Projekt und Ihren letzten Sitzungen für Sie entwerfen:

{
  "autoMode": {
    "environment": [
      "$defaults",
      "Source control: github.com/example-org and every repo under it",
      "Trusted internal domains: *.internal.example.com"
    ],
    "allow": [
      "$defaults",
      "Deploying to the staging namespace is fine, it's isolated from production and resets nightly"
    ]
  }
}

[!WARNING]

Behalten Sie "$defaults" in jeder Liste bei, die Sie festlegen, denn ohne diesen Eintrag ersetzen Ihre Einträge die integrierten Regeln dieser Liste, statt sie zu ergänzen. Bei environment und allow würden Sie den integrierten Kontext und die Ausnahmen verlieren, und eine soft_deny-Liste ohne ihn verliert die integrierten Blockierungen für Force-Pushes und Production-Deployments.

Der autoMode-Block muss außerdem in ~/.claude/settings.json statt im Projekt liegen, weil der Klassifikator autoMode in Projekteinstellungen ignoriert.

Wenn Sie jede Bearbeitung und jeden Befehl lieber sehen möchten, bevor sie ausgeführt werden, wechselt Shift+Tab in der Sitzung durch die Berechtigungsmodi, einschließlich Manual, oder Sie starten mit claude --permission-mode manual aus Ihrer Shell. Und wenn Manual dann zu oft nachfragt, durchsucht /fewer-permission-prompts Ihre letzten Transkripte nach häufigen, nur lesenden Bash- und MCP-Aufrufen und fügt sie einer Allowlist in .claude/settings.json hinzu.

Ändern Sie Modell und Effort

Effort ist die wichtigste Steuerung dafür, wie lange Claude nachdenkt, und ersetzt das meiste, was man früher mit Prompt-Formulierungen gemacht hat. Claude Opus 5.5, Sonnet 5.5 und Haiku 5.5 verwenden standardmäßig medium, was für alltägliche Feature-Arbeit mit klarem Umfang völlig ausreicht. Wann Sie es mit /effort in der Sitzung ändern sollten:

• Erhöhen Sie es mit /effort high oder /effort xhigh, wenn es darauf ankommt, Fälle zu erfassen, die leicht übersehen werden. Denken Sie an einen Fehler in Code, den Sie nicht geschrieben haben, einen instabilen Test oder eine Schemaänderung, bei der Claude jeden Leser der alten Struktur finden muss. Claude prüft dann mehr Edge Cases und verifiziert mehr von seiner Arbeit, bevor es antwortet. Dafür gehen die zusätzliche Zeit und die zusätzlichen Token drauf.
• Senken Sie es mit /effort low, wenn Sie schnell hin und her arbeiten und ohnehin jedes Ergebnis prüfen: Brainstorming, ein erster Entwurf, eine Umbenennung über ein paar Dateien. Claude liefert Ihnen schneller einen Ausgangspunkt, und da Sie jeden Schritt steuern, hätte die zusätzliche Überlegung außer der Wartezeit kaum etwas geändert.
• Heben Sie max für ein schwieriges Problem auf, das Claude ohne Sie durcharbeiten soll, etwa die Suche nach einer Sicherheitslücke. Bei gewöhnlichen Aufgaben neigt es dazu, zu viel nachzudenken, sodass Sie mehr für eine Antwort bezahlen, die womöglich nicht besser ist als mit high.
• Wenn nur die nächste Nachricht es braucht, etwa eine knifflige Frage mitten in ansonsten alltäglicher Arbeit, schreiben Sie ultrathink in diesen Prompt, statt die Einstellung zu ändern.

Was das Modell selbst angeht, bewältigt das Standardmodell Opus 5.5 die meisten Programmieraufgaben gut, und Sonnet kostet bei alltäglicher Arbeit weniger. Claude Fable 5.1 steht zur Verfügung, wenn Sie es ausdrücklich mit /model fable auswählen, und Haiku eignet sich gut für Subagenten mit einfachen Aufgaben. Unter Modellkonfiguration finden Sie die vollständige Liste pro Plan und Anbieter.

Wissen Sie, was Subagenten kosten

Claude delegiert selbstständig an Subagenten:

• Breite Suchen in der Codebasis gehen an den integrierten Explore-Agenten.
• Nebenaufgaben werden geforkt, solange der Fork-Modus aktiv ist (die Standardeinstellung).
• Die Subagenten, die es startet, laufen standardmäßig im Hintergrund, sodass Ihre Hauptkonversation weiterläuft.

Sie müssen selten um etwas davon bitten, aber es hilft zu wissen, was Sie bekommen und was es kostet.

Subagenten lohnen sich in diesen Situationen:

• Unabhängige Arbeitspakete gleichzeitig ausführen, damit die gesamte Aufgabe schneller fertig ist
• Lange Ausgaben, etwa einen vollständigen Testlauf oder eine breite Suche, aus Ihrer Hauptkonversation heraushalten, wo sie sonst für den Rest der Sitzung mitgeschleppt würden
• Einen Reviewer bekommen, der nicht gesehen hat, wie der Code geschrieben wurde
• Einer Aufgabe weniger Tools geben, als die Hauptsitzung hat, etwa einem Reviewer, der lesen, aber nicht bearbeiten kann

Was sie Sie kosten, sind vor allem Token, denn jeder Subagent sendet eigene Anfragen, und diese zählen zur selben Nutzung wie Ihre Hauptkonversation. Manchmal kostet es auch Zeit: Ein neuer Subagent muss zuerst Kontext sammeln, den Ihre Konversation bereits hatte, und kann daher am Ende langsamer sein, als die Aufgabe direkt dort zu erledigen, wo Sie sind.

Und standardmäßig ist es dasselbe Modell (oder ein kleineres) an derselben Aufgabe. Sie gewinnen dadurch Parallelität oder einen frischen Blick, aber keine klügere Antwort.

Um weniger für sie auszugeben:

• Setzen Sie model: haiku in der Definition eines Subagenten, wenn seine Arbeit einfach ist, etwa die Dateien zu sammeln, die ein Modul importieren, oder Links in der Dokumentation zu prüfen. Eine solche Aufgabe braucht nicht das größere Modell, und Haiku kostet pro Anfrage deutlich weniger.
• Bitten Sie um kurze Zusammenfassungen als Rückmeldung, damit zwanzig Ergebnisse Ihren Kontext nicht trotzdem füllen.
• Prüfen Sie mit /usage, welchen Anteil Ihrer Nutzung jeder Subagententyp ausmacht, damit Sie erkennen, welche ihre Kosten wert sind.
• Geben Sie einem benutzerdefinierten Subagenten in .claude/agents/ nur tools: Read, Grep, Glob. Dann ist er ein Reviewer, der nichts bearbeiten kann, und diese Einschränkung wird von Claude Code durchgesetzt, statt in einem Prompt erbeten zu werden.

Dieser Reviewer ist eine kurze Datei, .claude/agents/reviewer.md:

---
name: reviewer
description: Reviews changed files against the spec they were built from. Use after implementing a feature, before opening the PR.
tools: Read, Grep, Glob
---
You're reviewing code you didn't write. Compare the changed files against the spec you're given,
check that every requirement is implemented and the listed edge cases have tests,
and report only the gaps that affect correctness. Skip style.

Bitten Sie Claude have the reviewer compare the rate limiter against SPEC.md, und die Lücken kommen in Ihre Sitzung zurück, wo Claude sie beheben kann.

Halten Sie Kosten und Kontext gering

Mit einem Fenster von 1M Token bei den meisten aktuellen Modellen und einer Komprimierung nahe dessen Obergrenze geht Ihnen selten der Kontext aus. Sie können aber trotzdem für Kontext bezahlen, den Sie nicht brauchen. Jede Anfrage sendet die gesamte Konversation, sodass eine Sitzung, die drei unzusammenhängende Aufgaben angesammelt hat, bei jedem Turn der vierten alle drei erneut liest. Das ist vergünstigt, solange der Cache warm ist, und kostet den vollen Preis, sobald er abläuft.

/usage ist die erste Anlaufstelle. Bei Pro, Max, Team und Enterprise schlüsselt es Ihre Nutzung nach Skill, Subagent, Plugin und MCP-Server auf. Außerdem kennzeichnet es Muster wie langen Kontext oder häufige Cache-Misses, sobald eines davon 10 % Ihrer Nutzung überschreitet. Von dort aus die üblichen Lösungen:

• /clear zwischen unzusammenhängenden Aufgaben. Es kostet nichts und sorgt dafür, dass die nächste Aufgabe nicht weiter für den Verlauf der vorherigen bezahlt. /clear oauth-migration benennt die Sitzung, die Sie verlassen, damit Sie später zu ihr zurückkehren können.
• /compact mit einem Fokus, etwa /compact keep the API changes and the test commands. In einer langen Sitzung ist /compact selbst eine große Anfrage, da es die gesamte Konversation liest, um sie zusammenzufassen, und das umso mehr, wenn der Cache abgelaufen ist.
• Behalten Sie Hintergrundarbeit im Blick: Ein /loop, die Prüfung eines Ziels nach jedem Turn und Claudes eigene Subagenten senden alle weiterhin Anfragen, während Sie nicht tippen.

[!NOTE]

Der Prompt-Cache hält bei einem Abonnement etwa eine Stunde und bei einem API-Schlüssel, einem Cloud-Anbieter oder Nutzungsguthaben fünf Minuten. Subagenten bekommen fünf Minuten, sofern Sie das nicht ändern.

Beim einstündigen Cache wird eine inaktive Sitzung mit mehr als etwa 200K Token kurz vor Ablauf des Caches komprimiert, sodass Sie nach der Mittagspause mit einer Zusammenfassung weitermachen. Wenn Sie den Verlauf gar nicht brauchen, ist eine neue Sitzung trotzdem günstiger.

Steuern Sie die Sitzung

[!TIP]

Beobachten Sie die erste Minute, drücken Sie Esc, sobald Claude abschweift, und führen Sie nach zwei fehlgeschlagenen Korrekturen /clear aus und schreiben einen besseren Prompt, statt eine dritte Korrektur zu versuchen.

Keine Konfiguration ersetzt es, die erste Minute zu beobachten und einzugreifen, wenn Claude in eine Richtung geht, die Sie nicht beabsichtigt haben. Dafür gibt es nur wenige Steuerelemente, und es lohnt sich, sie auswendig zu kennen:

• Esc stoppt Claude mitten in einer Aktion und behält alles bis zu diesem Punkt, sodass Sie umlenken können, ohne Arbeit zu verlieren.
• /rewind oder zweimal Esc bei leerem Prompt öffnet das Rewind-Menü, in dem Sie den Code, die Konversation oder beides auf einen früheren Prompt zurücksetzen. Dadurch ist es risikoarm, zuerst den mutigeren Ansatz auszuprobieren und zurückzuspulen, wenn er nicht funktioniert. Dasselbe Menü kann auch einen Teil der Konversation zusammenfassen, wenn dieser veraltet ist.
• /clear fängt neu an. Wenn Sie dasselbe zweimal korrigiert haben und es immer noch falsch ist, ergänzt eine dritte Korrektur vor allem eine Konversation, die bereits zwei fehlgeschlagene Versuche enthält, die Claude immer wieder liest. /clear plus ein neuer Prompt, der das Gelernte einbezieht, funktioniert fast jedes Mal besser.

[!WARNING]

Checkpoints umfassen die Dateien, die Claude in Ihrer Hauptkonversation mit seinen eigenen Datei-Tools bearbeitet hat. Eine Datei, die nur ein Bash-Befehl verändert hat, wird daher nicht wiederhergestellt. Sie funktionieren zusammen mit Git, statt es zu ersetzen.

Zwei kleinere: /btw beantwortet eine kurze Frage, ohne dem Verlauf etwas hinzuzufügen. Und für Arbeit, die sich über mehrere Tage erstreckt, benennt /rename oauth-migration die Sitzung, sodass claude --resume oauth-migration aus Ihrer Shell sie später wieder aufnimmt, einschließlich Checkpoints. claude --continue setzt die letzte fort.

Lassen Sie Claude ohne Sie arbeiten

[!TIP]

Bevor ein Lauf unbeaufsichtigt bleibt, stellen Sie sicher, dass er weiß, wie „fertig“ aussieht, seine eigene Arbeit prüfen kann und nur anfassen kann, was er soll. Geben Sie ihm eine Obergrenze für Turns oder Ausgaben, und lassen Sie am Ende eine Person das Ergebnis genehmigen.

Alles auf dieser Seite wird etwas wichtiger, sobald Sie nicht da sind, um Fehler abzufangen. Solange Sie zusehen, ist es keine große Sache, wenn Claude ein Stück Kontext fehlt: Sie bemerken es innerhalb von ein oder zwei Nachrichten und sagen es ihm. Bei einem Lauf, den Sie vor dem Schlafengehen gestartet haben, sagt es ihm niemand, und am nächsten Morgen stellen Sie fest, dass es die ganze Nacht auf einer falschen Annahme aufgebaut hat.

Bevor Sie eine Aufgabe allein laufen lassen, lohnt es sich, diese fünf Fragen mit genau dieser Aufgabe im Kopf durchzugehen:

1. Weiß es, wie „fertig“ aussieht? Eine Zielbedingung, eine Spezifikationsdatei oder ein fehlschlagender Test, den es grün machen muss.
2. Kann es seine eigene Arbeit prüfen? Die Test-Suite, ein Stop-Hook, irgendein Review-Schritt.
3. Was darf es anfassen? Berechtigungsregeln, dontAsk, die Sandbox, ein Worktree, der eine Branch, auf den es pushen darf.
4. Was stoppt es? --max-turns, --max-budget-usd, ein Ausgabenlimit.
5. Wohin geht das Ergebnis, und wer gibt es frei? Ein PR, ein Kommentar oder eine Zusammenfassung, und dann eine Person, die den Merge, das Deployment oder alles andere genehmigt, was sich nicht rückgängig machen lässt.

Sobald es läuft, bringt Claude eine lange Aufgabe selbstständig zu Ende. Bei Ihnen bleibt, sie zu starten, festzulegen, was „fertig“ diesmal bedeutet, und am Ende den Merge zu genehmigen.

Führen Sie Claude aus einem Skript aus

claude -p "prompt" läuft einmal und beendet sich. So landet Claude Code in CI-Jobs, Git-Hooks und Shell-Schleifen.

In einem Skript möchten Sie fast immer ein paar weitere Flags:

• --bare überspringt Hooks, Skills, Plugins, MCP-Server und CLAUDE.md-Dateien, sowohl die des Repos als auch die des Rechners, sodass der Lauf überall dasselbe tut. Außerdem wird Ihre claude.ai-Anmeldung nie verwendet: Die Authentifizierung kommt aus ANTHROPIC_API_KEY, einem apiKeyHelper in der Datei, die Sie mit --settings übergeben, oder den Anmeldedaten Ihres Cloud-Anbieters.
• --append-system-prompt, --mcp-config und --settings übergeben explizit, was der Lauf tatsächlich braucht.
• --allowedTools genehmigt seine Tools vorab, und --permission-mode dontAsk lehnt alles andere ab, das eine Abfrage ausgelöst hätte.
• --output-format json liefert Ihnen ein einzelnes Ergebnisobjekt zum Parsen, und stream-json mit --verbose streamt Ereignisse, während sie auftreten.

Zusammengesetzt sieht das so aus:

for file in $(cat files.txt); do
  claude --bare -p "Migrate $file to the new logger API and commit. Reply OK or FAIL." \
    --allowedTools "Read,Edit,Bash(git add *),Bash(git commit *)" \
    --permission-mode dontAsk \
    --max-turns 20
done

Wenn ein Lauf beendet ist, antwortet Claude mit OK oder FAIL, und ein Lauf, der das Turn-Limit erreicht, endet stattdessen mit einem Fehler. Probieren Sie es zuerst mit drei Dateien aus, sehen Sie, was schiefgeht, korrigieren Sie den Prompt und führen Sie dann den Rest aus.

Der Auto-Modus funktioniert auch mit -p, wenn Sie --permission-mode auto übergeben. In einem nicht interaktiven Lauf verweigert eine Blockierung durch den Klassifikator nur diese eine Aktion, und Claude macht weiter. Wiederholte Blockierungen pausieren den Lauf nicht so, wie sie es im Terminal tun. Lesen Sie, wie die Schwellenwerte dort gelten, bevor Sie sich darauf verlassen.

Starten Sie Läufe nach Zeitplan oder bei einem Ereignis

Sobald ein Lauf begonnen hat, kann Claude den Rest selbst erledigen. Das Einzige, was es nicht kann, ist zu entscheiden, anzufangen. Also muss etwas anderes das tun: Sie, ein Timer oder ein Ereignis wie eine fehlgeschlagene CI-Prüfung oder ein neuer PR.

In einer offenen Sitzung ist das /loop, das einen Prompt in einem Intervall wiederholt:

/loop 15m check CI on this branch, and if it's red pull the failing job's log, fix it and push

Jeder Lauf ist ein weiterer Turn in derselben Sitzung, lassen Sie also keinen in einer langen Konversation laufen. Für alles, was passieren soll, während Ihr Laptop zugeklappt ist, richtet /schedule eine geplante Cloud-Aufgabe ein, die nach einem Timer läuft. Dafür ist eine claude.ai-Anmeldung statt eines API-Schlüssels erforderlich. Sie können einen GitHub-Ereignis-Trigger hinzufügen, indem Sie Claude darum bitten, oder einen API-Trigger unter claude.ai/code/routines.

[!WARNING]

Bevor Sie eine geplante Cloud-Aufgabe laufen lassen, schützen Sie main mit einer GitHub-Branch-Regel, die die Aufgabe nicht umgehen kann. Und beobachten Sie die ersten paar Läufe von allem Neuen, bevor Sie ihm unbeaufsichtigt vertrauen.

Führen Sie Sitzungen parallel aus

Wenn mehrere separate Arbeiten gleichzeitig laufen, geben Sie jeder einen eigenen Checkout, damit die Bearbeitungen nicht kollidieren können. claude -w feature-auth startet eine Sitzung in einem neuen Worktree, die Desktop-App führt mehrere davon nebeneinander aus, und Cloud-Sitzungen führen sie in der Cloud statt auf Ihrem Rechner aus.

Ein Worktree ist ein frischer Checkout, das heißt, von Git ignorierte Dateien wie .env sind nicht vorhanden und Abhängigkeiten sind nicht installiert. Für Ersteres listen Sie die benötigten ignorierten Dateien in einer .worktreeinclude im Repo-Stammverzeichnis auf (gleiche Syntax wie .gitignore), und Claude Code kopiert sie in jeden Worktree, den es erstellt:

.env
.env.local
config/dev-credentials.json

Beschränken Sie sich auf kleine Dateien: Sie werden kopiert statt verlinkt, node_modules darin würde also eine vollständige Kopie pro Worktree bedeuten. Für große Verzeichnisse gibt es die Einstellung worktree.symlinkDirectories, oder Sie halten den Installationsbefehl in CLAUDE.md fest, damit Claude ihn ausführt, wann immer es in einem neuen Checkout startet.

Aufräumen müssen Sie dabei selten selbst:

• Wenn Sie eine unbenannte Worktree-Sitzung beenden, entfernt Claude Code den Worktree, sofern nichts darin ist. Bei einer benannten Sitzung oder einer mit Änderungen fragt es, was zu tun ist.
• Subagenten-Worktrees verschwinden, wenn der Subagent ohne Änderungen fertig wird.
• Zurückgebliebene Worktrees von Subagenten und Hintergrundsitzungen werden entfernt, sobald sie älter als cleanupPeriodDays sind und keine Arbeit enthalten.

[!NOTE]

Einen claude -p --worktree-Lauf räumen Sie selbst auf, da er sich ohne Nachfrage beendet. Entfernen Sie solche Worktrees mit git worktree remove <path>, und wenn Git sich weigert, weil der Worktree gesperrt ist, führen Sie zuerst git worktree unlock <path> aus.

Für eine große mechanische Änderung über viele Dateien teilt /batch migrate every handler to the v2 response helpers die Arbeit in 5 bis 30 Einheiten auf und zeigt Ihnen den Plan. Anschließend führt es jede Einheit in einem eigenen Worktree aus und öffnet dafür einen PR. Aus Ihrer Shell heraus bietet Ihnen claude agents (noch eine Research Preview) einen Bildschirm für alles, was auf Ihrem Rechner im Hintergrund läuft.

Eine zweite Sitzung ist auch der einfachste unabhängige Reviewer, den Sie bekommen können. Eine Sitzung schreibt den Rate Limiter, eine andere prüft @src/middleware/rateLimiter.ts, ohne beim Schreiben zugesehen zu haben, und Sie fügen die Befunde in die erste ein. Dieselbe Idee wie /code-review, nur dass Sie die Nachrichten überbringen.

Was Sie nicht mehr tun müssen

Jeder dieser Ratschläge war gut, als er geschrieben wurde. Die meisten waren Workarounds für etwas, das das Modell damals noch nicht zuverlässig konnte, und die Modelle haben inzwischen aufgeholt. Falls einige davon noch Gewohnheiten sind, erfahren Sie hier, warum Sie sie bedenkenlos ablegen können.

Wenn sich ein anderer Ratschlag auf dieser Seite irgendwann wie reine Beschäftigung anfühlt, ist das wahrscheinlich ein Zeichen, dass er ebenfalls in diese Tabelle gehört.

Verwandte Ressourcen

• Wie Claude Code funktioniert: die Schleife, die Tools und was beim Start geladen wird
• Das Kontextfenster erkunden: was in einer Sitzung Platz belegt und wann es geladen wird
• Claude Code erweitern: die Wahl zwischen Skills, Hooks, MCP, Subagenten und Plugins
• Einen Berechtigungsmodus wählen und Berechtigungen konfigurieren
• Kosten effektiv verwalten
• Claude Code programmatisch ausführen und Arbeit mit geplanten Cloud-Aufgaben automatisieren
• Für Teamleads und Admins: Claude Code für Ihre Organisation einrichten