Claude Code: Secrets in Erlaubnisregeln finden und verhindern

Kurz gesagt: Wenn du in Claude Code einen Befehl mit „Yes, and don't ask again“ freigibst, speichert Claude Code eine Erlaubnisregel in der Datei .claude/settings.local.json. Stand im Befehl ein Passwort oder API-Schlüssel, steht er danach in dieser Datei. Laut einem Bericht des Sicherheitsunternehmens Apiiro lagen so Zugangsdaten in über tausend öffentlichen GitHub-Dateien. Anthropic hat am 12. November 2026 mit Claude Code 2.1.323 reagiert. Bereits geleakte Schlüssel musst du trotzdem selbst sperren. Die Prüfung dauert fünf Minuten, die Befehle stehen unten.

Was genau passiert?

Claude Code fragt vor vielen Aktionen nach, etwa bevor es einen Befehl im Terminal ausführt. Die Antwort „Yes, and don't ask again“ ist bequem: Claude Code merkt sich die Freigabe und fragt beim nächsten Mal nicht mehr. Laut offizieller Dokumentation speichert es dafür eine Erlaubnisregel (allow-Regel) in .claude/settings.local.json im Hauptverzeichnis des Git-Repositorys. Erkennt Claude Code ein Befehlspräfix, landet eine allgemeine Regel wie npm test * in der Datei. Sonst landet der freigegebene Befehl selbst darin.

Das Problem entsteht, wenn der Befehl ein Secret enthält, also ein Passwort, einen Token oder einen API-Schlüssel. Ein typisches Beispiel ist ein curl-Aufruf mit Schlüssel im Header oder ein Datenbankbefehl mit Passwort in der Verbindungszeile. Die Datei settings.local.json ist für persönliche Einstellungen gedacht und soll nicht ins Repository. Claude Code trägt sie beim ersten Schreiben in die globalen Ausschlüsse von Git ein, nicht in die .gitignore des Projekts. Wer die Datei von Hand anlegt, auf einem neuen Rechner arbeitet oder den Ordner erst später zum Git-Repository macht, kann sie trotzdem versehentlich versionieren und veröffentlichen.

Wer ist betroffen?

Betroffen sein kann jedes Team, das Claude Code nutzt und Repositorys auf GitHub, GitLab oder ähnlichen Plattformen teilt. Das Risiko ist am größten, wenn drei Dinge zusammenkommen: Jemand tippt Zugangsdaten direkt in Befehle, gibt sie mit „Yes, and don't ask again“ frei, und das Repository ist öffentlich oder wird mit Externen geteilt. Auch private Repositorys sind nicht automatisch sicher, denn jeder mit Lesezugriff sieht die Datei. Was das für dein Unternehmen heißt: Das ist kein exotisches Entwicklerproblem, sondern betrifft auch Teams ohne eigene IT, die Claude Code für Automationen und Auswertungen nutzen.

Die Prüfung in fünf Minuten

Führe diese drei Befehle im Hauptverzeichnis jedes Repositorys aus, in dem jemand Claude Code nutzt:

# 1. Ist die Datei aktuell versioniert?
git ls-files | grep settings.local.json

# 2. War sie früher einmal versioniert?
git log --all --oneline -- .claude/settings.local.json

# 3. Was steht lokal drin? Nach Schlüsseln und Passwörtern suchen
grep -n -i -E 'key|token|secret|passw|bearer' .claude/settings.local.json

Geben die ersten beiden Befehle nichts aus, war die Datei nie im Repository. Gibt einer von ihnen etwas aus, liegt die Datei in der Versionsgeschichte, und du prüfst sie mit dem dritten Befehl auf Zugangsdaten. Wichtig: Auch wenn die Datei heute nicht mehr versioniert ist, kann ein früherer Stand noch in der Geschichte liegen und von jedem mit Zugriff gelesen werden.

Sofortmaßnahmen bei einem Fund

1. Schlüssel sperren und neu erzeugen. Beim jeweiligen Anbieter, also etwa in der Claude Console, bei AWS oder beim Datenbankanbieter. Ein Schlüssel, der einmal in einem öffentlichen Repository stand, gilt als kompromittiert, auch wenn du ihn sofort löschst.
2. Datei aus der Versionierung nehmen. Mit git rm --cached .claude/settings.local.json und einem Eintrag in der .gitignore. Die lokale Datei bleibt erhalten.
3. Claude Code aktualisieren. Ab Version 2.1.323 speichert die Freigabe keine Regel mehr dauerhaft, die nach einem Secret aussieht oder in eine von Git verfolgte Datei ginge.
4. Gespeicherte Regeln aufräumen. Einträge mit Zugangsdaten aus der lokalen settings.local.json löschen.
5. Nutzung prüfen. In den Protokollen des Anbieters nachsehen, ob der Schlüssel in der Zwischenzeit von fremden Adressen genutzt wurde.

