Claude Codes „Nicht mehr fragen“-Funktion Preisgabe von API-Schlüsseln auf GitHub: So prüfst und behebst du das Problem

Der Button „Don’t Ask Again“ (Nicht mehr fragen) in Claude Code speichert den genau freigegebenen Befehl als Allow-Regel in .claude/settings.local.json. Enthielt dieser Befehl ein Passwort oder einen API-Key, liegt das Geheimnis nun im Klartext in Ihrem Projektordner – und wird die Datei committet, ist es öffentlich. Das Sicherheitsunternehmen Apiiro fand 1.122 solcher Dateien auf öffentlichem GitHub mit 1.379 echten Geheimnissen. Hier erfahren Sie, wie Sie Ihre eigenen Repos mit einem Befehl prüfen, aufräumen und verhindern, dass es erneut passiert.

Was passiert ist: die Apiiro-Ergebnisse in Zahlen

Apiiro durchsuchte öffentliches GitHub nach Kopien der .claude/settings.local.json, der projektbezogenen Datei, in der Claude Code Ihre persönlichen Freigaben speichert. Dabei fanden sich 104.185 Kopien in 103.617 Repositories. In 1.122 davon lag mindestens ein echtes Geheimnis, insgesamt 1.379 verschiedene Geheimnisse, wie iTnews in seinem Bericht über die Untersuchung schreibt.

Art des Geheimnisses	Anzahl
Datenbank-Passwörter	379
Supabase-Service-Role-Keys	122
SSH-Logins für öffentliche Server	43
GitHub-, GitLab- und npm-Tokens	42
AWS-Keys	23

Als Apiiro die Suche auf ältere Git-Versionen der Datei, die gemeinsame .claude/settings.json und gespeicherte Agent-Transkripte ausdehnte, stieg die Zahl auf 2.539 Geheimnisse in 1.994 Repositories. Apiiro hat nicht getestet, ob die Zugangsdaten noch funktionieren, aber eine Organisation, die benachrichtigt wurde, bestätigte, dass ein Key aktiv war.

Die Scanner-Zahlen sollten Sie am meisten beunruhigen. Von den 1.122 Dateien mit einem echten Geheimnis fand TruffleHog 643 und gitleaks 564. 215 Dateien kamen an beiden vorbei. „Wir betreiben einen Secret-Scanner“ ist also kein Beweis dafür, dass Sie sauber sind.

Die Geschichte schaffte es an die Spitze von Hacker News mit 582 Punkten. Boris Cherny, der bei Anthropic Claude Code leitet, antwortete im Thread, dass Claude Code Geheimnisse bisher nicht entfernt habe und das Team sich damit beschäftige. Lesen Sie die ursprüngliche Apiiro-Recherche.

Wie „Don’t Ask Again“ Geheimnisse in eine Datei schreibt

Wenn Claude Code einen Bash-Befehl ausführen will, fragt es zuerst. Wählen Sie „Yes, and don’t ask again“, schreibt Claude Code eine dauerhafte Freigabe in die .claude/settings.local.json als allow-Regel, wie Anthropics Einstellungs-Dokumentation beschreibt. Die Regel speichert den Befehlstext. War der Befehl dieser:

psql "postgresql://admin:Sup3rS3cret@db.example.com:5432/prod" -c "select count(*) from users"

dann enthält Ihre Einstellungsdatei nun etwa Folgendes:

{
  "permissions": {
    "allow": [
      "Bash(psql \"postgresql://admin:Sup3rS3cret@db.example.com:5432/prod\" -c \"select count(*) from users\")"
    ]
  }
}

Das Passwort steht in der Regel, weil es im Befehl stand. Claude Code speichert, was Sie freigegeben haben, Wort für Wort.

Diagramm, wie eine Claude-Code-Freigabe mit Inline-Passwort in die settings.local.json und dann in ein öffentliches GitHub-Repository gelangt

Warum es auf GitHub landet

