Dek: Ein Bestätigungsknopf in Claude Code speichert ganze Shell-Befehle samt Zugangsdaten in einer Konfigurationsdatei. Apiiro hat nachgezählt, wie viele dieser Dateien öffentlich auf GitHub liegen und was darin steht.
Was der Knopf „Yes, and don't ask again" in Claude Code ablegt
Claude Code fragt nach, bevor der Agent einen Shell-Befehl ausführt, und wer oft mit demselben Werkzeug arbeitet, kennt die dritte Option im Dialog: „Yes, and don't ask again". Ein Klick, und die Rückfrage verschwindet für ähnliche Befehle.
Bequem ist das, und teuer. Der Agent schreibt den freigegebenen Befehl als Allowlist-Regel in .claude/settings.local.json, damit er beim nächsten Lauf nicht wieder fragen muss. Enthält dieser Befehl ein Passwort, wird das Passwort mitgespeichert. Nicht als Platzhalter, nicht gehasht, sondern als Zeichenkette neben dem Kommando, das es benutzt.
Apiiro hat diesen Mechanismus am 5. November 2026 in einem Blogbeitrag beschrieben und die Folgen gemessen. Der Punkt ist nicht, dass eine Datei entsteht. Der Punkt ist, was in ihr steht und wohin sie wandert, sobald jemand das Projekt kopiert, spiegelt oder als Fork weiterreicht.
Wie Apiiro Claude Code in 103.617 Repositories geprüft hat
Die Analyse ist eine Inventur, keine Warnung auf Verdacht. Apiiro durchsuchte 104.185 öffentlich erreichbare Kopien von .claude/settings.local.json aus 103.617 Repositories. In 1.122 dieser Dateien fanden sich 1.379 verschiedene Secrets.
Dann weitete das Team den Blick. Zusammen mit geteilten Einstellungsdateien, Agent-Transkripten und der Git-Historie kamen 2.539 verschiedene Secrets in 1.994 öffentlichen Repositories zusammen, verteilt über 63 Organisationen. Diese zweite Zahl beschreibt Secrets, nicht Dateien. Wer sie als Dateizahl liest, liegt um den Faktor zwei daneben.
Für Sicherheitsteams ist der Unterschied wichtig, weil er den Aufwand bestimmt. Eine vergessene Datei lässt sich löschen. Zweitausend einzelne Passwörter und Keys lassen sich nicht wegdiskutieren, sondern nur austauschen, und zwar in jedem System, das sie akzeptiert.
Auffällig ist, dass die Datei überhaupt entsteht, ohne dass jemand sie bewusst anlegt. Sie ist ein Nebenprodukt einer Zustimmung, die sich auf einen einzelnen Befehl bezog und danach als generelle Regel weiterlebt.
Was in den 1.122 settings.local.json-Dateien steckt
Die Mischung erklärt, warum das Muster so teuer ist. Auf die 1.122 Dateien entfallen 636 Keys im Format eines Anbieters und 743 Passwörter oder Tokens, die zu öffentlich adressierbaren Hosts gehören.
Darunter sind 379 Datenbank-Passwörter, 122 Supabase-Service-Role-Keys und 103 Supabase-Konto-Tokens. Dazu kommen 43 SSH-Zugangsdaten, einige davon für root-Logins innerhalb von sshpass-Aufrufen, 23 AWS-Keys und sechs private Schlüssel.
Apiiro hat die Funde nicht ausprobiert und die betroffenen Hosts nicht kontaktiert. „Echtes Secret" heißt in diesem Bericht also: glaubwürdiges Zugangsmaterial, nicht verifizierter funktionierender Login.
Eine Organisation hat laut Bericht bestätigt, dass ein offengelegter Schlüssel aktiv war. Nur eine. Diese eine Bestätigung ist der Grund, warum der Bericht nicht als theoretisches Risiko abgehakt werden sollte, und gleichzeitig der Grund, warum er keine Panik auslösen muss: Der Anteil tatsächlich nutzbarer Zugänge ist unbekannt.
Warum Git-Ignore bei Claude Code credentials nicht reicht
Claude Code trägt die Datei in die globale Git-Ignore-Liste des Entwicklers ein, wenn sie innerhalb eines Repositories angelegt wird. In dieser Umgebung greift der Schutz also. Er reist nur nicht mit.
Kopiert jemand das Projektverzeichnis, klont er es auf einen anderen Rechner oder spiegelt er es in eine zweite Instanz, ist die Ausnahme nicht mehr dabei, und niemand merkt es, weil die Datei lokal weiterhin unsichtbar bleibt. Bei selbst betriebenen GitLab-Instanzen, wie sie in vielen Unternehmen laufen, passiert genau das: Das Projekt wird gespiegelt, die Ignore-Regel bleibt zurück.
Die Historie verschärft den Effekt. Ältere Versionen der Dateien enthielten 734 Secrets, die in den aktuellen Kopien nicht mehr auftauchen, aber weiterhin in Commits stehen. Forks trugen Zugangsdaten aus 74 Repositories in 211 weitere Kopien, ohne dass dort jemand den Befehl je ausgeführt hätte.
Warum Gitleaks den Claude Code secrets leak teils übersieht
Die üblichen Scanner greifen einen Teil ab, nicht alles. Gitleaks markierte 564 der Dateien mit Secrets, TruffleHog 643. Bei 215 Dateien schlug keiner der beiden an.
Der Grund ist banal und schwer zu beheben. Passwörter, die als PGPASSWORD=, sshpass -p oder mysql -p im Befehl stehen, haben kein Anbieterpräfix. Die Scanner suchen nach Mustern wie AKIA oder sk-. Ein Datenbankpasswort in einem Kommando sieht dagegen aus wie ein gewöhnliches Argument.
Wer sich auf den Scanner verlässt, prüft also zuerst die Form und erst danach den Inhalt. Für Claude Code credentials bedeutet das: Die Regel im Repo muss den Dateipfad abdecken, nicht nur bekannte Key-Formate, und sie muss auch dann greifen, wenn die Datei in einem Unterverzeichnis eines Monorepos liegt.
Was Teams diese Woche mit Claude Code credentials tun sollten
Die Reihenfolge ist keine Geschmacksfrage. Zuerst rotieren, dann aufräumen. Wer die Datei löscht und den Schlüssel weiterleben lässt, hat nur die Beweislage verschlechtert.
Danach folgt das Entfernen aus dem Index, nicht nur aus dem Arbeitsverzeichnis, denn eine repository-lokale Ignore-Regel hält den Pfad dauerhaft draußen, auch nach dem nächsten Klonen. Anschließend lohnt der Blick in alte Commits, in geteilte Einstellungsdateien und in die Transkripte des Agenten, weil dort dieselben Befehle noch einmal stehen können.
Am Ende steht der Umbau: keine Literale mehr im Befehl, sondern Umgebungsvariablen, die aus einem Secret Manager kommen. Das ist mehr Arbeit als ein Klick auf „nicht mehr fragen", und es ist die einzige Variante, die auch nach dem nächsten Klon noch hält.
Für Teams in der EU kommt die Meldekette dazu. Ein Repository mit Datenbank-Zugangsdaten ist ein Datenvorfall, und die DSGVO verlangt eine Meldung binnen 72 Stunden, sobald personenbezogene Daten betroffen sein können. Ob das der Fall ist, lässt sich nur prüfen, wenn die Datei bekannt ist.
Was der Fall für jede Agent-CLI wie Claude Code bedeutet
Der Fehler steckt nicht in einer Zeile Code, die man patchen könnte. Er steckt in der Produktentscheidung, eine dauerhafte Erlaubnis an genau der Stelle zu speichern, an der der Befehl ausgeführt wird.
Andere Agenten mit Freigabelogik stehen vor derselben Wahl, und die Diskussion um sie hat gerade erst begonnen. Es gibt keine CVE-Nummer für diesen Fall, kein Update, das ihn schließt.
Bleibt eine Frage, die jedes Team für sich beantworten muss: Was darf ein Assistent speichern, wenn er „nicht mehr fragen" verspricht? Die Antwort entscheidet darüber, ob Bequemlichkeit ein UI-Detail bleibt oder zur Credential-Ablage wird.
