Claude Code Secrets auf GitHub: So schützt du deine API-Keys

Claude Code kann Passwörter und API-Keys in die Datei .claude/settings.local.json schreiben, und genau diese Datei landet manchmal in öffentlichen GitHub-Repositories. Das haben Sicherheitsforscher von Apiiro herausgefunden, wie Ars Technica berichtet. Wenn du Claude Code nutzt, solltest du heute zwei Dinge tun: prüfen, ob die Datei in deinen Repos liegt, und verhindern, dass sie dort je hinkommt. Diese Anleitung zeigt, wie.

Was ist bei Claude Code passiert?

Auslöser ist die Freigabe von Shell-Befehlen. Wenn Claude Code einen Befehl ausführen will und du „Yes, and don’t ask again” wählst, speichert das Tool diese Entscheidung als Regel in der lokalen Datei .claude/settings.local.json. Manchmal ist die Regel ein Muster. Oft steht aber der komplette Befehl drin, und damit alles, was darin eingebettet war: ein Datenbankpasswort in einer Connection-String, ein Token als Parameter, ein Root-Login.

Lokal ist das ein überschaubares Risiko. Laut Anthropics Dokumentation wird die Datei in die globale .gitignore des Entwicklers eingetragen. Diese Regel gilt aber nur auf deinem Rechner und steckt nicht im Repository. Wird ein Repo auf einer anderen Maschine geklont oder ein Ordner erst später zum Repo, greift der Schutz nicht. Apiiro schreibt zudem, dass Claude Code Änderungen an der Datei in vielen Fällen selbst committet, ohne dass der Nutzer etwas tut.

Die Zahlen aus dem Bericht:

• Über 100.000 öffentliche Repositories enthielten die lokale Settings-Datei.
• Rund 1.100 Dateien aus 63 Organisationen enthielten tatsächlich Secrets wie API-Tokens, Datenbankpasswörter oder private Schlüssel.
• Selbst nach dem Löschen können die Secrets in Forks weiterleben.

Neu ist das Problem nicht. Ein Bug-Report dazu stammt laut Ars Technica schon von August 2025. Weitere Reports meldeten, dass die Datei teils gar nicht in der .gitignore landete oder dass sensible Befehle in einer anderen, ungeschützten Datei auftauchten. Alle wurden nach 60 Tagen Inaktivität ohne Maßnahme geschlossen.

Bist du betroffen? So prüfst du deine Repositories

Du brauchst dafür nur Git und Zugriff auf deine Repos. Es dauert pro Projekt wenige Minuten.

Voraussetzungen: Git auf der Kommandozeile, Schreibrechte auf den Repos, bei Organisationen idealerweise Admin-Rechte auf GitHub.

Zuerst schaust du, ob die Datei aktuell versioniert ist:

git ls-files | grep -i "settings.local.json"

Dann prüfst du die Historie, denn ein früherer Commit reicht schon:

git log --all -p -- .claude/settings.local.json

Findest du dort Einträge mit Passwörtern, Tokens oder Schlüsseln, behandle sie als kompromittiert. Das gilt besonders, wenn das Repo öffentlich ist oder war. Prüfe außerdem, ob es Forks gibt.

Claude Code Secrets auf GitHub verhindern: Schritt für Schritt

1. Betroffene Secrets zuerst rotieren. Bevor du irgendetwas aus dem Repo löschst, tausche Passwörter, Tokens und Schlüssel aus und widerrufe die alten. Löschen allein hilft nicht, weil Kopien in Forks und Klonen bleiben können. Rotieren macht das alte Secret wertlos.

2. Die Datei aus der Versionskontrolle nehmen. Entferne sie aus dem Index, ohne sie lokal zu löschen:

git rm --cached .claude/settings.local.json

3. Eine Ignore-Regel im Repo selbst setzen. Trag .claude/settings.local.json in die .gitignore des Projekts ein und committe sie. Die globale Regel auf deinem Rechner schützt Kolleginnen, Klone und CI-Maschinen nicht. Die Regel im Repo reist dagegen mit.

4. Die Datei auf Secrets durchsehen. Öffne die lokale Settings-Datei und lösche Regeln, in denen Zugangsdaten stehen. Das Auto-Cleanup nimmt dir Claude Code nicht ab.

5. Secrets gar nicht erst in Befehle schreiben. Das ist die eigentliche Ursache. Arbeite mit Umgebungsvariablen, einer .env-Datei außerhalb der Versionskontrolle oder einem Secret-Manager. Im Befehl steht dann nur der Variablenname, nicht der Wert. Gib Claude Code keine Befehle, in denen ein Klartext-Passwort steht, und tipp sie auch selbst nicht so ein.

6. Secret-Scanner einrichten, aber nicht darauf verlassen. Boris Cherny vom Claude-Code-Team empfiehlt Secret-Scanner und erwägt, so etwas künftig direkt einzubauen. Richte gitleaks oder TruffleHog als Pre-Commit-Hook und in der CI ein. Aktiviere zusätzlich die Secret-Scanning-Funktion von GitHub samt Push-Schutz, sofern dein Plan sie anbietet. Der wichtige Haken: Apiiro stellte fest, dass 215 der rund 1.100 öffentlichen Secrets von gitleaks und TruffleHog nicht erkannt wurden. Mehrere Schichten sind deshalb Pflicht.

