Claude Code Permission Safety Ladder: Zugriff kontrolliert erweitern

Die schwierige Anfängerfrage ist nicht der Prompt, sondern was Claude Code ohne Nachfrage ausführen darf. Alles auf ask ist langsam. Alles auf allow ist riskant. Die Permission Safety Ladder erweitert Zugriff in kontrollierten Stufen.

Leser aus einem Berechtigungs-Guide brauchen eine Reihenfolge für settings. Dieser Artikel trennt Rechte für Woche eins von Aktionen, die denied oder menschlich freigegeben bleiben.

Weiterführende Artikel: claude-code-permissions-guide, claude-code-security-best-practices, claude-code-harness-lite-workflow.

Warum dieses Muster vor die erste Änderung gehört

Claude Code ist am stärksten, wenn die Aufgabe klare Grenzen hat. Eine gute Grenze nennt lesbare Dateien, editierbare Dateien, verbotene Aktionen und den Nachweis, der die Arbeit beendet. Ohne diese Grenze kann ein kleiner Anfänger-Prompt zu einer großen Umschreibung werden, und eine Content-Änderung kann PDF, Gumroad oder Beratung beschädigen.

Dieses Muster hilft auch beim Umsatz, weil es technischen Nachweis mit Leser-Nachweis verbindet. Eine Seite, die lokal baut, aber Leser zum falschen Produkt schickt, ist nicht fertig. Wer Scope, Befehl, öffentliche URL und CTA notiert, verbessert morgen aus Belegen statt aus Erinnerung.

Praktischer Ablauf

1. Level 0 erlaubt nur Read, Glob und Grep
2. Level 1 ergänzt Nachweise wie git status, git diff und build
3. Level 2 lässt Write/Edit für begrenzte Pfade wie content und tests auf ask
4. Level 3 erlaubt Deploy-Checks nur mit expliziter Bestätigung
5. Secrets, force push, destruktives Löschen und Billing bleiben denied oder freigabepflichtig

Situation	Sicherer Schritt	Nachweis
Persönliche Content-Site	MDX und Bilder bleiben ask, build darf allowed sein, deploy braucht Bestätigung, CTA-Checks werden Proof.	build, diff, URL
SaaS-Dashboard	UI-Komponenten und Tests sind begrenzte Edits, auth, billing und migrations bleiben Freigabe.	screenshot, test
Team-Workflow	Das Permission-Level steht in CLAUDE.md, damit Reviewer die Autonomie kennen.	log, command, handoff

Der erste Durchlauf bleibt kurz. Das Audit soll eine Entscheidung erzeugen, keinen Riesenbericht. Wenn nach 20 Minuten keine Entscheidung klar ist, liest man eine weitere Datei, statt mit Änderungen zu beginnen.

Kopierbarer Prompt und Code

Entwirf eine vierstufige Claude-Code-Berechtigungsleiter für dieses Repository. Trenne read-only, proof commands, limited edits und deploy checks. Liste Aktionen, die denied bleiben müssen.

{
  "permissions": {
    "allow": [
      "Read(**)",
      "Glob(**)",
      "Grep(**)",
      "Bash(npm.cmd run build)",
      "Bash(git status --short)",
      "Bash(git diff --stat)"
    ],
    "ask": [
      "Write(site/src/content/**)",
      "Edit(site/src/content/**)",
      "Bash(npm install *)",
      "Bash(npx wrangler pages deploy *)"
    ],
    "deny": [
      "Bash(git push --force*)",
      "Bash(rm -rf*)",
      "Read(.env*)"
    ]
  }
}

Der Code ist absichtlich klein. Er macht aus einer Betriebsregel ein prüfbares Objekt: Scope existiert, Schutzbereiche existieren, ein Prüfbefehl ist verbunden. Die Form passt für Artikel, Apps, Debugging oder Team-Handoff.

Drei reale Beispiele

Persönliche Content-Site

MDX und Bilder bleiben ask, build darf allowed sein, deploy braucht Bestätigung, CTA-Checks werden Proof.

Wichtig ist der Nachweis. Bewahren Sie einen Befehl, eine sichtbare Seite oder eine Notiz auf, die zeigt, dass die Arbeit den Leser erreicht hat.

SaaS-Dashboard

UI-Komponenten und Tests sind begrenzte Edits, auth, billing und migrations bleiben Freigabe.

Wichtig ist der Nachweis. Bewahren Sie einen Befehl, eine sichtbare Seite oder eine Notiz auf, die zeigt, dass die Arbeit den Leser erreicht hat.

Team-Workflow

Das Permission-Level steht in CLAUDE.md, damit Reviewer die Autonomie kennen.

Wichtig ist der Nachweis. Bewahren Sie einen Befehl, eine sichtbare Seite oder eine Notiz auf, die zeigt, dass die Arbeit den Leser erreicht hat.

Fehlerfälle, die man vermeiden sollte

• Deploy oder Push zu früh zu erlauben veröffentlicht vor der Prüfung.
• Alles auf ask macht den Ablauf zu langsam.
• Settings ohne deny lassen gefährliche Aktionen unklar.

Ein weiterer Fehler ist Lokalisierungsdrift. Der englische Artikel kann den richtigen Produktpfad erklären, während eine andere Sprache einen alten CTA behält. Darum prüft man öffentlich h1, Einstieg und CTA je Sprache, nicht nur frontmatter lang.

Leser zu PDF, Gumroad und Beratung führen

Wenn Leser noch Befehlssicherheit brauchen, passt das kostenlose Cheatsheet. Wenn Setup, Rechte, CLAUDE.md, Hooks, MCP oder CI/CD blockieren, ist der Setup Guide der beste nächste Kauf. Wer wiederholt Review-, Debugging- und Refactoring-Prompts schreibt, sollte 50 Prompt Templates nutzen. Für Team-Rollout, Workflow-Design oder Umsatzpfade ist Beratung sinnvoll. Einen Vergleich gibt es auf products.

Nicht jeder Leser soll sofort zum bezahlten Produkt. Anfänger brauchen oft zuerst ein reibungsarmes PDF. Wer Prompts wiederholt, ist näher an Templates. Wer bei permissions, CLAUDE.md, hooks, MCP oder CI/CD blockiert, ist näher am Setup Guide. Teams mit Prozessfragen sind näher an Beratung.

Was vor und nach der Veröffentlichung geprüft wird

Prüfung bedeutet hier mehr als HTTP 200. h1, Einstieg, heroImage, interne Links, Gumroad-Links und Beratungspfad müssen zur gleichen Leserabsicht passen.

Bei mehrsprachiger Veröffentlichung werden Japanisch, Englisch, Chinesisch, Koreanisch, Spanisch, Französisch, Deutsch, Portugiesisch, Hindi und Indonesisch einzeln geprüft. Der slug kann stimmen, obwohl der Text alt ist. Mobile Screenshots zeigen Einstieg und CTA gemeinsam.

Zahlen, die als Nächstes wichtig sind

Beobachten Sie PDF-Starts, Gumroad-Klicks, product-page visits, training-page visits, Suchquelle, Länder-Mix und Klickrate von Artikel zu CTA. Steigen PV ohne Gumroad-Klicks, muss der Produktfit stärker werden. Steigen Beratungsbesuche aus technischen Artikeln, braucht der Leser wahrscheinlich Workflow-Design.