Claude Code versucht, diese Datei aus git herauszuhalten. Beim ersten Schreiben der .claude/settings.local.json in einem Repository, das sie noch nicht ignoriert, fügt es **/.claude/settings.local.json zu Ihrer globalen git-excludes-Datei hinzu. Dieser Schutz hat Lücken:

Sie haben die Datei von Hand erstellt. Die Dokumentation sagt klar: Wenn Sie die Datei selbst angelegt haben, müssen Sie sie selbst zu .gitignore hinzufügen. Chernys Einschätzung auf HN war, dass die offengelegten Kopien manuell erstellt und dann eingecheckt wurden.
Die Ignore-Regel existiert nur auf einem Rechner. Sie steht in Ihren globalen Excludes, nicht im .gitignore des Repos. Ein Teammitglied, ein CI-Job oder ein neuer Laptop, der den Ordner kopiert, erbt sie nicht.
Die Datei wurde erzwungen hinzugefügt oder war bereits getrackt, bevor die Regel existierte. git add -f überschreibt Ignore-Regeln, und einmal getrackte Dateien ignorieren Ignore-Regeln künftig.
Die gemeinsame Datei. In der VS-Code-Erweiterung können Sie im Freigabe-Dialog die Zieldatei wählen, einschließlich der committeten .claude/settings.json. Eine dort gespeicherte Regel gilt für alle.

Prüfen Sie Ihre Repos mit einem Befehl

Beginnen Sie mit dem aktuellen Repo. Dies zeigt, ob die Datei aktuell getrackt wird und ob sie jemals committet wurde:

git ls-files | grep -E '(^|/)\.claude/settings(\.local)?\.json$'
git log --all --name-only --format= | grep -E '\.claude/settings(\.local)?\.json$' | sort -u

Gibt die erste Zeile etwas aus, ist die Datei in Ihrem aktuellen Baum. Gibt die zweite etwas aus, ist sie in Ihrer Historie – selbst wenn Sie sie später gelöscht haben.

Um alle Repos unter einem Ordner auf einmal zu prüfen:

find ~/code -path '*/.claude/settings.local.json' -exec sh -c \
  'cd "$(dirname "$1")/.." && git ls-files --error-unmatch .claude/settings.local.json >/dev/null 2>&1 && echo "TRACKED: $PWD"' _ {} \;

Für eine GitHub-Organisation kann die GitHub CLI Code nach Dateinamen durchsuchen:

gh search code permissions --owner your-org --filename settings.local.json

Schauen Sie dann in jede gefundene Datei. Weil Scanner 19 % der offengelegten Dateien übersehen haben, lesen Sie die Regeln selbst, statt sich auf einen grünen Scan zu verlassen:

grep -nE 'Bash\(' .claude/settings.local.json | grep -iE 'pass|token|key|secret|://[^/]*:[^@]*@'

Ein Connection-String mit user:password@, ein Authorization: Bearer-Header, -p gefolgt von einem Klartext-Passwort oder alles, was mit sk-, ghp_, AKIA oder eyJ beginnt, ist ein Credential. Lassen Sie zur zweiten Prüfung – nicht als einzige Prüfung – gitleaks über das Repo laufen.

So beheben Sie eine offengelegte Einstellungsdatei

Die Reihenfolge ist wichtig. Das Rotieren kommt zuerst, denn das Löschen der Datei hilft nichts gegen die Kopie, die bereits in Forks, Clones und Caches existiert.

Rotieren Sie jedes Credential, das die Datei je enthalten hat. Prüfen Sie die vollständige Historie der Datei mit git log -p --all -- .claude/settings.local.json, listen Sie jedes Geheimnis auf und widerrufen Sie jedes bei seinem Anbieter. Apiiros Empfehlung setzt diesen Schritt an erste Stelle.
Entfernen Sie die Datei aus dem Tracking und ignorieren Sie sie im Repo selbst:

git rm --cached .claude/settings.local.json
echo '.claude/settings.local.json' >> .gitignore
git add .gitignore && git commit -m "Stop tracking Claude Code local settings"
git check-ignore -v .claude/settings.local.json

Der letzte Befehl sollte die passende .gitignore-Zeile ausgeben. Eine Regel im Repo schützt jeden Clone.

