Gefährliche Claude-Code-Prompts vermeiden: Auto-Push, Testverzicht und vage Fixes stoppen

Claude Code zu bitten: “Mach alles fertig, push es und überspring die Tests erst einmal” klingt schnell. Bei einem Werkzeug, das Dateien ändern, Shell-Befehle ausführen, git bedienen und Dokumentation prüfen kann, verliert man mit so einem Satz aber leicht die Kontrolle über den Review.

Dieser Artikel soll nicht dramatisieren, sondern vorbeugen. Ich habe am 3. Juni 2026 die offiziellen Claude-Code-Dokumente geprüft, vor allem Permission Modes, /permissions, settings.json und Common Workflows, und daraus sichere Alternativen formuliert, die du direkt in der Praxis nutzen kannst.

flowchart LR
  A["Auftrag schreiben"] --> B["Nur Untersuchung erlauben"]
  B --> C["Plan reviewen"]
  C --> D["Eng ändern"]
  D --> E["Tests und diff prüfen"]
  E --> F["Mensch entscheidet push/deploy"]

Was einen Prompt gefährlich macht

Gefährlich heißt hier nicht bösartig. Gemeint ist ein Auftrag, bei dem Umfang, Befugnis oder Erfolgskriterium unklar sind, während Claude Code starke Aktionen ausführen kann. Für Einsteiger: Eine Berechtigungsgrenze ist die Stelle, an der der Agent fragen muss, bevor er Dateien ändert, Befehle ausführt oder außerhalb des Projekts arbeitet.

Claude Code kann Projektdateien lesen und durchsuchen, Code bearbeiten, Tests starten und git verwenden. Die offiziellen Dokumente erklären, dass Claude Code in einer lokalen Sitzung mit den Dateien und Terminal-Fähigkeiten arbeiten kann, die dem Nutzer zur Verfügung stehen. Deshalb sollte ein guter Prompt nicht nur sagen, was erlaubt ist, sondern auch, was verboten bleibt.

Riskante Formulierung	Sichere Alternative
Repariere alles	Ziel- und Ausschlussdateien nennen, dann zuerst einen Plan verlangen
Push es, wenn es fertig ist	Diff und Testergebnis zusammenfassen; push entscheide ich
Tests überspringen	Kleinsten sinnvollen Check vorschlagen und Gründe nennen, falls er nicht läuft
Produktions-DB prüfen	Nur dev/staging nutzen; Produktions-SQL nur generieren, nicht ausführen
Alle Bestätigungen überspringen	In Plan mode untersuchen, danach Schritt für Schritt mit Freigabe
Altes Zeug löschen	Löschkandidaten zuerst listen; nur nach Freigabe löschen
Alles auf latest aktualisieren	Security-Fixes, Minor-Updates und Major-Updates trennen
Recherchieren und umsetzen	Offizielle Quellen nennen und Erkenntnisse von Änderungsvorschlägen trennen

Berechtigungsgrenzen aus der aktuellen Doku

Der Permission Mode von Claude Code ändert sich nicht, nur weil man im Chat “mach es sicher” schreibt. Im CLI wechselst du mit Shift+Tab oder --permission-mode; in IDEs und Desktop über den Moduswähler; dauerhafte Vorgaben stehen in settings.json.

Am 3. Juni 2026 beschreibt die offizielle Doku diese Hauptmodi: default fragt vor Aktionen, die nicht nur lesen; acceptEdits akzeptiert Dateiänderungen und typische Dateisystemoperationen automatisch; plan eignet sich zum Lesen, Erkunden und Planen vor Änderungen; auto ist eine Research Preview mit Hintergrundprüfungen; dontAsk verweigert nicht vorab genehmigte Tools; bypassPermissions gehört nur in isolierte Container oder VMs.

Mit /permissions siehst du Allow-, Ask- und Deny-Regeln. Deny hat Vorrang. Teams sollten daher Force-Pushes, .env-Zugriffe und Produktions-Deploy-Befehle sperren, statt sich auf Erinnerung zu verlassen. Gemeinsame Regeln gehören in .claude/settings.json; persönliche Experimente in .claude/settings.local.json.

Minimales settings.json

Das folgende Beispiel ist ein Startpunkt. Passe nur die Kommandonamen an dein Projekt an.

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test *)",
      "Bash(git status)",
      "Bash(git diff *)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(npm publish *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Bash(git push --force *)",
      "Bash(* --no-verify *)"
    ]
  }
}

Wichtig ist Zurückhaltung. Eine breite Regel wie Bash(*) macht die Prüfschicht dünn. Wiederholbare Checks wie npm run test und git diff vorzuerlauben hält die Sitzung schnell, ohne riskante Aktionen zu verstecken.

Use Case 1: Bugfix

Riskant ist: “Fix alles rund um Login und push es, wenn es läuft.” Der Umfang ist zu groß, und die Remote-Aktion hängt direkt am Edit.

