Bericht: Laut Apiiro legte Claude Codes „Don't ask again" Passwörter in 1.122 öffentlichen GitHub-Dateien offen. Prüfen Sie .claude/settings.local.json

Urteil: Wenn jemand in Ihrem Team je auf „Yes, and don't ask again" (Ja, und nicht mehr fragen) bei einem Befehl mit Passwort, Token oder Schlüssel geklickt hat, gehen Sie davon aus, dass dieses Credential in .claude/settings.local.json liegt, und prüfen Sie, ob die Datei es in Git geschafft hat. Apiiros Zahl ist berichtet, und wir konnten den Post nicht lesen, aber der Mechanismus steht in Anthropics eigener Doku: „Yes, and don't ask again" speichert die Zustimmung als allow-Regel in .claude/settings.local.json, und Claude Code hält diese Datei nur über Ihre globalen Git-Excludes aus Commits heraus. Claude Code bleibt in unserem Verzeichnis Bedingt: Das ist ein Konfigurationsrisiko, das Sie heute schließen können, kein Grund, das Tool fallen zu lassen.

Was passiert ist

Das Sicherheitsunternehmen Apiiro hat eine Untersuchung zu der Berechtigungsdatei veröffentlicht, die Claude Code schreibt. Sie erreichte Hacker News am 7. November als „Claude Code's ‚Don't Ask Again‘ exposes passwords in 1,122 public GitHub files". Apiiros Website verweigerte unsere Anfragen (HTTP 403). Wir konnten daher weder die Methode noch die übrigen Zahlen prüfen, auch nicht, was Apiiro als Secret zählte. Anthropics Einstellungsdoku bestätigt den Mechanismus: Wenn Sie für einen Bash-Befehl „Yes, and don't ask again" wählen, speichert Claude Code diese Zustimmung als allow-Regel in .claude/settings.local.json. Enthielt der genehmigte Befehl ein Passwort oder Token, liegt das Secret in dieser Regel.

Warum die Datei in Git landet

Beim ersten Schreiben der Datei fügt Claude Code **/.claude/settings.local.json zu Ihrer globalen Git-Excludes-Datei hinzu, nicht zum .gitignore des Repositorys. Eine globale Excludes-Datei lebt auf einer einzelnen Maschine. Das Repository selbst trägt also keine Regel, die die Datei fernhält, und laut Doku müssen Sie die Datei selbst zu .gitignore hinzufügen, wenn Sie sie von Hand anlegen. Verlassen Sie sich nicht auf einen Secret-Scanner als letzte Absicherung: Ein Passwort innerhalb eines Befehlsstrings entspricht möglicherweise nicht den Schlüsselformaten, nach denen Scanner suchen.

Was Anthropic gesagt hat

Boris Cherny, der Claude Code leitet, antwortete am 7. November im Hacker-News-Thread: „Historisch hat Claude Code keine Secret-Bereinigung gemacht (dafür gibt es viele gute Tools), aber wir prüfen, was wir tun können, um das zu verhindern." Im selben Kommentar schrieb er, die Datei „soll lokal bleiben", und dass Claude Code sie beim Erstellen automatisch in die .gitignore einträgt, „sodass in diesem Fall die Dateien manuell erstellt und eingecheckt wurden". Er riet Nutzern außerdem, in den Auto-Modus zu wechseln und Secret-Scanning bei ihrem Git-Host zu aktivieren. Weder der Eintrag zu 2.1.319 (6. November) noch der zu 2.1.321 (9. November) geht darauf ein. 2.1.321 behebt einen anderen Secrets-Fehler (MCP-OAuth-Anfragen, die bei einem Redirect Refresh-Tokens an einen anderen Host sendeten), der nicht dieses Problem ist. Behandeln Sie das Verhalten als aktuell.

Was sich für Sie ändert

FAQ

Ist mein Secret offengelegt, wenn die Datei meine Maschine nie verlassen hat? Nicht über GitHub. Der Offenlegungspfad ist das Committen und Pushen der Datei. Prüfen Sie also vor allem anderen Git-Status und Verlauf.

Fängt ein Secret-Scanner das ab? Nicht zuverlässig. Ein Passwort in einem genehmigten Befehl entspricht möglicherweise nicht den Formaten, nach denen Scanner suchen. Durchsuchen Sie die Datei direkt.

Hat Anthropic einen Fix geliefert? Stand des Releases 2.1.321 vom 9. November: nein. Boris Cherny sagte, das Team beschäftige sich damit, „was wir tun können, um das zu verhindern".