Die Versionsgeschichte zu bereinigen, ist aufwendig und ersetzt das Sperren nicht, weil Kopien eines öffentlichen Repositorys längst existieren können. Das Sperren hat deshalb immer Vorrang.

Dauerhafte Regeln für Teams

Damit das nicht wieder passiert, reichen fünf Regeln, die ihr einmal festlegt:

• settings.local.json in jede .gitignore. Nicht auf die globalen Ausschlüsse eines einzelnen Rechners verlassen. Die Zeile lautet .claude/settings.local.json.
• Secrets nie in Befehle tippen. Zugangsdaten gehören in Umgebungsvariablen oder einen Secret-Manager. Der Befehl verweist dann nur auf die Variable, etwa $API_KEY, und die Erlaubnisregel enthält keinen Wert.
• Deny-Regeln für sensible Dateien. In einer gemeinsamen .claude/settings.json sperrt ihr den Lesezugriff auf .env und Ordner mit Zugangsdaten. Deny-Regeln haben Vorrang, eine Erlaubnisregel kann sie nicht aufheben.
• Schreibschutz außerhalb des Projekts. Seit Version 2.1.314 verhindert die Einstellung permissions.blockWritesOutsideWorkingDirectories, dass Claude Code Dateien außerhalb der freigegebenen Arbeitsverzeichnisse schreibt.
• IP-Allowlist als zweite Sicherung. In der Claude Console legt ihr seit dem 5. November 2026 als Beta fest, von welchen IP-Adressen eure API-Schlüssel genutzt werden dürfen, bis zu 1.000 Einträge. Ein abgeflossener Schlüssel ist außerhalb eurer Netze dann wertlos.

So sieht der Kern einer gemeinsamen settings.json aus, in der Syntax der offiziellen Dokumentation:

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ]
  }
}

Die vollständigen Vorlagen mit Hook zum Dateischutz und einer .gitignore stehen im Claude-Code-Guide unter Vorlagen zum Download. Wer Freigaben grundsätzlich seltener erteilen will, kann den Auto Mode nutzen: Dabei prüft laut Dokumentation ein separates Modell jede Aktion vor der Ausführung, ausdrückliche Rückfrage-Regeln gelten weiter.

Wie hat Anthropic reagiert?

Eine eigene Stellungnahme von Anthropic zum Apiiro-Bericht habe ich in den offiziellen Quellen nicht gefunden. Die Reaktion steht im Changelog: Mit Claude Code 2.1.323 vom 12. November 2026 gilt eine Erlaubnisregel, die nach einem Secret aussieht oder in eine von Git verfolgte settings.local.json gespeichert würde, nur noch für die laufende Sitzung. Zugleich hat Anthropic behoben, dass die Datei nicht global ausgeschlossen wurde, wenn ein Ordner erst später zum Git-Repository wurde oder auf einem neuen Rechner lag. Seit derselben Version prüfen außerdem Claude-Chats und Cowork Plugin-Dateien vor dem Senden auf Secrets.

Meine Einordnung: Das Verhalten war dokumentiert, das Risiko entstand aus der Kombination von Bequemlichkeit und Secrets im Befehl. Die Korrektur ist schnell gekommen und sinnvoll. Sie ersetzt aber nicht die Regeln oben, denn kein Werkzeug erkennt jedes Secret zuverlässig.

Quellen und Stand der Recherche

Erstellt und gegen die Dokumentation von Anthropic geprüft am 13. November 2026.

• Claude Code, Berechtigungen: code.claude.com (abgerufen am 13.11.2026)
• Claude Code, Einstellungen: code.claude.com (abgerufen am 13.11.2026)
• Claude Code, Berechtigungsmodi und Auto Mode: code.claude.com (abgerufen am 13.11.2026)
• Claude Code, Changelog mit Version 2.1.323: code.claude.com (abgerufen am 13.11.2026)
• Anthropic, Release Notes der Plattform mit IP-Allowlist: platform.claude.com (abgerufen am 13.11.2026)
• Apiiro, Originalbericht: apiiro.com (am 13.11.2026 nicht abrufbar)
• VentureBeat, 9. November 2026: venturebeat.com (Sekundärquelle)
• RuntimeWire, 7. November 2026: runtimewire.com (Sekundärquelle)

Weiterführend: der Claude-Code-Guide, KI-Systeme: Zugriffe sinnvoll begrenzen und alle Neuerungen im KI-Änderungsprotokoll.

Häufige Fragen