Ziel: Behebe den Fehler, bei dem die Session direkt nach dem Login abläuft.
Umfang: Nur src/auth/**, src/session/** und tests/auth/**.
Verboten: git push, deploy, Zugriff auf Produktions-DB, Lesen von .env.
Vorgehen:
1. Relevante Dateien lesen und bis zu 3 wahrscheinliche Ursachen nennen.
2. Änderungsplan vorschlagen und auf meine Freigabe warten.
3. Nach Freigabe die kleinste sinnvolle Änderung machen.
4. npm run test -- auth ausführen und Fehler zusammenfassen.
5. Zum Schluss git-diff-Zusammenfassung und Restrisiken melden.

So kann Claude Code untersuchen, bearbeiten und prüfen, während die Review-Punkte erhalten bleiben. Unnötige Querschnittsänderungen werden deutlich unwahrscheinlicher.

Use Case 2: Refactoring

Riskant ist: “Räum die alte Implementierung auf und lösche alles Unnötige.” Wörter wie alt, sauber und unnötig sind instabil.

Ziel: Doppelte Validierung im Billing-Modul zusammenführen.
Erlaubte Änderungen: src/billing/validators.ts und zugehörige Tests.
Nicht ändern: migrations/**, prisma/**, public/**, package-lock.json.
Löschregel: Nur Löschkandidaten listen. Ohne Freigabe nichts löschen.
Prüfung: npm run test -- billing und npm run lint ausführen.
Ausgabe: Kurz Gründe, Kompatibilitätsfolgen und fehlende Tests melden.

Bei Refactorings ist die Ausschlussliste oft wichtiger als die Zielliste. Migrationen, Lockfiles und generierte Dateien lassen sich optisch leicht falsch bewerten.

Use Case 3: Review vor dem Deploy

Riskant ist: “CI ist langsam, überspring es und shippe in Produktion.” --no-verify kann mehr als Lint überspringen, etwa Secret-Scans und Hooks.

Ziel: Kurzen Release-Check durchführen.
Erlaubte Befehle: git status, git diff, npm run test -- --runInBand, npm run build.
Verbotene Befehle: git push, deploy, --no-verify, npm publish.
Entscheidung:
- Stoppen, wenn Tests oder Build fehlschlagen.
- Nur die letzten 80 Zeilen eines Fehlerlogs zusammenfassen.
- Status als Bereit / Muss repariert werden / Entscheidung offen melden.

Deployments berühren Kunden, Abrechnung, Suchindizes, Caches und Support. Claude Code sollte Belege vorbereiten; der finale Release-Schritt bleibt ausdrücklich menschlich.

Use Case 4: Recherche und Dokumentation

Riskant ist: “Such die neuesten Infos und bau sie irgendwie in den Artikel ein.” Externe Fakten ändern sich, daher müssen Quellen und Bearbeitungsumfang getrennt bleiben.

Ziel: Text zu Claude-Code-Permission-Modes aktualisieren.
Quellen: Offizielle Dokumentation bevorzugen und URLs am Ende auflisten.
Verboten: Keine Features behaupten, die offizielle Doku nicht bestätigt.
Vorgehen:
1. Tabelle mit Differenzen zwischen aktuellem Artikel und offizieller Doku erstellen.
2. Nur Änderungsvorschläge machen; vor dem Bearbeiten warten.
3. Nach der Änderung alte Links und description-Länge prüfen.

Bei Rechercheaufgaben ist Claude Code zuerst Quellenprüfer und Diff-Sortierer, erst danach Autor.

Konkrete Fehlerfälle

Erstens: unbegrenzte Retries. “Wiederholen, bis es klappt” kann aus einer Störung zusätzliche Kosten und Rate-Limit-Druck machen. Lege maximale Versuche, Wartezeit und Abbruchbedingungen fest.

Zweitens: Secrets. Echte API-Keys im Prompt können in Gesprächsverlauf, lokalen Logs und Subagent-Übergaben bleiben. Werte gehören in Umgebungsvariablen oder Secret Manager; Prompts nennen nur Variablennamen.

Drittens: Dependency-Upgrades. “Alle Pakete auf latest” kann Major-Versionen mit Breaking Changes einziehen. Nutze npm outdated, trenne Security-Fixes von normalen Updates und prüfe Major-Upgrades separat.

Viertens: Cleanup und Migrationen. “DB-Dateien aufräumen” kann als Löschen der Migrationshistorie verstanden werden. Lass zuerst eine Liste erstellen und stoppe bei Produktionsdaten spätestens bei generiertem SQL.

Review-Checkliste

Füge diese Liste an riskante Prompts an.

Sicherheitscheck:
[ ] Ziel- und Ausschlussdateien genannt
[ ] git push / deploy / publish verboten oder freigabepflichtig gemacht
[ ] Produktions-DB, Produktions-API und kostenpflichtige Aktionen blockiert
[ ] .env, private Keys und personenbezogene Daten ausgeschlossen
[ ] Plan mode oder Plan vor Änderungen verlangt
[ ] Mindestens Test, Lint oder Build eingeplant
[ ] Bei Fehlern stoppen und Logs zusammenfassen lassen
[ ] Am Ende diff, ausgeführte Befehle und Restrisiken verlangen

Wenn du diese Regeln nicht jedes Mal neu schreiben willst, findest du auf der Produktseite Prompt-Pakete und Checklisten. Für Teams lassen sich CLAUDE.md, Berechtigungen, Review-Gates und Onboarding-Übungen mit echtem Repository-Bezug über Claude-Code-Training und Beratung gestalten.

Verwandte Artikel

• 7 reale Produktionsvorfälle mit Claude Code und vollständige Wiederherstellung
• Vollständiger Leitfaden zu Claude-Code-Sicherheit
• Vollständiger Leitfaden zu Claude-Code-Berechtigungen
• Claude-Code-Freigabefluss und Sandbox-Design

Offizielle Links

• Claude Code: Choose a permission mode
• Claude Code: Configure permissions
• Claude Code settings
• Claude Code common workflows

実際に試した結果: In Masas Arbeitsweise halfen drei Regeln am meisten: erst Plan mode, Änderungsumfang auf zwei bis fünf Dateien begrenzen und push/deploy als menschliche Entscheidung behalten. Gefährliche Prompts zu vermeiden bremst Claude Code nicht aus; es macht die Übergabe präzise genug, damit die Arbeit schneller und ruhiger geprüft werden kann.