Der „Mach du“-Knopf

Was es ist und warum es zählt

Im Modus Manual fragt Claude Code vor den meisten Aktionen um Erlaubnis. Am Anfang liest du jede Frage. Nach einer Weile drückst du Ja, ohne zu lesen, und dann schützt dich die Erlaubnis nicht mehr.

Der „Mach du“-Knopf ist das Gegenteil: Du entscheidest einmal, in Ruhe, was Claude allein machen darf und was nicht. Frei im Projekt: Dateien ändern, Tests starten, den Server hochfahren. Gesperrt bei drei Dingen, die sich schwer rückgängig machen lassen: löschen, veröffentlichen, die echte Datenbank anfassen.

Du brauchst zwei Teile: einen Berechtigungsmodus, der entscheidet, wie viel Claude dich fragt, und eine Regeldatei im Projekt, die festlegt, was immer durchgeht, was immer fragt und was verboten ist.

1. Der Modus

Ich arbeite in accept edits: Claude ändert die Dateien des Projekts, ohne zu fragen, alles andere läuft über die Regeln unten. Ein paar einfache Dateibefehle wie mkdir, mv, cp und rm akzeptiert es auch von selbst, aber nur im Projektordner.

Zum Einschalten drückst du Shift+Tab, bis du unter dem Prompt „accept edits on“ liest. In neueren Versionen startet die Sitzung schon im auto mode, in dem ein zweites Modell die Aktionen an deiner Stelle prüft: Das erste Shift+Tab bringt dich zu Manual, das zweite zu accept edits. Oder du wählst ihn beim Start, im Terminal:

claude --permission-mode acceptEdits

Bevor du Claude eine Aufgabe gibst, schau immer auf diese Zeile. Auto ist praktisch und blockiert riskante Aktionen, aber die Dokumentation sagt selbst, dass es keine Sicherheit garantiert. Mit accept edits weißt du genau, was von selbst durchgeht, und die Regeln gelten in beiden.

2. Die Regeln, ein für alle Mal

Leg die Datei .claude/settings.json im Projektordner an. Wenn es sie schon gibt, überschreib sie nicht: Füg den Teil „permissions“ zu dem hinzu, was schon drinsteht. Meine sieht so aus:

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "allow": [
      "Bash(npm test *)",
      "Bash(npm run test *)",
      "Bash(npm run dev *)",
      "Bash(npm run lint *)"
    ],
    "ask": [
      "Bash(git push *)"
    ],
    "deny": [
      "Bash(rm *)",
      "Bash(git push --force *)",
      "Bash(git push -f *)",
      "Bash(npm publish *)",
      "Bash(vercel *)",
      "Bash(npx vercel *)",
      "Bash(supabase db push *)",
      "Bash(psql *)",
      "Read(./.env.production)"
    ]
  }
}

Setz deine Befehle an die Stelle von meinen (die Tests, der Server, das Deployment, der Client deiner echten Datenbank). Achtung: In accept edits würde auch rm im Projekt von selbst durchgehen, deshalb steht es bei deny.

Was jeder Teil macht

• defaultMode: der Modus, in dem die Sitzung im Terminal startet. Du startest in accept edits, auch wenn der Standard auto wäre. Das Flag --permission-mode gewinnt gegen die Datei.
• allow: die Befehle, die Claude startet, ohne zu fragen: Tests, Lint, Entwicklungsserver. Bash(npm test *) deckt npm test allein ab und auch mit jeder Option dahinter.
• ask: die Befehle, bei denen du jedes Mal gefragt werden willst, in jedem Modus, auch in auto. git push schickt den Code online: Das will ich vorher sehen.
• deny: was nie passieren darf: Dateien löschen, der erzwungene Push, veröffentlichen, das Deployment, die echte Datenbank. vercel und npx vercel sind zwei Zeilen, weil die Regel für vercel den Befehl mit npx davor nicht sieht.
• Read(./.env.production): Claude liest die Datei mit den Produktionsschlüsseln nicht, weder mit seinen eigenen Werkzeugen noch mit cat, und kann sie nicht ändern.

Du musst die Datei nicht von Hand schreiben. Du kannst sie von Claude anpassen lassen:

Lies die package.json und die Skripte dieses Projekts. Dann pass diese Datei .claude/settings.json an: In allow kommen die echten Befehle für die Tests, den Lint und den Entwicklungsserver; in deny die Befehle, die Dateien löschen, die App veröffentlichen, deployen oder die Produktionsdatenbank anfassen. Setz nichts in allow, was etwas löscht oder online schickt. Zeig mir die Datei, bevor du sie speicherst.

