Claude Code: Freigaben nicht raten – ein Entscheidungslog für read/edit/run/deploy

Freitagabend bat ich Claude Code: „Korrigiere nur die Links auf dieser Seite.” Zurück kam ein Bildschirm voller Bestätigungsfragen. „Darf ich diesen Befehl ausführen?” – und ich, müde wie ich war, drückte Enter, ohne den Inhalt richtig zu lesen.

Am nächsten Morgen stand auf der Live-Seite ein anderer Preis. Beim Korrigieren der Links hatte die KI „nebenbei” auch eine andere Datei angefasst, in der der Preis stand. Den Erlauben-Knopf hatte unmissverständlich ich gedrückt.

Das Problem war nicht, wie klug die KI ist. Das Problem war, dass die Grenze zwischen dem, was ich gestern erlaubt hatte, und dem, was ich heute hätte stoppen müssen, nur in meinem Kopf existierte – und jeden Tag schwankte. Wenn das „Ach, passt schon” je nach Tagesform anspringt, ist der Unfall nur eine Frage der Zeit. Heute schreibe ich, wie du diese Grenze aus dem Kopf herausholst: mit einem Freigabe-Log.

Das Wichtigste in Kürze

• Freigaben in Claude Code werden in vier Arten geteilt: Lesen, Ändern, Ausführen, Veröffentlichen. Damit verschwindet das Zögern.
• Jede Aktion landet in „erlauben / nachfragen / verbieten” – Grund und Prüfbefehl täglich in einer Datei.
• An die KI gehen Recherche und Entwurf, beim Menschen bleiben vier Dinge: Preise, Live-Veröffentlichung, Löschen und Unumkehrbares.
• Eine kopierbare Log-Vorlage plus ein Prompt, der die Einteilung vorab als Entwurf liefert.
• Im Zweifel nicht „erlauben”. Allein das hat die „Nebenbei-Unfälle” fast komplett beseitigt.

Freigaben in Lesen, Ändern, Ausführen und Veröffentlichen teilen

Wer Claude Code nutzt, bekommt ständig Rückfragen. Weil man sie alle in einen Topf wirft und nur „Ja oder Nein” denkt, ist jedes Mal anstrengend. Teilt man die Arbeit in vier Arten, wird die Entscheidung schlagartig leichter.

• Lesen: Nur den Inhalt von Dateien oder Logs ansehen. Grundsätzlich „erlauben” macht keine Probleme.
• Ändern: Eine Datei umschreiben. Ein Tippfehler im Artikel ist harmlos. Die Preistabelle ist etwas anderes.
• Ausführen: Einen Befehl laufen lassen. Ein Funktionscheck ist harmlos, aber alles mit Wirkung nach außen verlangt Vorsicht.
• Veröffentlichen: Auf die Live-Seite spielen. Das behandle ich immer als letzte Bastion.

Selbst beim gleichen „Ändern” wiegt ein Tippfehler im Blogtext völlig anders als die Datei mit den Zahlungseinstellungen. Deshalb lege ich nicht nur die Art der Aktion fest, sondern immer auch „welche Datei” gleich dazu.

Die Entscheidung in drei Stufen einteilen

Sind die vier Arten getrennt, weist man jede in drei Stufen ein. Schwere Begriffe braucht es nicht.

Stufe	Bedeutung	Beispiel
erlauben	Darf still durchlaufen	Artikelordner lesen, Tippfehler im Text korrigieren
nachfragen	Einmal bei mir rückfragen	Preisdatei ändern, live veröffentlichen
verbieten	Diesmal nicht erlaubt	Dateien in Masse löschen, erzwungenes Überschreiben

Es gibt nur einen Trick. Sobald du auch nur ein bisschen zögerst, nicht in „erlauben” stecken. Erst mal nach „nachfragen”. Später, wenn klar ist „das ist jedes Mal sicher”, stufst du es auf „erlauben” hoch. Anfangs die Zügel über alles halten und nur das lockern, was sich als sicher erwiesen hat. Hältst du diese Reihenfolge ein, passiert der Preis-Unfall vom Anfang gar nicht erst.

Täglich in eine Datei festhalten: die Log-Vorlage

Weil man es im Kopf behalten will, bricht es zusammen. Eine Datei pro Tag, in der du nur die heutige Einteilung notierst. Das Format ist egal, aber bei mir hat sich diese Form eingependelt. Du kannst sie direkt kopieren.