Bereinigen Sie die Historie, wenn das Repo öffentlich oder weit verbreitet ist. git-filter-repo entfernt die Datei aus jedem Commit:

git filter-repo --invert-paths --path .claude/settings.local.json
git push --force --all

Dadurch wird die Historie für alle umgeschrieben, warnen Sie also zuerst Ihr Team. Forks erreicht es nicht – es ist also Aufräumarbeit, kein Ersatz für Schritt 1.

Bereinigen Sie auch die lokale Datei. Öffnen Sie die .claude/settings.local.json, löschen Sie jede Regel mit einem Klartext-Geheimnis und ersetzen Sie sie durch ein Muster (nächster Abschnitt).
Aktivieren Sie Push-Protection. GitHub Secret Scanning Push Protection blockiert Pushes mit erkannten Secret-Formaten. Sie findet nicht alles, wie die 215 übersehenen Dateien zeigen, stoppt aber die gängigen Token-Formate.

Verhindern, dass es erneut passiert

Die Lösung lässt sich einfach sagen: Nie ein Klartext-Geheimnis in einen Befehl schreiben, den Ihr Agent ausführt, und stattdessen Muster statt exakter Befehle freigeben.

Direkter Vergleich einer riskanten Claude-Code-Allow-Regel mit Klartext-Passwort und einer sicheren Regel, die eine Umgebungsvariable referenziert

Referenzieren Sie Geheimnisse, tippen Sie sie nicht. Die Shell löst eine Variable zur Laufzeit auf, aber die Allow-Regel speichert den Text wie geschrieben. psql "$DATABASE_URL" speichert also $DATABASE_URL in der Regel, nicht das Passwort:

{
  "permissions": {
    "allow": ["Bash(psql \"$DATABASE_URL\" *)", "Bash(npm run test *)"],
    "deny": ["Read(./.env)", "Read(./.env.*)"]
  }
}

Die deny-Regeln stammen direkt aus Anthropics Einstellungs-Dokumentation; sie verhindern, dass Claude Code Ihre .env-Dateien liest, sodass ein Key auch nicht von dort in einen Befehl eingefügt werden kann.

Halten Sie Regeln eng. HN-Kommentatoren, die die Studie zitierten, berichteten, dass 5 % der Dateien beliebige Shell-Befehle erlaubten und 43 % Interpreter-Regeln wie Bash(python:*) enthielten. So eine Regel lässt den Agenten alles über Python ausführen – im Grunde eine Allow-Everything-Regel mit Umwegen.

Ziehen Sie den Auto-Modus und eine Sandbox in Betracht. Cherny empfahl den Auto-Modus statt handgeschriebener Berechtigungsregeln und erwähnte eine Open-Source-Sandbox von Anthropic. Mehrere Kommentatoren wiesen darauf hin, dass der Auto-Modus ein Klassifikator ist, keine Sicherheitsgrenze – kombinieren Sie ihn also mit den obigen Gewohnheiten.

Halten Sie Agenten von Produktions-Geheimnissen fern. Der sicherste Key ist einer, den der Agent nie sieht. Die Muster dafür haben wir in wie Sie KI-Agenten API-Keys nutzen lassen, ohne sie zu sehen behandelt, und was Angreifer mit offengelegten KI-Keys machen, in gestohlenen KI-API-Keys und LLMjacking.

Lassen Sie Ihren Coding-Agenten APIs aufrufen, ohne Keys einzutippen – mit Apidog CLI

Ein häufiger Weg, wie ein Key in einem freigegebenen Befehl landet, ist ein schneller API-Aufruf: curl -H "Authorization: Bearer sk-..." zum Testen eines Endpunkts. Diese Aufgabe können Sie stattdessen an die Apidog CLI übergeben. Der Key liegt in einer Apidog-Umgebungsvariable, Ihr Testszenario referenziert ihn als {{API_KEY}}, und der Befehl, den Ihr Agent ausführt, enthält nur Projekt-, Szenario- und Umgebungs-IDs. Es gibt darin kein Geheimnis, das gespeichert werden könnte.

