GitLab warnt: Claude-Code-Einstellungsdatei kann Geheimnisse offenlegen
GitLab hat einen Leitfaden veröffentlicht, um Geheimnisse aufzuspüren und zu entfernen, die über die Datei .claude/settings.local.json von Claude Code offengelegt werden könnten. Das Unternehmen erklärt, dass die Datei in Repositories eingecheckt werden kann, weil ihr Ausschluss nur in der lokalen Git-Konfiguration eines Entwicklers gespeichert wird.
- Claude Code speichert genehmigte Befehle in .claude/settings.local.json.
- GitLab zufolge enthielten 1.122 von 104.185 öffentlichen Kopien mindestens ein Geheimnis.
- Die Aufnahme der Datei in .gitignore verhindert künftig ein versehentliches Tracking in Commits.
- Push-Regeln und Secret Push Protection können riskante Pushs ablehnen.
- Die Repository-Historie muss auf Dateien geprüft werden, die später gelöscht wurden.
Wie die Datei Zugangsdaten offenlegen kann
Claude Code, der Programmieragent von Anthropic, ermöglicht es Entwicklern, einen Shell-Befehl durch die Auswahl von „Ja, und nicht noch einmal fragen“ zu genehmigen. Der Agent speichert diesen exakten Befehl anschließend in .claude/settings.local.json und führt ihn künftig ohne Rückfrage aus.
GitLab zufolge wird auch das Zugangsmittel in der Datei gespeichert, wenn der Befehl ein Passwort oder Token enthält. Claude Code hält die Datei über die persönlichen globalen Ausschlussregeln des Entwicklers von Git fern, nicht über die .gitignore-Datei des Repositorys. Dieser Schutz gilt nur auf einem Laptop und wird nicht zusammen mit dem Repository übertragen. Dadurch kann die Datei eingecheckt und veröffentlicht werden.
GitLab erklärt, dass die eigenen Infrastrukturgeheimnisse geschützt sind. Anfang November 2026 berichtete Apiiro, dass das Problem dazu geführt hatte, dass 104.185 Kopien der Datei in öffentlichen Repositories auftauchten, darunter 1.122 mit mindestens einem Geheimnis. GitLab zufolge befanden sich außerdem Hunderte weitere Geheimnisse ausschließlich in der Repository-Historie, in Dateien, die inzwischen gelöscht worden waren.
GitLabs empfohlene Schutzmaßnahmen
GitLab empfiehlt, .claude/settings.local.json in die .gitignore-Datei jedes Repositorys aufzunehmen. Kunden mit Premium und Ultimate können dieselbe Zeile in das Projekt für Dateivorlagen ihrer Gruppe aufnehmen, sodass später erstellte Projekte diese Einstellung übernehmen.
Kunden mit Premium und Ultimate können außerdem eine Push-Regel für die Gruppe verwenden, um den Dateinamen überall dort abzulehnen, wo er in einem Repository auftaucht. GitLab stellt dafür das Muster (^|/)\.claude/settings\.local\.json$ bereit. Die Regel lehnt neue Dateien ab, blockiert jedoch keine Änderungen an einer bereits getrackten Datei. Vorhandene Kopien müssen daher zunächst bereinigt werden. Gruppenregeln werden in später erstellte Projekte kopiert und gelten nicht automatisch für bestehende Projekte.
Kunden mit Ultimate können den Secret Push Protection aktivieren. Dieser prüft den Inhalt jedes Pushs und lehnt erkannte Token-Formate unabhängig vom Dateinamen ab. GitLab empfiehlt außerdem eine Ausführungsrichtlinie für Gruppenscans, die Secret Detection in jedem Projekt ausführt, auch in Projekten ohne .gitlab-ci.yml-Datei. Ein historischer Scan kann die Repository-Historie prüfen, wenn die Variable SECRET_DETECTION_HISTORIC_SCAN: 'true' verwendet wird.
Aktuelle und gelöschte Kopien finden
Nachdem die Schutzmaßnahmen eingerichtet wurden, empfiehlt GitLab zu prüfen, ob die Datei derzeit vorhanden war oder in der Vergangenheit vorhanden ist. Gruppen mit GitLab Duo können den GitLab Duo Agentic Chat auffordern, Projekte und Untergruppen einschließlich Branches und Commit-Historie zu untersuchen. Laut GitLab kann die daraus entstehende Tabelle zeigen, ob eine Datei noch vorhanden ist, wann sie hinzugefügt oder entfernt wurde und ob eine gelöschte Version ein Geheimnis enthielt.
Kunden mit Premium und Ultimate ohne GitLab Duo können die Codesuche verwenden, auch in archivierten Projekten. GitLab weist darauf hin, dass die Codesuche im Allgemeinen den Standard-Branch in seinem aktuellen Zustand anzeigt. Eine gelöschte Datei oder eine Datei, die nur in einem anderen Branch gespeichert ist, wird daher nicht sichtbar. Um frühere Offenlegungen zu erkennen, muss deshalb die Commit-Historie geprüft werden.
Für Nutzer bietet der Leitfaden eine Möglichkeit, versehentliche Commits zu verhindern und sowohl aktuelle als auch historische Leaks zu untersuchen. Für Gruppen kombinieren die GitLab-Kontrollen die Blockierung von Dateinamen, die Erkennung von Tokens und geplante Repository-Scans. Welche Optionen verfügbar sind, hängt vom GitLab-Abonnement und der Art der Bereitstellung ab.