{
  "datum": "2026-06-07",
  "umfang": "Nur Artikeltext und CTA-Verlinkung tauschen",
  "lesen":   { "erlauben": ["site/src/content/**", "site/src/lib/gumroadProducts.ts"] },
  "aendern": { "erlauben": ["neue Artikeldateien"], "nachfragen": ["Preis", "Zahlungseinstellungen", "Live-Secrets"] },
  "ausfuehren": { "erlauben": ["npm run build", "Anzeige der Live-URL prüfen"], "nachfragen": ["veröffentlichen", "git push"] },
  "veroeffentlichen": { "erst_nach_pruefung": ["Build läuft durch", "h1 der Live-URL stimmt", "Anzeige je Sprache gesichtet"] },
  "notiz_naechstes_mal": "Preis bleibt weiter nachfragen. CTA-Tausch im Artikel nach Sicherheitsnachweis auf erlauben."
}

Das Schreiben dauert zwei bis drei Minuten. Aber diese zwei, drei Minuten ersparen dir am nächsten Tag die zehn Minuten Grübeln à la „Moment, was hab ich da gestern gemacht?”. Die eine Zeile umfang wirkt unscheinbar, ist aber wichtig. Schreibst du vorher hin, wie weit die heutige Arbeit reicht, merkst du in dem Moment, in dem die KI darüber hinausgeht.

Was an die KI geht und was der Mensch entscheidet

Vermischt man das hier, kracht es. Halte die Grenze klar.

Was du der KI überlassen darfst

• Suchen, welche Dateien wohl betroffen sind
• Einen Entwurf der Änderung erstellen
• Den Unterschied vor und nach der Änderung zeigen
• Den Befehl laufen lassen, der prüft, „ob der Build durchläuft”

Was der Mensch zwingend selbst hält

• Änderungen, die Preise, Zahlung oder das Anmeldeformular berühren
• Veröffentlichung auf der Live-Seite (den Veröffentlichen-Knopf drückst du selbst)
• Löschen von Dateien oder Daten
• Arbeit, deren Rückweg du nicht erklären kannst

Meine Regel ist einfach: Sobald „Geld”, „Live”, „Löschen” oder „nicht rückgängig” im Spiel sind, fälle ich die letzte Entscheidung immer mit eigener Hand. Umgekehrt werfe ich alles andere – Recherche und Entwurf – bedenkenlos der KI hin. Diese Denkweise streife ich auch im Einstieg in Claude Code für Nicht-Entwickler, aber auch ohne Fachwissen reicht es, „nur Geld und Live mache ich selbst” festzulegen.

Ein Prompt, der die Einteilung als Entwurf liefert

Die Einteilung selbst kannst du dir von der KI helfen lassen. Aber nimm das Ergebnis nicht blind hin – am Ende schaust du selbst drüber. Du kannst die folgende Anweisung direkt einfügen.

Teile für die heutige Claude-Code-Arbeit die Aktionen in „erlauben / nachfragen / verbieten" ein.
Es gibt vier Arten: Lesen / Ändern / Ausführen / Veröffentlichen.

Gib für jeden Punkt zurück:
1. Liste der Aktionen, die erlaubt werden dürfen
2. Liste der Aktionen, bei denen einmal nachgefragt wird
3. Liste der Aktionen, die diesmal verboten sind
4. Prüfbefehl zur Sicherheitskontrolle (z. B. npm run build)
5. Notiz fürs nächste Mal (Bedingung für nachfragen -> erlauben)

Aktionen rund um Preis, Zahlung, Live-Veröffentlichung und Löschen im Zweifel in „nachfragen" einordnen.

Der entscheidende Punkt ist die letzte Zeile. Lässt du sie drin, verhinderst du, dass die KI von selbst die Zügel lockert und „das kann ruhig erlauben sein” urteilt. Wer das Schreiben von Prompts weiter verfeinern will, schaut zusätzlich in Prompt-Design für Claude Code.

Wo das im Alltag wirkt (drei Fälle)

1. Blogartikel umbauen Du willst unter einem beliebten Artikel nur einen einzigen Anmeldelink austauschen. Bittest du hier „korrigiere, was zusammenhängt”, ist der Umfang zu groß. Schreib vorab ins Log: „welche Dateien anfassbar”, „welche nicht”, „welche Live-URL prüfen”. Dann wird der Check nach der Arbeit aus „fühlt sich irgendwie gut an” ein „mit dieser Begründung darf das live”.

