10 gefährliche Prompt-Muster in Claude Code | Was Sie vermeiden sollten und sichere Alternativen

Schreiben Sie Prompts mit dem Gedanken „Das wird er schon verstehen”? Claude Code führt Anweisungen wortwörtlich aus. Vage oder gefährliche Anweisungen führen zu unbeabsichtigten Ergebnissen.

Dieser Artikel beschreibt 10 gefährliche Prompt-Muster, die zu echten Vorfällen geführt haben, zusammen mit sicheren Alternativen für jedes Muster. Wenn Sie nach dem Lesen eines dieser Muster erkennen, ändern Sie es sofort.

---

Muster 1: „Lies alles und verstehe das gesamte Projekt”

Warum es gefährlich ist

❌ „Lies dieses gesamte Repository und verstehe es, bevor du implementierst"

Bei einem Repository mit Hunderten von Dateien explodiert der Kontext. Es werden Zehntausende von Tokens verbraucht, und die Verarbeitung stoppt mit einem Prompt is too long-Fehler. Wenn es mitten im Lesen stoppt, erfolgt die Implementierung auf Basis eines unvollständigen Verständnisses.

Außerdem werden alle Dateien, die .env oder geheime Schlüssel enthalten, in den Kontext geladen.

Sichere Alternative

✅ „Überprüfe die Struktur des Verzeichnisses src/api/ und lies nur auth-bezogene Dateien"
✅ „Lies zunächst nur package.json und README, um einen Projektüberblick zu bekommen"
✅ „Verwende Grep, um authentifizierungsbezogene Dateien zu finden, bevor du sie liest"

Kernpunkt: Begrenze den Leseumfang explizit. Claude Code versucht breit zu lesen, wenn nichts angegeben ist.

---

Muster 2: „Bei einem Fehler automatisch wiederholen”

Warum es gefährlich ist

❌ „Wenn beim Aufruf der externen API ein Fehler auftritt, automatisch wiederholen, bis es klappt"

Wenn ein externer Dienst ausgefallen ist, wird die API in einer Endlosschleife bombardiert. Es gibt reale Vorfälle mit Zehntausenden von Aufrufen in einer Stunde, wobei Rechnungen auf Hunderte oder Tausende von Euro angestiegen sind. Dies kommt besonders häufig bei nächtlichen Batch-Jobs vor, die unbemerkt bis zum Morgen laufen.

Sichere Alternative

✅ „Bei einem Fehler maximal 3 Mal wiederholen.
   1 Sekunde vor dem 1. Versuch warten, 4 Sekunden vor dem 2., 16 Sekunden vor dem 3.
   Wenn alle 3 fehlschlagen, Fehler protokollieren und Verarbeitung stoppen"

✅ „Verwende folgenden Code für Wiederholungsversuche:
   withRetry(fn, { maxAttempts: 3, baseDelayMs: 1000 })"

---

Muster 3: „Direkt zur Produktions-DB verbinden und prüfen”

Warum es gefährlich ist

❌ „Verbinde dich mit der Produktions-DB unter DATABASE_URL, prüfe die Benutzeranzahl und nimm dann Korrekturen vor"

Was als „nur prüfen” beginnt, birgt das Risiko, dass nachfolgende Korrekturabfragen gegen die Produktions-DB ausgeführt werden. Wenn nach einem SELECT versehentlich DELETE oder UPDATE folgt, sind Produktionsdaten verloren. Die Verbindung zur Produktion löst leicht Operationen jenseits des beabsichtigten Rahmens aus.

Sichere Alternative

✅ „Verbinde dich mit der Entwicklungs-DB (DATABASE_URL_DEV) und prüfe die Benutzeranzahl.
   Keine Verbindung zur Produktionsumgebung"

✅ „Erstelle die Abfrage, führe sie aber nicht aus.
   Ich überprüfe sie und führe sie selbst aus"

✅ In CLAUDE.md:
„Das Ausführen von Abfragen gegen die Produktions-DATABASE_URL ist verboten.
 Erst auf Staging prüfen, nur nach Benutzerfreigabe ausführen"

---

Muster 4: API-Schlüssel direkt in den Prompt einfügen

Warum es gefährlich ist

❌ „Verwende QIITA_TOKEN=abc123def456, um auf Qiita zu posten"
❌ „Verwende sk-ant-api03-xxxxx, um die Anthropic API aufzurufen"

