Claude Code Datenleck: Passwörter durch „Yes, and don’t ask again“

Am 5. November haben die Apiiro-Forscher Shmulik Cohen und Matan Giladi einen Bericht veröffentlicht über ein Claude Code Datenleck, bei dem Passwörter auf GitHub gelandet sind. In 104.185 öffentlichen Kopien der Datei .claude/settings.local.json fanden sie 1.122 Dateien mit mindestens einem Secret, insgesamt 1.379 verschiedene Passwörter, API-Schlüssel und Tokens.

Wie funktioniert das Datenleck in Claude Code?

Wenn Claude Code um Erlaubnis für einen Terminalbefehl bittet, können wir „Yes, and don’t ask again“ wählen. Laut der Claude-Code-Dokumentation landet diese Freigabe als allow-Regel in der Datei .claude/settings.local.json im Projekt.

Das Problem: Die Regel speichert den kompletten freigegebenen Befehl, samt allem, was wir hineingeschrieben haben. Stand im Befehl ein Passwort, etwa PGPASSWORD=… psql … oder ein curl mit API-Schlüssel im Header, steht dieses Passwort im Klartext in der Datei.

Interessant ist, dass das keine neue Entdeckung ist. Im August 2025 hat jemand genau dieses Problem in Issue #5544 gemeldet (mit Beispielen für API-Schlüssel und Jira-Tokens). Ein Bot hat es am 3. Januar 2026 nach 60 Tagen ohne Aktivität als „not planned“ geschlossen, ohne Fix.

Wenn die Datei lokal ist, wie kam sie auf GitHub?

Die Datei ist eigentlich privat. Beim ersten Schreiben trägt Claude Code **/.claude/settings.local.json in die globale Ausschlussdatei von Git ein, damit sie nicht in Commits landet (so beschreibt es die Dokumentation).

Dieser Schutz hat aber ein paar Lücken:

1. Der globale Ausschluss gilt nur auf einem Rechner und wandert nicht mit dem Repository mit.
2. Haben wir die Datei von Hand angelegt, schließt Claude Code sie nicht aus, und wir müssen sie selbst in die .gitignore eintragen.
3. Ignore-Regeln greifen nicht bei Dateien, die Git bereits trackt, also landet eine einmal committete Datei auch in allen weiteren Commits.
4. Wer die Datei aus dem Repository löscht, entfernt sie damit nicht aus der Historie oder aus Forks.

Laut iTWire wurde die Datei in 539 von 1.105 untersuchten Repositorys durch Commits geändert, an denen Claude als Co-Autor beteiligt war.

Wie groß ist das Ausmaß?

Die Zahlen aus dem Bericht (Daten vom öffentlichen GitHub, gesammelt vom 1. bis 3. November):

1. 104.185 öffentliche Kopien von settings.local.json, davon enthielten 1.122 (etwa 1,1 %) mindestens ein Secret.
2. In diesen Dateien standen 1.379 verschiedene Werte.
3. Rechnet man die Git-Historie, die gemeinsam genutzte .claude/settings.json und gespeicherte Agenten-Gespräche dazu, kommt man auf 2.539 Secrets in 1.994 Repositorys.
4. Apiiro hat die Firmen am 2. und 3. November informiert, und eine davon hat bestätigt, dass der offengelegte Schlüssel aktiv war.

Eine Einschränkung: Apiiro hat nicht geprüft, ob die gefundenen Zugangsdaten funktionieren. Die Kandidaten wurden mit Filtern gegen Fehlalarme und einer Bewertung durch ein Sprachmodell aussortiert, ein Teil davon war also womöglich schon veraltet.

Warum ist das gerade so ein Thema?

Der Bericht landete am Samstagabend auf der Startseite von Hacker News. „Don’t ask again“ soll verhindern, dass der Agent ständig dasselbe fragt, und genau deshalb vergisst man leicht, was eigentlich gespeichert wurde.

Es ist auch ein weiteres Beispiel dafür, dass Secrets heute nicht nur aus Anwendungscode leaken, sondern auch aus Konfigurationsdateien von Agenten (ähnlich wie beim Datenleck bei OpenCode). Eine Antwort von Anthropic gibt es in den Medienberichten bisher nicht.

Worauf sollten wir künftig achten?

1. Zuerst widerrufen und ersetzen wir jedes Passwort und jeden Schlüssel, der jemals in dieser Datei in einem öffentlichen Repository stand. Erst danach räumen wir die Historie auf.
2. Prüfen wir, ob die Datei getrackt wird: git ls-files .claude. Wenn ja, hören wir auf, sie zu tracken (git rm --cached .claude/settings.local.json), und tragen sie in die .gitignore im Repository selbst ein, nicht nur global.
3. Sehen wir uns auch die Historie an (git log --all -- .claude/settings.local.json), dazu die gemeinsame .claude/settings.json und gespeicherte Agenten-Gespräche.
4. Keine Passwörter direkt in Befehle schreiben. Besser übergeben wir sie über Umgebungsvariablen oder einen Secrets-Manager und nutzen in allow-Regeln Muster wie Bash(npm run test *) aus der Dokumentation.

Mehr dazu, wie man API-Schlüssel von Agenten fernhält, steht in meinem Leitfaden zur Sicherheit von KI-Agenten, und die Grundlagen des Tools in der Claude-Code-Anleitung.

FAQ

Schickt Claude Code meine Passwörter selbst an GitHub?

Nein. Die Datei settings.local.json bleibt auf unserer Festplatte. Zum Leak kommt es erst, wenn die Datei in einem Commit und in einem öffentlichen Repository landet.

Wie prüfe ich, ob meine settings.local.json im Repository ist?

Es reicht git ls-files .claude im Projektverzeichnis. Steht settings.local.json in der Liste, trackt Git die Datei. Es lohnt sich auch, die Datei selbst zu öffnen und in den allow-Regeln nach Passwörtern, Tokens und Schlüsseln zu suchen.

Reicht es, die Datei aus dem Repository zu löschen?

Nein. Die Datei bleibt in der Git-Historie und in Forks, deshalb ist das Wichtigste, die offengelegten Zugangsdaten zu widerrufen und auszutauschen.