Claude Code Approval- und Sandbox-Leitfaden | Sichere Einstellungen fuer die taegliche Arbeit

Nur weil Approval aktiviert ist, ist Claude Code noch nicht automatisch sicher. Zu viele Rueckfragen fuehren dazu, dass man nur noch mechanisch bestaetigt. Zu viel allow fuehrt dazu, dass Aktionen mit echter Wirkung zu leicht durchrutschen.

Dieser Artikel beantwortet die operative Frage nach dem Einstieg: Was sollte automatisch laufen, was sollte nachfragen, und was sollte direkt verboten sein? Als Hintergrund passen Harness Engineering, Permissions Guide und Security Failure Cases.

Approval ist nicht dasselbe wie Sicherheit

Ein brauchbares Setup besteht meist aus drei Schichten:

Kontrolle	Aufgabe	Beispiele
permission rules	allow / ask / deny festlegen	secrets, destruktive Befehle, deploy
approval flow	Vor irreversiblen Nebenwirkungen stoppen	git push, publish, send
sandbox	Reichweite der Shell verkleinern	build, Verifikation, explorative Skripte

Die offiziellen Referenzen bleiben permissions, settings und hooks. Die praktische Kernaussage ist: Reversibles sollte schnell sein, Irreversibles absichtlich langsam.

Eine einfache Aufteilung fuer den Alltag

Aktion	Empfehlung	Grund
Dateien lesen, suchen, Diffs pruefen	allow	Niedriges Risiko
build, test, lint, analytics	allow	Darf die Iteration nicht bremsen
Code auf einem Branch aendern	ask oder Session-allow	Haengt vom Repo ab
git push, deploy, publish, send	ask	Externer Seiteneffekt
.env lesen, rm -rf, git reset --hard	deny	Zu grosser Schaden
Schreibende externe APIs	ask	Wirkung in echten Systemen

Solide Basis fuer .claude/settings.json

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Read",
      "Grep",
      "Glob",
      "Bash(npm run build)",
      "Bash(npm run test)",
      "Bash(node scripts/analytics-report.mjs *)"
    ],
    "ask": [
      "Edit",
      "Write",
      "Bash(git push *)",
      "Bash(npx wrangler pages deploy *)",
      "Bash(node scripts/outreach-send-mails.mjs --send)",
      "WebFetch(domain:api.gumroad.com)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Bash(rm -rf *)",
      "Bash(git reset --hard *)",
      "Bash(curl * | sh)"
    ]
  },
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": false
  }
}

Wenn dein Umfeld kein brauchbares Sandboxing bietet, verschiebe mehr Aktionen mit Aussenwirkung nach ask.

Hooks machen schlechte Gewohnheiten schwerer

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash(git add*)",
        "hooks": [{
          "type": "command",
          "command": "git diff --cached --name-only | grep -E '^\\.env' && echo 'Blocked: .env staged' && exit 1 || exit 0"
        }]
      },
      {
        "matcher": "Bash(npx wrangler pages deploy*)",
        "hooks": [{
          "type": "command",
          "command": "npm run build"
        }]
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [{
          "type": "command",
          "command": "npm run test || true"
        }]
      }
    ]
  }
}

Das Muster dahinter:

• secrets vor dem Commit blockieren
• build vor dem Deploy erzwingen
• nach Edits deterministisch pruefen

Drei reale Workflows

1. Content-Site

Nicht das Schreiben selbst ist der heikle Teil, sondern Analytics lesen, Thema waehlen, alle Sprachen erzeugen, builden, deployen, die Live-URL oeffnen und mobil mit Playwright pruefen.

2. App-Repository

Code lesen, Diffs analysieren, auf einem Branch refaktorieren und Tests laufen lassen ist oft sicher. Shared-Branch-Pushes, Migrationen, Produktions-APIs und Infra-Aenderungen sollten in ask bleiben.

3. Outreach / Backoffice

Recherche und Entwuerfe koennen automatisch laufen. Senden, Publishen und echte Datensaetze aendern nicht.

Drei haeufige Fehler

1. Alles auf ask setzen und dann trotzdem blind bestaetigen.
2. --dangerously-skip-permissions zur Gewohnheit machen.
3. Einen erfolgreichen build mit einem erfolgreichen Release verwechseln.

Gerade der dritte Fehler ist bei mehrsprachigen Seiten haeufig: build ist grün, aber eine Live-URL ist alt oder eine Sprache fehlt.

Was wir heute praktisch geaendert haben

Bei ClaudeCodeLab gilt jetzt:

• pro Run muss ein neuer Artikel live gehen
• zusaetzlich muss eine bestehende Aufgabe vorankommen
• Playwright prueft die Mobile-Ansicht
• alle Sprach-URLs fuer denselben slug werden in Produktion kontrolliert

Sicherheit entsteht durch klare Betriebsregeln, nicht durch einen vagen Hinweis auf Vorsicht.

Naechster Schritt

Starte mit dem kostenlosen Cheatsheet. Wenn du kopierbare Settings, Hooks und Setup-Beispiele willst, nutze die English products page. Fuer Hilfe bei Rollout, Review-Flow oder sicheren Automationsgrenzen ist die consultation page der richtige naechste Schritt.