Wer in Claude Code zum ersten Mal einen Shell-Befehl laufen lässt, bekommt vom Agenten eine Freigabefrage. Neben „Ja“ und „Nein“ steht dort auch „Yes, and don't ask again“ – praktisch für wiederkehrende Aufrufe. Nach Angaben der Sicherheitsfirma Apiiro landen genau diese Dauer-Freigaben seit Monaten zu Tausenden auf GitHub, und mit ihnen oft die eingetippten Passwörter, Tokens und Cloud-Schlüssel. In einer Untersuchung öffentlicher Repositories zählten die Forscher 2.539 verschiedene Geheimnisse in 1.994 Projekten.

Das Problem steckt in .claude/settings.local.json. Dort legt Claude Code jede „Don't ask again“-Zustimmung als Erlaubnisregel ab – nicht als abstrakter Werkzeug-Name, sondern als vollständiger Shell-Befehl inklusive aller Parameter. Wer also einmal psql 'postgresql://user:hunter2@db.example/prod' freigibt, friert damit auch das Passwort in der lokalen Konfiguration ein. Wird die Datei später zusammen mit dem restlichen Projekt committed und auf GitHub veröffentlicht, ist das Geheimnis öffentlich.

Wie Apiiro gesucht hat

Apiiro durchkämmte vom 1. bis 3. November 2026 insgesamt 104.185 öffentlich erreichbare Kopien von .claude/settings.local.json. In 1.122 dieser Dateien fanden die Analysten echte Zugangsdaten – verteilt über 1.994 Repositories von 63 Organisationen, überwiegend Softwarefirmen. Zum Einsatz kamen die Open-Source-Scanner Gitleaks und TruffleHog; Gitleaks schlug bei 564 Dateien an, TruffleHog bei 643. 215 der Fundstücke rutschten durch beide Filter und wurden manuell bestätigt.

Nach Angaben der Forscher waren unter den Funden 379 Datenbank-Passwörter, 122 Supabase-Service-Role-Keys und 43 SSH-Zugänge, teilweise mit Root-Passwort. Dazu kamen Cloud-Credentials, private Schlüssel, Package-Registry-Tokens, Square-Produktions-Tokens sowie laut Apiiro ein Azure-PostgreSQL-Passwort einer Produktionsumgebung und ein Passwort zu einer medizinischen Patientenakten-Datenbank. Häufige Muster sind Passwörter hinter PGPASSWORD=, hinter sshpass -p oder in Request-Headern für API-Aufrufe.

Symbolbild: Code-Editor mit geöffnetem Terminal

Bild: Symbolbild – VS Code Screenshot von Cycling2, Lizenz CC0, via Wikimedia Commons.

Warum .claude/settings.local.json so gefährlich ist

Die Datei trägt „local“ im Namen, und laut offizieller Dokumentation soll sie nicht geteilt werden. In der Praxis ignorieren aber viele Projekte den Ordner .claude/ nicht in ihrer .gitignore. Wer mit git add . arbeitet, zieht die Datei damit automatisch in jeden Commit. Für den Agenten ist der Shell-Befehl inklusive Passwort nur ein eindeutiger Fingerabdruck der Freigabe; für GitHub ist es ab dem Push ein öffentlicher Text.

Besonders tückisch: Auch wenn Entwickler die Datei nach einem Leak löschen und neu pushen, bleiben die Geheimnisse in der Git-Historie liegen. Angreifer, die die Repositories per API abschöpfen, sehen jede frühere Version. Nach Apiiros Daten funktionieren nicht alle gefundenen Zugangsdaten noch; eine Bestätigung der aktuellen Gültigkeit lehnten die Forscher aus rechtlichen Gründen ab. Die Auswertung fand nur in öffentlichen Repositories statt. Wie viele private Projekte betroffen sind, lässt sich von außen nicht sagen.

Was du jetzt tun solltest

Betroffene Projekte erkennst du schnell. Rufe im Projekt-Verzeichnis die komplette Historie der Datei auf:

git log --all --full-history --patch -- .claude/settings.local.json

Bekommst du Treffer mit PGPASSWORD=, -Authorization: Bearer, sshpass -p, AWS_SECRET_ACCESS_KEY oder ähnlichem, ist der Schaden bereits angerichtet. Rotiere in diesem Fall zuerst jedes gefundene Passwort und jeden Token, bevor du die Datei entfernst – eine simple Löschung macht alte Commits nicht ungeschehen. Danach nimmst du die Datei aus dem Repository, ohne sie lokal zu löschen:

git rm --cached .claude/settings.local.json
echo '.claude/settings.local.json' >> .gitignore
git commit -m 'Claude-Code: lokale Settings nicht mehr versionieren'

Für größere Code-Bestände lohnen sich die auch von Apiiro genutzten Scanner. Gitleaks und TruffleHog laufen offline, kennen gängige Secret-Muster und können als Pre-Commit-Hook jedes Hochladen verdächtiger Zeilen blockieren:

trufflehog git file://. --no-update
gitleaks detect --source . --no-git
gitleaks protect --staged

Zusätzlich empfiehlt sich, GitHubs eigenes Secret Scanning zu aktivieren – für öffentliche Repositories ist es gratis und meldet Treffer direkt an die Hersteller der jeweiligen Cloud-Dienste, damit sie die Schlüssel sperren können. Für private Repos und ganze Organisationen bietet GitHub Advanced Security einen ähnlichen Mechanismus samt Push-Protection, die das Veröffentlichen eines gefundenen Tokens blockiert, bevor der Commit die Serverseite überhaupt erreicht.

Die bessere Antwort heißt: nie als Argument

Die eigentliche Ursache liegt im Umgang mit Geheimnissen in Shell-Befehlen. Passwörter, Tokens und API-Keys haben als Klartext-Argument ohnehin nichts zu suchen – weder auf der Kommandozeile noch in Konfigurationsdateien. Besser sind Umgebungsvariablen aus einer Datei, die ausdrücklich außerhalb der Versionskontrolle liegt, oder ein Secret-Manager wie pass, 1Password CLI, HashiCorp Vault beziehungsweise die Secret-Dienste der Cloud-Anbieter. Claude Code darf dann auf den Referenznamen zugreifen, nicht auf den Wert:

export PGPASSWORD="$(pass show prod/db)"
psql -h db.example -U appuser

Damit landet im Freigabe-Prompt und später in settings.local.json nur noch der harmlose Aufruf, nicht das Geheimnis. Wer auf Agenten-Werkzeuge wie Claude Code setzt, sollte die „Yes, and don't ask again“-Option außerdem bewusst nur dort nutzen, wo der Befehl wirklich wiederholt läuft und keine sensiblen Werte enthält. Für alles andere ist der zusätzliche Dialog kein Ärgernis, sondern die letzte Sicherheitsschleife.

Quellen

Bildnachweis