Claude Code speichert Passwörter in Freigaben

Ihr bittet Claude Code, kurz in die Staging-Datenbank zu schauen. Claude schlägt einen Befehl vor, in dem das Passwort aus eurer Konfiguration steht, denn ohne geht es nicht. Ihr klickt "Yes, and don't ask again". Ab jetzt steht genau dieser Befehl, mit Passwort, als Freigaberegel in .claude/settings.local.json im Projektordner. Und von dort landet er häufig im Git-Repo.

Das Security-Unternehmen Apiiro hat am 07.11.2026 ausgewertet, wie oft das passiert. Ergebnis: 2.539 echte Secrets in 1.994 öffentlichen GitHub-Repos. Darunter Datenbankpasswörter, Supabase-Service-Keys, AWS-Keys, npm-Tokens und SSH-Root-Logins.

Was genau gespeichert wird

Die Freigaberegel ist der Befehl selbst, Zeichen für Zeichen. Wer also PGPASSWORD=geheim psql -h db.example.com ... dauerhaft erlaubt, hat das Passwort im Klartext in der Datei. Je länger jemand mit Claude Code arbeitet und Rückfragen wegklickt, desto mehr sammelt sich an. Laut Apiiro enthält jede zehnte Datei über 8 KB ein echtes Secret, bei Dateien unter 500 Byte ist es weniger als eine von 500.

Apiiro hat das Verhalten nach eigenen Angaben auch mit aktuellen Modellen wie Opus 5.5 und Fable 5.1 nachgestellt. Es liegt also nicht am Modell, sondern daran, wie Claude Code Freigaben speichert. Von 16 untersuchten Coding-Agenten sei Claude Code der einzige, der standardmäßig den vollständigen Befehl in eine Projektdatei schreibt.

Warum die Datei im Repo landet

Eigentlich soll settings.local.json lokal bleiben. Claude Code trägt sie beim Anlegen in die globale Git-Ignore-Liste des Rechners ein. Das deckt den Normalfall ab, aber nicht diese Fälle:

• Der Ordner wird erst später zu einem Git-Repo.
• Das Projekt wird auf einem anderen Rechner geklont, dort fehlt der globale Eintrag.
• Die Datei wurde schon einmal committet. Dann greift keine Ignore-Regel mehr, und jede neue Freigabe wird an die getrackte Datei angehängt, ohne Hinweis an euch.

In die .gitignore des Repos selbst schreibt Claude Code nichts. Dazu kommt: In 539 der betroffenen Repos hat ein Commit, den Claude mitverfasst hat, die Datei verändert. Claude Codes Commit-Anweisungen warnen vor .env und credentials.json, die eigene Settings-Datei steht nicht auf der Liste.

Die Zahlen

Löschen allein hilft also nicht. Was einmal committet war, steckt in der Historie, in jedem Fork und jedem Klon.

Unangenehm für alle, die sich auf Secret-Scanner verlassen: gitleaks und TruffleHog haben zusammen nur einen Teil gefunden, 215 der 1.122 Dateien hat keines der beiden Werkzeuge erkannt. Scanner suchen nach Schlüsselformaten mit Präfix und Zufallsstring. Ein Passwort hinter PGPASSWORD=, sshpass -p oder mysql -p sieht für sie aus wie ein gewöhnliches Wort.

Was Anthropic sagt

Boris Cherny, Head of Claude Code, hat am 07.11.2026 auf Hacker News reagiert. Claude Code habe Secrets bisher nicht selbst herausgefiltert, das Team prüfe aber, was es dagegen tun kann. Im Gespräch seien, den Auto-Mode solche Fälle abfangen zu lassen und einen einfachen Secret-Scan einzubauen. Erst wolle man Prototypen bauen. Einen Termin gibt es nicht.

Laut Apiiro gibt es Issues zu dem Verhalten seit August 2025, ohne Antwort von Anthropic. Ähnliche Funde hatten zuvor schon ironPeak und Lakera gemeldet, Lakera in npm-Paketen.

Was ihr jetzt tun solltet

Datei prüfen, auch wenn sie nie committet war. Öffnet .claude/settings.local.json in euren Projekten und schaut in die allow-Liste. Jeder Eintrag ist ein Befehl, den ihr freigegeben habt. Alles mit Passwort, Token, Key oder Connection-String rauslöschen. Die Datei liegt auch lokal im Klartext und ist für Schadsoftware ein leichtes Ziel.

Prüfen, ob sie im Repo ist oder war:

git ls-files .claude/
git log --all --oneline -- .claude/settings.local.json

Zeigt der erste Befehl die Datei, ist sie getrackt. Zeigt der zweite Commits, war sie es irgendwann.

Zuerst rotieren, dann aufräumen. Jedes Credential, das je in der Datei stand, ist als kompromittiert zu behandeln. Danach die Datei aus dem Repo nehmen und für alle sperren:

git rm --cached .claude/settings.local.json
echo ".claude/settings.local.json" >> .gitignore

Die Historie umzuschreiben ersetzt das Rotieren nicht, Forks und Klone haben die alte Fassung trotzdem.

Secrets nicht mehr in Befehle tippen. Verweist auf Umgebungsvariablen aus eurem Secret-Manager. Dann steht in der Regel $DB_URL und nicht das Passwort.

Muster statt Einzelbefehle freigeben. Eine Regel wie Bash(npm run:*) erlaubt eine ganze Befehlsfamilie, ohne dass ein konkreter Aufruf mit Argumenten gespeichert wird.

Auch die geteilte settings.json anschauen. Die committen Teams absichtlich, und auch dort fand Apiiro in 298 Dateien Secrets in Freigaberegeln.

Für Teams

Behandelt Agenten-Ordner wie .claude/, .cursor/, .gemini/ und .specstory/ sowie Memory- und Übergabedateien von Agenten wie .env: als Ort, an dem Secrets liegen können. Konkret heißt das:

• .claude/settings.local.json in die .gitignore-Vorlagen eurer Organisation aufnehmen.
• Die Ordner in Pre-Commit- und CI-Secret-Scans einbeziehen, mitsamt Historie.
• Prüfen, ob euer Scanner Passwörter in Befehlszeilen erkennt, nicht nur bekannte Key-Formate.
• Bei Funden zuerst die Credentials angehen, die auf öffentlich erreichbare Hosts zeigen.

Wie man Coding-Agenten im Team grundsätzlich so aufsetzt, dass solche Fehler weniger Schaden anrichten, steht in unserem Artikel Coding-Agenten im Team sicher betreiben. Warum der Auto-Mode, den Cherny empfiehlt, kein Allheilmittel ist, zeigt unsere Meldung 0,00 Prozent im Test, 80 Prozent im Angriff.

Diese Meldung wird ergänzt, sobald Anthropic eine Gegenmaßnahme ausliefert.