7. Eine harte Regel für den Ordner .claude/ ergänzen. Ein Pre-Commit-Check, der jeden Commit ablehnt, der Dateien aus .claude/settings.local.json enthält, fängt den Fall ab, den Scanner verfehlen. Das ist keine Funktion von Claude Code, sondern normale Git-Praxis.

8. Commits des Agenten prüfen. Wenn Claude Code selbst committet, kontrolliere vor dem Push den Diff. Ein Blick auf die Dateiliste genügt oft: Taucht dort etwas aus .claude/ auf, stoppst du. Wer es ganz sicher will, lässt den Agenten nur lokal committen und pusht selbst.

9. Historie bereinigen, falls nötig. Waren Secrets im Verlauf, entfernst du die Datei mit einem Werkzeug wie git filter-repo oder BFG Repo-Cleaner aus allen Commits und pusht neu. Informiere alle, die geforkt oder geklont haben. Das ersetzt Schritt 1 nicht, sondern ergänzt ihn.

Ich: Ich nutze Claude Code jede Woche und lasse Agenten viel Arbeit übernehmen, bewerte und entscheide aber selbst. Bei einer Freigabe mit „don’t ask again” würde ich deshalb genau hinsehen. Da ich täglich mit Oracle- und SQL-Server-Abfragen arbeite, ist ein Datenbankzugang in einem Befehl für mich das naheliegendste Beispiel dafür, was dort landen kann.

Was ist mit dem Auto-Modus?

Cherny nennt als Zwischenlösung Claudes Auto-Modus. Er nutzt Klassifizierer, die Routine-Rückfragen selbst beantworten, sodass du keine „fummeligen Allow-/Deny-Listen” pflegen musst. Das reduziert die Zahl der Freigaben und damit der gespeicherten Regeln.

Ein vollständiger Schutz ist es nicht. Auf den Einwand eines Nutzers, dass auch im Auto-Modus sensible Befehle in den Settings-Dateien landen können, antwortete Cherny, das sei ein „guter Fang”. Das Team überlege, wie es das verbessern kann. Wir lesen das als Eingeständnis, dass der Auto-Modus das Problem abmildert, aber nicht löst.

Welche Fehler passieren am häufigsten?

• Nur löschen statt rotieren. Ein entferntes Secret bleibt in der Git-Historie und in Forks erreichbar.
• Auf die globale .gitignore vertrauen. Sie gilt nur auf der Maschine, auf der du sie eingerichtet hast.
• Einem einzigen Scanner glauben. Rund jedes fünfte Secret in Apiiros Stichprobe blieb bei zwei gängigen Tools unentdeckt.
• Die Datei manuell anlegen und mitcommitten. Cherny sagt, solche Fälle kämen vor allem vor, wenn Dateien von Hand erstellt und eingecheckt wurden. Apiiro berichtet dagegen auch von automatischen Commits durch Claude Code. Beide Darstellungen widersprechen sich teilweise, also ist Vorsicht in beiden Fällen sinnvoll.
• Neue Repos aus bestehenden Ordnern anlegen. Wird ein Arbeitsordner später mit git init zum Repo, liegt die Settings-Datei schon darin, ohne dass die Ignore-Regel greift.

Was bedeutet das für Teams im DACH-Raum?

Ein öffentlich gewordenes Datenbankpasswort ist nicht nur ein Entwicklerproblem. Führt der Zugang zu Datenbanken mit personenbezogenen Daten, kann ein Leak eine Datenschutzverletzung im Sinne der DSGVO sein. Dann laufen enge Meldefristen gegenüber der Aufsichtsbehörde. Ob eine Meldepflicht besteht, bewertet dein Datenschutzbeauftragter, nicht dieser Artikel.

Für kleine Firmen und Agenturen ohne eigenes Security-Team liegt der Nutzen im Pragmatischen. Eine Zeile in der .gitignore, ein Pre-Commit-Hook und eine klare Regel („keine Passwörter in Befehlen”) kosten kaum Zeit. Besonders gefährdet sind Freelancer, die Kundenzugänge direkt im Terminal nutzen und Repos öffentlich spiegeln.

Was ist noch offen?

Anthropic hat bislang nur angekündigt, nach Lösungen zu suchen. Ob die Datei künftig automatisch im Repo ignoriert wird oder ob ein eingebauter Scanner kommt, ist nicht bestätigt. Auch wie viele der gefundenen Secrets noch gültig sind, geht aus dem Bericht nicht hervor.

Dein nächster Schritt: Nimm dir heute deine aktiven Projekte vor, führe die beiden Prüfbefehle aus und setze die Ignore-Regel ins Repo. Und beobachte die Release Notes von Claude Code, ob das Team die Handhabung der Settings-Dateien ändert.