Standardmäßig fragt Claude Code vor der Ausführung der meisten Shell-Befehle nach. Wählt der Nutzer „Yes, and don't ask again“, speichert der KI-Coding-Assistent von Anthropic laut seiner Berechtigungsdokumentation eine Allow-Regel in .claude/settings.local.json im Projekt, und passende Befehle laufen in späteren Sitzungen ohne Nachfrage. The Hacker News zufolge kann Anthropics KI-Coding-Assistent dabei den Befehl wortwörtlich einschließlich des Geheimnisses in einer Projekt-Einstellungsdatei speichern.
Die Regel deckt nur ab, was die Eingabeaufforderung anbot – manchmal ein Muster wie npm test *, manchmal einen exakten Befehl. Bei einem exakten Befehl wird jedes darin eingegebene Passwort oder Token im Klartext mitgespeichert, berichtet The Hacker News.
The Hacker News zufolge öffnet mehr als ein Drittel der gefundenen Geheimnisse direkt eine Datenbank – darunter 379 Datenbank-Passwörter. Hinzu kommen 43 SSH-Logins für öffentliche Server, 42 Tokens für GitHub, GitLab und npm sowie 23 AWS-Schlüssel. Zu den Eigentümern der Dateien zählen 63 Organisationen, überwiegend Softwareunternehmen aller Größen. Die Forscher nennen als schwerwiegendste Fälle den Admin-Cloud-Schlüssel eines Datenbankanbieters und das Eigentümer-Passwort einer Datenbank für medizinische Aufzeichnungen.
In den öffentlichen Dateien stießen die Forscher auf gespeicherte Befehle, in denen das Geheimnis noch enthalten war.
Dass ausgerechnet ein Datenbankanbieter seinen eigenen Admin-Schlüssel offenlegt, zeigt, wie wenig die Datei als sensibel gilt. Das Eigentümer-Passwort einer Datenbank für medizinische Aufzeichnungen in öffentlichen Repositories lässt erahnen, was auf dem Spiel steht.
Wer die Datei .claude/settings.local.json aus seinem Projekt entfernt, macht das Leck damit nicht rückgängig. The Hacker News zufolge bleiben ältere Versionen in der Git-Historie und in Forks des Repositories erhalten. Löschen ist deshalb Kosmetik.
Auch die lokale Ausnahme in den Git-Einstellungen schützt nur den eigenen Rechner. Claude Code fügt die Datei nie der .gitignore des Projekts hinzu, sodass der Schutz nicht mit dem Projekt wandert. Für eine bereits committete Datei bewirkt dieser Ausschluss nichts.
Die Forscher fanden in älteren Versionen der Datei 734 weitere Geheimnisse in 509 Repositories, die in keiner aktuellen Kopie mehr vorhanden sind, meist weil die Datei gelöscht wurde. Forks verbreiten die Dateien weiter: 211 Forks von 74 Repositories tragen dieselben Geheimnisse wie die Originale. Wer eine Datei mit Geheimnissen einmal committet hat, sollte sie als dauerhaft öffentlich behandeln.
Was also tun? Die Forscher raten zuerst zum Rotieren: jedes Passwort, jeden Token und jeden Schlüssel ändern, den die Datei jemals enthalten hat, und erst danach aufräumen. Die Reihenfolge ist kein Detail – wer zuerst löscht, hat den alten Schlüssel vielleicht schon aus den Augen verloren, während er anderswo noch gültig ist. Entwickler sollen laut The Hacker News ihre GitHub-Organisation nach .claude/settings.local.json und .claude/settings.json durchsuchen und jedes Repository in der Git-Historie darauf prüfen, auch wenn die Dateien verschwunden sind.
Für Sicherheitsteams empfehlen die Forscher, Agent-Ordner wie .claude/, .cursor/, .gemini/ und .specstory/ sowie Agent-Memory-Dateien auf Laptops wie in Repositories als geheimnishaltig zu behandeln – so wie .env-Dateien.
Damit es gar nicht so weit kommt, sollen Geheimnisse aus Befehlen herausbleiben und als Variablen aus einem Secrets-Manager wie $DB_URL referenziert werden, damit die gespeicherte Regel nur den Variablennamen enthält. Statt einzelner Befehle empfehlen die Forscher Muster wie Bash(npm run:*), die den Spielraum der Genehmigung breiter, aber den Inhalt harmloser machen.