Nicht mehr fragen? Dann bitte ohne Secret.
Eine dauerhafte Freigabe speichert eine Regel. Enthält der exakt freigegebene Befehl ein Secret, kann daraus eine weitere Kopie werden. Deshalb gehören auch lokale Einstellungen in die Prüfung.
Die Rückfrage endet, die Regel bleibt
Ein Befehl wurde geprüft, die Rückfrage ist beantwortet. Bei einer dauerhaften Freigabe entsteht daraus eine Einstellung für spätere Aufrufe. Für mich gehört deshalb zur Entscheidung auch die Frage, was genau gespeichert wird.
Laut Claude-Code-Dokumentation wird eine dauerhaft bestätigte Bash-Freigabe als allow-Regel in .claude/settings.local.json abgelegt. Die Berechtigungsdokumentation unterstützt Regeln, die einen exakten Befehl abgleichen. Enthält eine solche Regel einen wörtlichen geheimen Wert, enthält die gespeicherte Konfiguration damit auch diesen Wert. Das ist eine Folgerung aus dem dokumentierten Speicher- und Regelverhalten, keine Behauptung über jede Freigabe.
Local beschreibt den Geltungsbereich
Die Herstellerdokumentation unterscheidet persönliche Projekteinstellungen in .claude/settings.local.json von der gemeinsam genutzten .claude/settings.json. Erstere ist für lokale Abweichungen vorgesehen, letztere kann Einstellungen für das Team enthalten.
Ich würde die Bezeichnung „local“ deshalb als Hinweis auf den vorgesehenen Einsatz verstehen. Ob eine Datei tatsächlich geteilt wurde, ist eine eigene Prüfung: Liegt sie in einem Commit, einem Archiv oder einer anderen weitergegebenen Kopie? Der Dateiname beantwortet das nicht.
Git-Ausschluss und frühere Commits trennen
Claude Code ergänzt laut Dokumentation beim ersten eigenen Schreiben der lokalen Datei in einem Git-Repository einen passenden Eintrag in den globalen Git-Ausschlüssen, sofern sie noch nicht ignoriert wird. Wer die Datei selbst anlegt, soll sie gegebenenfalls selbst in .gitignore aufnehmen.
Für die Bearbeitung würde ich zwei Befunde getrennt festhalten: Wird die Datei heute ausgeschlossen, und war sie früher bereits versioniert? Zusätzlich würde ich prüfen, ob gespeicherte Regeln über andere Konfigurationsdateien oder Kopien weitergegeben wurden. Bei Funden reicht es, den betroffenen Zugang und seine Ablageorte zu dokumentieren; das Secret selbst gehört nicht in ein Ticket.
Zuerst den Zugang ungültig machen
GitHub empfiehlt bei offengelegten Zugangsdaten zuerst Widerruf oder Rotation. Die Entfernung aus der Repository-Historie ist eine gesonderte Entscheidung mit Nebenwirkungen und muss mit den Beteiligten koordiniert werden. Andere Klone und Forks können weiterhin Kopien enthalten.
Das würde ich als Reihenfolge für die eigene Bearbeitung übernehmen: betroffenen Zugang eingrenzen, seine Gültigkeit beenden und anschließend die Ablagen bereinigen. Welche weiteren Prüfungen nötig sind, hängt von Berechtigungen, möglicher Offenlegung und verfügbaren Nutzungsprotokollen ab. Ein gefundenes Secret belegt für sich allein noch keinen Missbrauch.
Freigaben ohne Klartext-Geheimnisse gestalten
GitHub empfiehlt, Geheimnisse nicht fest in Code einzubauen, sondern sie beispielsweise über Secret-Management-Dienste zur Laufzeit bereitzustellen. Auch geeignete Schutzmechanismen vor dem Commit und Push können versehentliche Veröffentlichungen begrenzen.
Für neue Freigaben würde ich den tatsächlich gespeicherten Regeltext ansehen und die Prüfung mit künstlichen Testwerten durchführen. Dabei auch kontrollieren, ob ein Wert in Ausgaben oder anderen Dateien auftaucht. Mein Ziel wäre eine nachvollziehbare Freigabe, deren Nutzen ohne eine zusätzliche dauerhafte Kopie des Zugangsschlüssels auskommt.