[füge hier die Datei ein]

Wenn Claude die Datei speichert, fragt es dich auch in accept edits um Erlaubnis: Das ist normal, der Ordner .claude ist geschützt.

3. Drei Dinge, die du wissen solltest

Deny gewinnt immer

Claude Code prüft die Regeln in dieser Reihenfolge: zuerst deny, dann ask, dann allow. Es entscheidet die erste, die passt. Ein allow reißt kein Loch in ein deny, auch nicht, wenn es genauer ist. Und die deny-Regeln gelten in jedem Modus.

In meiner Datei: git push --force steht sowohl bei ask als auch bei deny, und deny gewinnt. git push origin main --force sieht das deny dagegen nicht, weil der Befehl nicht mit „git push --force“ anfängt. Er fängt aber mit „git push“ an, und das ask stellt dir die Frage. Deshalb behalte ich beide Zeilen.

Die Regeln lesen den Text des Befehls

Die Regeln lesen den Text des Befehls: bash -c 'rm -rf build' oder /bin/rm rutschen unter „Bash(rm *)“ durch. Die Regel erkennt sie nicht, und dann entscheiden der Modus und die anderen Regeln.

Für eine echte Wache nimm einen PreToolUse-Hook (den Wächter aus TIPS 05) oder die Sandbox (/sandbox). Der Hook liest den ganzen Text jedes Befehls, bevor er startet, auch innerhalb von bash -c. Mit der Sandbox begrenzt das Betriebssystem, was Befehle außerhalb des Projekts schreiben und mit welchen Websites sie sich verbinden. Im Projekt lässt sie aber Schreiben zu: Ein rm dort hält nur der Hook auf.

Der Modus ohne Kontrollen

Den Modus ganz ohne Kontrollen (--dangerously-skip-permissions) nutzt du nur in einem Container oder einer virtuellen Maschine, nie auf dem Computer mit deinen Dateien. Auch die Dokumentation empfiehlt ihn nur in isolierten Umgebungen. Wenn du auf deinem Computer weniger Fragen willst, ist der Weg accept edits mit den Regeln, oder auto.

4. Prüfen

Gib /permissions in Claude Code ein: Du siehst alle aktiven Regeln und aus welcher Datei jede kommt. Fehlt eine Regel, liegt die Datei meistens am falschen Ort, oder im JSON steckt ein Fehler, etwa ein fehlendes Komma.

Dann mach einen echten Test. Schreib Claude:

Leg eine leere Datei namens berechtigungstest.txt an. Dann probier diese drei Befehle aus, einen nach dem anderen, und sag mir bei jedem, was passiert ist: von einer Regel blockiert, du hast mich um Erlaubnis gefragt, oder er ist von selbst gelaufen.
- npm test (oder der Testbefehl dieses Projekts)
- rm berechtigungstest.txt
- git push --dry-run
Wenn ein Befehl blockiert wird, such keine anderen Wege, ihn zu starten.

Das erwartest du: Tests laufen von selbst, rm blockiert, git push mit Rückfrage (mit --dry-run wird nichts online geschickt). Die Testdatei löschst du danach selbst: Claude kann es nicht.

Häufige Fehler

• Die Datei kopieren, ohne die Befehle zu ändern: Wenn deine Tests nicht mit npm test laufen, bringt das allow nichts und Claude fragt dich jedes Mal. Trag die echten Befehle deines Projekts ein.
• In accept edits arbeiten, ohne rm bei deny: Im Projekt geht rm von selbst durch. Lass es bei deny und lösch die Dateien, die wegsollen, selbst.
• Glauben, dass das deny jede Form des Befehls abdeckt: bash -c oder /bin/rm kommen durch. Für eine echte Wache kommen der Hook oder die Sandbox dazu.
• Sich auf Anweisungen im Chat verlassen, etwa „lösch nichts“: Sie lenken Claude, blockieren aber nichts. Was nie passieren darf, gehört zu deny.
• Nicht nachsehen, in welchem Modus du bist: Die Sitzung kann in auto starten, ohne dass du es gewählt hast. Lies vor einer langen Aufgabe die Zeile unter dem Prompt.

Checkliste

• Modus gewählt und unter dem Prompt geprüft
• .claude/settings.json mit den Befehlen deines Projekts
• rm, Deployment, publish und echte Datenbank bei deny
• git push bei ask
• Regeln mit /permissions geprüft
• Test gemacht: Tests frei, rm blockiert, push mit Rückfrage
• Kein --dangerously-skip-permissions auf deinem Computer

Häufige Fragen