2. Anfragen sortieren Lass die KI eingegangene Anfragen lesen und dir nur die aussichtsreichen nennen. Das Lesen darf „erlauben” sein. Aber das Eintragen in die Kundenliste bleibt „nachfragen”. Selbst wenn die KI die Einordnung falsch macht, stoppt sie, bevor sie eigenmächtig in die Live-Daten schreibt.

3. Mehrsprachige Artikel vor der Veröffentlichung prüfen Auch wenn die Spracheinstellung im Frontmatter stimmt, bleibt der Text manchmal auf Englisch stehen. Sieh dir je Sprache Überschrift, Einleitung und CTA an und prüfe, ob die Leser dieser Sprache die nächste Handlung verstehen. Diese Sichtung verankerst du im Log als festen „Prüfpunkt bis zur Veröffentlichung”.

Kopieren und loslegen: Prüfskript fürs Freigabe-Log

Ein Log zu schreiben nützt nichts, wenn du dann den wichtigen „Check vor der Veröffentlichung” überspringst. Deshalb gieße den Pflicht-Check vor der Veröffentlichung in ein einziges Skript. Hier ein Beispiel, das die Maschine prüfen lässt, ob der Build durchläuft und ob die Überschrift der Live-URL stimmt. Es läuft, sobald Node.js installiert ist.

node check-before-deploy.mjs https://claudecode-lab.com/de/blog/claude-code-permission-decision-log/

Der Inhalt ist nur das hier.

import { execSync } from "node:child_process";

// Die als Argument übergebene Live-URL prüfen
const url = process.argv[2];
if (!url) {
  console.error("Bitte die zu prüfende Live-URL übergeben");
  process.exit(1);
}

// 1. Prüfen, ob der Build durchläuft (fällt er hier, wird nicht veröffentlicht)
try {
  console.log("Build wird geprüft ...");
  execSync("npm run build", { stdio: "inherit" });
} catch {
  console.error("Build fehlgeschlagen. Veröffentlichung wird gestoppt.");
  process.exit(1);
}

// 2. Prüfen, ob die Live-URL genau eine h1-Überschrift hat
const res = await fetch(url);
const html = await res.text();
const h1Count = (html.match(/<h1[\s>]/g) || []).length;

if (res.status !== 200) {
  console.error(`URL nicht erreichbar (Statuscode: ${res.status}). Veröffentlichung wird überdacht.`);
  process.exit(1);
}
if (h1Count !== 1) {
  console.error(`Es gibt ${h1Count} h1-Überschriften. Erst auf genau eine korrigieren, dann veröffentlichen.`);
  process.exit(1);
}

console.log("Build, URL und Überschrift bestanden. Veröffentlichen ist in Ordnung.");

Erst wenn dieses Skript grün wird, erlaube ich „Veröffentlichen”. Umgekehrt: Was nicht grün wird, wird unter keinen Umständen veröffentlicht. Der Trick ist, die Entscheidung nicht der Tagesstimmung, sondern dem Haken oder Kreuz der Maschine anzuvertrauen.

Häufige Fehler und wie du sie behebst

Ehrlich gesagt: Ich habe so ziemlich alles davon selbst verbockt.

Nur die Einstellung ändern, ohne den Grund festzuhalten. Aktualisierst du nur die Konfigurationsdatei, ohne festzuhalten, „warum du das so gemacht hast”, wiederholt dein Ich von morgen dasselbe Zögern. Die Lösung ist simpel: Schreib in die „Notiz fürs nächste Mal” eine einzige Zeile als Grund. Etwa „Preis bleibt nachfragen, weil er direkt mit Vertrauen zusammenhängt”.

Aus dem Schwung heraus „Veröffentlichen” erlauben. Im Schwung, dass der Build durchlief, erlaubst du gleich bis zur Veröffentlichung. Aber der Check vor der Veröffentlichung ist etwas anderes. Verankere die Punkte – Überschrift der Live-URL, kaputte Darstellung, Mobilansicht – im „erst nach Prüfung” und veröffentliche nicht, bevor der maschinelle Check durch ist.