Im Prompt enthaltener Inhalt wird als Gesprächsverlauf gespeichert. Er wird beim Delegieren an Unteragenten unverändert weitergegeben. Er verbleibt in Protokollen im lokalen .claude/-Verzeichnis und kann über Backup-Tools oder Code-Sharing unbeabsichtigt nach außen gelangen.

Sichere Alternative

✅ „Verwende QIITA_TOKEN aus .env, um scripts/qiita-publish.mjs auszuführen"
   ← Der Token-Wert existiert nur in .env; nur der Variablenname kommt in den Prompt

✅ Umgebungsvariablen im Skript lesen:
   const token = process.env.QIITA_TOKEN;
   if (!token) throw new Error("QIITA_TOKEN ist nicht gesetzt");

---

Muster 5: „Konflikt lösen und in Produktion pushen”

Warum es gefährlich ist

❌ „Es gibt einen Konflikt mit dem main-Branch. Löse ihn auf und pushe in Produktion"

Als Mittel zur „Konfliktlösung” könnte git push --force gewählt werden. Dies riskiert das Löschen von Commits der Teammitglieder. Außerdem kann „in Produktion pushen” zu einem direkten Push führen, der CI/CD umgeht.

Sichere Alternative

✅ „Prüfe den Konflikt mit main und schlage eine Merge-Strategie vor.
   Warte auf meine Freigabe, bevor du tatsächlich mergst und pushst"

✅ In CLAUDE.md:
„git push --force ist verboten.
 Wenn Force nötig ist, --force-with-lease verwenden und Benutzer bestätigen lassen"

// .claude/settings.json
{
  "permissions": {
    "deny": [
      "Bash(git push --force *main*)",
      "Bash(git push --force *master*)"
    ]
  }
}

---

Muster 6: „Alle alten Dateien löschen und aufräumen”

Warum es gefährlich ist

❌ „Lösche alle Dateien in dist/, .cache/ und alte Log-Dateien, um aufzuräumen"

Da „alt” mehrdeutig ist, können notwendige Dateien gelöscht werden. Insbesondere .cache/-Verzeichnisse können wichtige OS- oder toolspezifische Daten enthalten. Die gleichzeitige Angabe mehrerer Verzeichnisse resultiert in rm -rf dist .cache logs/, was auf unbeabsichtigte Pfade übertragen werden kann.

Sichere Alternative

✅ „Lösche nur den Inhalt des Verzeichnisses site/dist/.
   Lass das Verzeichnis selbst bestehen. Berühre keine anderen Verzeichnisse"

✅ „Zeige mir die Liste der zu löschenden Dateien, bevor du sie löschst, damit ich bestätigen kann.
   Lösche nach meiner Freigabe"

---

Muster 7: „Alles automatisch genehmigen und auf einmal ausführen”

Warum es gefährlich ist

❌ „Überspringe alle Bestätigungen und führe alles bis zum Ende aus"
❌ „Führe es mit der Option --dangerously-skip-permissions aus"

Der Genehmigungsfluss ist ein Sicherheitsmechanismus. Wird er übersprungen, geht Claude Code mit dem vor, was es als „effizienteste” Methode beurteilt. Das könnte rm -rf, Force-Push oder Schreibvorgänge in die Produktions-DB bedeuten—alles ohne Bestätigung.

Sichere Alternative

✅ „Liste zuerst die Schritte für diese Aufgabe auf.
   Nach meiner Freigabe einen Schritt nach dem anderen ausführen und das Ergebnis bei jedem Schritt prüfen"

✅ Für die Automatisierung nur vertrauenswürdige Operationen erlauben:
   "allow": ["Read(**)", "Glob(**)", "Bash(npm run test)"]

---

Muster 8: „Migrationen aktualisieren und DB aufräumen”

Warum es gefährlich ist

❌ „Die Migrationsdateien sind unordentlich. Räum sie auf und bringe alles auf den neuesten Stand"

„Aufräumen” kann als Löschen alter Migrationsdateien interpretiert werden. Wenn die Migrationshistorie weg ist, wird das Einrichten neuer Umgebungen oder ein Rollback unmöglich. Wenn ein migrate reset-artiger Befehl ausgeführt wird, könnten Produktionsdaten gelöscht werden.

Sichere Alternative