Richten Sie es einmal ein – in Ihrem eigenen Terminal statt über den Agenten, damit Ihr Access-Token nie durch eine Freigabe läuft:

npm install -g apidog-cli@latest
apidog auth login
npx -y skills add https://apidog.com   # pick Claude Code when prompted

Geben Sie Claude Code dann einen Prompt:

List the environments in Apidog project 123456, then run test scenario 7890
against the staging environment and summarise any failed assertions.
The API key is stored in that environment as {{API_KEY}}. Never pass a key,
token or password on the command line, and never use --env-var for secrets.

Der Agent führt Befehle wie diese aus, die gefahrlos mit „Don’t Ask Again“ freigegeben werden können:

apidog environment list --project 123456
apidog run -t 7890 --project 123456 -e <envId> -r cli,json

Zwei ehrliche Einschränkungen. Erstens verwendet apidog run den gemeinsamen Wert der Variable, der mit Apidog synchronisiert und für Mitglieder des Projekts sichtbar ist – hinterlegen Sie dort also einen eingeschränkten Test-Key, keinen Produktions-Root-Key. Wenn Sie Werte lieber lokal halten möchten, akzeptiert apidog run auch --variables <path>; verweisen Sie auf eine Datei außerhalb des Repos. Zweitens existiert das Flag --env-var "key=value" zum Übergeben von Variablen auf der Kommandozeile – und genau dieses Muster führt zu Leaks. Sagen Sie Ihrem Agenten also, es nicht für Geheimnisse zu verwenden.

Teams im Enterprise-Plan können Geheimnisse zusätzlich aus HashiCorp Vault, Azure Key Vault oder AWS Secrets Manager mit Apidog Vault Secrets abrufen, und der Enterprise-SaaS-Secret-Scanner markiert Keys, die in Apidog-Requests, Scripts und Variablen gespeichert sind. Er scannt keine GitHub-Repos, behalten Sie also auch die obigen Prüfungen bei. Für eine vollständige Anleitung siehe wie Sie die Apidog CLI in Claude Code verwenden und Umgebungen und Secret-Variablen in Apidog verwalten. Apidogs Free-Plan deckt bis zu 4 Nutzer ab.

button

FAQ

Ist Claude Codes settings.local.json standardmäßig gitignored?

Teilweise. Wenn Claude Code die Datei in einem git-Repository erstellt, fügt es **/.claude/settings.local.json zu Ihren globalen git-excludes hinzu. Das schützt nur Ihren Rechner und gilt nicht, wenn Sie die Datei von Hand erstellt oder erzwungen hinzugefügt haben. Fügen Sie die Zeile zusätzlich zum eigenen .gitignore des Repos hinzu.

Entfernt das Löschen der Datei den offengelegten Key?

Nein. Der Key bleibt in der git-Historie, in Forks und in jedem Clone, der erstellt wurde, während er öffentlich war. Rotieren Sie zuerst den Key, dann entfernen Sie die Datei aus dem Tracking und bereinigen die Historie mit git-filter-repo.

Finden gitleaks oder TruffleHog diese Leaks?

Nicht zuverlässig. In Apiiros Stichprobe wurden 215 von 1.122 Dateien mit einem echten Geheimnis von beiden Tools übersehen. Führen Sie einen Scanner aus, und lesen Sie dann die Bash(...)-Regeln in der Datei selbst.

Ist das ein Modell-Problem oder ein Claude-Code-Problem?

Apiiro reproduzierte es mit Opus 5.5 und Fable 5.1 und bezeichnete es als Eigenschaft von Claude Code, nicht des Modells. Die Freigabe speichert den Befehlstext – egal welches Modell den Befehl geschrieben hat.

Wie gebe ich Befehle in Claude Code sicher frei?

Geben Sie Muster wie Bash(npm run test *) frei und referenzieren Sie Geheimnisse als Umgebungsvariablen wie $DATABASE_URL. Fügen Sie deny-Regeln für Read(./.env) und Read(./.env.*) hinzu.