Leichte und schwere Arbeit gleich behandeln. Drehst du Tippfehler-Korrekturen und Änderungen an Anmeldelink oder Preis im selben „erlauben”, passiert irgendwann der Unfall vom Anfang. Arbeit, die gumroad-Links, Preise oder Formulare berührt, kommt in ein anderes Regal als die Tippfehler-Korrektur. Diese Grenze schreibst du als Regel in So schreibst du eine CLAUDE.md, dann musst du es nicht jedes Mal neu durchdenken.

Häufige Fragen

F. Was ist der Unterschied zwischen Freigabe-Log und Sicherheitseinstellung? A. Die Sicherheitseinstellung legt fest, „was erlaubt ist”, das Freigabe-Log hält fest, „warum du diese Entscheidung heute getroffen hast”. Die Einstellung ist die Regel, das Log eher ein Tagebuch. Mit beidem kann dein Ich von morgen oder das Team dieselbe Entscheidung reproduzieren.

F. Täglich schreiben ist mühsam. Wie hält man das durch? A. Indem du nicht auf Perfektion zielst. Anfangs reichen schon die zwei Spalten „Ändern” und „Veröffentlichen”. Bring es in eine Form, die in zwei bis drei Minuten geschrieben ist, und mach es zur Gewohnheit, sie vor Arbeitsbeginn als erste Eingabe einzufügen – dann bleibst du dran.

F. Darf ich der von der KI vorgeschlagenen Einteilung trauen? A. Als Entwurf ist sie praktisch, aber die letzte Entscheidung trifft der Mensch. Gerade Zeilen rund um Preis, Live und Löschen stufst du auf „nachfragen”, selbst wenn die KI „erlauben ist okay” sagt. Ziel ist, den Aufwand der Entscheidung zu senken – nicht, die Entscheidung selbst abzuwälzen.

F. Worauf achten, wenn man es im Team nutzt? A. Sammle die Logs an einem Ort und schreib bei jeder Aktion in „erlauben” den Grund auf, der für jeden zur selben Entscheidung führt. Ein „erlauben” ohne Grund wird je nach Person anders ausgelegt und ist die Wurzel von Unfällen. Für das schrittweise Ausweiten von Freigaben hilft auch Schritte zu mehr Autonomie – aber sicher.

F. Braucht man das auch für einen kleinen Blog? A. Je kleiner der Maßstab, desto direkter schlagen Preis- oder Link-Unfälle auf den Umsatz durch. Gerade Einzelne und kleine Teams profitieren davon, mit der einen Regel „nur Geld und Live = nachfragen” zu starten.

Weiterführende Links

• Berechtigungen in Claude Code – der Leitfaden
• Claude Code: Einstiegsleitfaden
• Anthropic offiziell: Claude Code settings – Dokumentation

Was beim Ausprobieren herauskam

Nachdem ich dieses Freigabe-Log rund zwei Wochen durchgehalten hatte, wirkte am stärksten ausgerechnet die „leichte Arbeit”. Tippfehler-Korrekturen kann ich beruhigt auf „erlauben” legen, aber Preis, Links, Anmeldeformular und Veröffentlichungseinstellung bleiben auf „nachfragen”. Allein dadurch, dass ich diese Unterscheidung vorab aufschrieb, verschwand der Aufwand, nach jeder KI-Antwort erneut zu überlegen „durfte ich diese Arbeit eigentlich erlauben?”.

Am meisten gezögert habe ich tatsächlich bei „Ausführen” und „Veröffentlichen”. Den Build darf ich erlauben, aber eine Veröffentlichung ohne geprüfte Live-URL ist noch zu früh. Nachdem ich einmal Überschrift, kaputte Darstellung und Mobilansicht mit eigenen Augen geprüft hatte, konnte ich dieselbe Art Veröffentlichung beim nächsten Mal auf „erlauben” hochstufen. Weil die Stufen so im Protokoll bleiben, ist das Freigabe-Log weniger ein steifes Sicherheitsdokument als vielmehr eine Notiz, die die täglichen Entscheidungen leichter macht – das ist mein aktuelles Fazit.

Wenn du die Berechtigungsgrenzen für dein eigenes Team zurechtschneiden oder die Regeln für die Live-Veröffentlichung gemeinsam durchgehen willst, lässt sich das in Schulung & Beratung in konkreten Betrieb übersetzen.