✅ „Zeige die Liste der Migrationsdateien und weise nur auf Duplikate oder Probleme hin.
   Nimm keine Änderungen vor"

✅ „Prüfe nicht angewendete Migrationen und zeige das SQL, das ausgeführt werden würde.
   Nach meiner Freigabe ausführen"

✅ In CLAUDE.md:
„Migrationsdateien nicht löschen.
 Immer Benutzerbestätigung einholen, bevor Migrationen mit ALTER/DROP ausgeführt werden"

---

Muster 9: „Alle Pakete auf die neueste Version aktualisieren”

Warum es gefährlich ist

❌ „Die npm-Pakete sind veraltet. Aktualisiere alles auf die neueste Version"

npm update oder npm install paket@latest kann Major-Versionen erhöhen. Wenn Breaking Changes enthalten sind, kann der lokale Build durchlaufen, aber der Dienst nach dem Produktions-Deployment ausfallen. Kaskadierender Abhängigkeitsbruch ist ebenfalls häufig.

Sichere Alternative

✅ „Führe npm outdated aus und zeige die Liste der aktualisierbaren Pakete.
   Alles, was eine Major-Version erhöht, prüfe ich separat"

✅ „Aktualisiere nur Pakete mit Sicherheitslücken (erkannt durch npm audit)"

✅ „Aktualisiere nur react und next.js auf die neueste Minor-Version.
   Die Major-Version nicht erhöhen"

---

Muster 10: „Zuerst deployen, Tests kommen später”

Warum es gefährlich ist

❌ „Ich schreibe die Tests später, deploye jetzt erst mal"
❌ „CI ist langsam, überspringe es mit --no-verify und pushe"

Tests und CI sind nicht „langsam”—sie „schützen dich”. Das schlimmste Muster ist, Bugs erst in der Produktion zu entdecken, nachdem man sie übersprungen hat. --no-verify deaktiviert alles einschließlich Git-Hooks, sodass auch Secret-Scanning und Lint übersprungen werden.

Sichere Alternative

✅ „Schreibe zuerst die Tests und deploye, nachdem sie bestanden haben.
   Auch wenn die Abdeckung unzureichend ist, reichen die Hauptpfade"

✅ „Untersuche, warum CI langsam ist, und beschleunige es durch Caching.
   Nicht überspringen"

✅ In CLAUDE.md:
„--no-verify ist verboten.
 Niemals irgendein Mittel zum Überspringen von CI verwenden"

---

Zusammenfassung: 3 Prinzipien für sichere Prompts

Prinzip 1: Bereich explizit angeben „Alle”, „alles” und „gesamte” sind Gefahrenwörter. Gib genau an, was gelesen, geändert und gelöscht werden soll.

Prinzip 2: Bestätigungsschritte beibehalten Füge vor „ausführen” ein „prüfen”, „vorschlagen” oder „Liste zeigen” ein. Besonders bei Operationen, die die Produktion betreffen.

Prinzip 3: Niemals Geheimnisse in Prompts schreiben API-Schlüssel, Passwörter und Verbindungsstrings kommen in .env. Nur Variablennamen kommen in Prompts.

Gefährliche Formulierung	Sichere Alternative
„Alles lesen”	„Nur das [X]-Verzeichnis lesen”
„Automatisch wiederholen”	„Maximal 3 Mal wiederholen, dann stoppen”
„Mit Produktions-DB verbinden”	„Auf Entwicklungs-DB prüfen, ich führe es in Produktion aus”
„Alles löschen und aufräumen”	„Nur [X] löschen, Liste zuerst zeigen”
„Alles auf einmal ausführen”	„Zuerst Schritte bestätigen lassen, dann fortfahren”

Claude Code folgt nur Anweisungen—es hat keine böse Absicht. Die Gefahr liegt bei der Person, die vage Anweisungen gibt. Die Gewohnheit zu entwickeln, spezifische und klar abgegrenzte Anweisungen zu schreiben, ist der schnellste Weg zur Unfallverhütung.

Verwandte Artikel

• 7 echte Produktionsvorfälle mit Claude Code und vollständige Wiederherstellungsverfahren
• Der vollständige Leitfaden zur Claude Code Sicherheit
• Der vollständige Leitfaden zu Claude Code Berechtigungen

Referenzen

• Claude Code Offizieller Sicherheitsleitfaden
• OWASP LLM Application Security