Wyciek haseł z Claude Code przez „Yes, and don’t ask again”

5 listopada badacze Apiiro, Shmulik Cohen i Matan Giladi, opublikowali raport o wycieku haseł z Claude Code na GitHuba. W 104 185 publicznych kopiach pliku .claude/settings.local.json znaleźli 1122 pliki z co najmniej jednym sekretem, czyli łącznie 1379 różnych haseł, kluczy API i tokenów.

Na czym polega wyciek haseł z Claude Code?

Gdy Claude Code pyta o zgodę na komendę w terminalu, możemy wybrać „Yes, and don’t ask again”. Według dokumentacji Claude Code ta zgoda trafia jako reguła allow do pliku .claude/settings.local.json w projekcie.

Problem w tym, że reguła zapisuje całą zatwierdzoną komendę, razem z tym, co w niej wpisaliśmy. Jeśli komenda miała hasło w treści, na przykład PGPASSWORD=… psql … albo curl z kluczem API w nagłówku, to hasło ląduje w pliku jawnym tekstem.

Co ciekawe, to nie jest nowe odkrycie. W sierpniu 2025 roku ktoś zgłosił dokładnie ten problem w zgłoszeniu #5544 (z przykładami kluczy API i tokenów Jiry). Bot zamknął je 3 stycznia 2026 roku po 60 dniach bez aktywności, ze statusem „not planned”, bez poprawki.

Skoro plik jest lokalny, jak trafił na GitHuba?

Plik z założenia jest prywatny. Claude Code przy pierwszym zapisie dodaje **/.claude/settings.local.json do globalnego pliku wykluczeń gita, żeby nie trafił do commitów (tak opisuje to dokumentacja).

Ta ochrona ma jednak kilka dziur:

1. Globalne wykluczenie działa tylko na jednym komputerze i nie podróżuje razem z repozytorium.
2. Jeśli plik utworzyliśmy ręcznie, Claude Code go nie wyklucza i musimy dopisać go do .gitignore sami.
3. Reguły ignorowania nie działają na pliki, które git już śledzi, więc raz scommitowany plik dalej trafia do kolejnych commitów.
4. Usunięcie pliku z repozytorium nie usuwa go z historii ani z forków.

Według iTWire w 539 z 1105 prześledzonych repozytoriów plik zmieniały commity, których współautorem był Claude.

Jak duża jest skala?

Liczby z raportu (dane zebrane z publicznego GitHuba 1–3 listopada):

1. 104 185 publicznych kopii settings.local.json, z czego 1122 (około 1,1%) zawierały co najmniej jeden sekret.
2. W tych plikach było 1379 różnych wartości.
3. Po doliczeniu historii gita, współdzielonego pliku .claude/settings.json i zapisanych rozmów z agentem wychodzi 2539 sekretów w 1994 repozytoriach.
4. Apiiro powiadomiło firmy 2 i 3 listopada, a jedna z nich potwierdziła, że ujawniony klucz był aktywny.

Jedno zastrzeżenie: Apiiro nie sprawdzało, czy znalezione dane logowania działają. Kandydatów odsiało filtrami fałszywych alarmów i oceną modelu językowego, więc część z nich mogła już być nieaktualna.

Dlaczego jest o tym głośno?

Raport trafił w sobotni wieczór na pierwszą stronę Hacker News. Opcja „don’t ask again” służy do tego, żeby agent nie pytał co chwilę o to samo, więc łatwo zapomnieć, co właściwie zostało zapisane.

To też kolejny przykład tego, że sekrety wyciekają dziś nie tylko z kodu aplikacji, ale też z plików konfiguracyjnych agentów (podobnie jak przy wycieku z OpenCode). Na razie w relacjach mediów nie ma odpowiedzi Anthropic.

Na co zwrócić uwagę na przyszłość?

1. Najpierw unieważnijmy i wymieńmy każde hasło lub klucz, który kiedykolwiek był w tym pliku w publicznym repozytorium. Dopiero potem sprzątajmy historię.
2. Sprawdźmy, czy plik jest śledzony: git ls-files .claude. Jeśli jest, przestańmy go śledzić (git rm --cached .claude/settings.local.json) i dopiszmy go do .gitignore w samym repozytorium, a nie tylko globalnie.
3. Przejrzyjmy też historię (git log --all -- .claude/settings.local.json), współdzielony .claude/settings.json i zapisane rozmowy z agentem.
4. Nie wpisujmy haseł wprost w komendy. Lepiej przekazywać je przez zmienne środowiskowe lub menedżer sekretów, a w regułach allow używać wzorców, takich jak Bash(npm run test *) z dokumentacji.

Więcej o tym, jak trzymać klucze API z dala od agentów, piszę w poradniku Bezpieczeństwo agentów AI, a podstawy pracy z narzędziem są w poradniku Claude Code.

FAQ

Czy Claude Code sam wysyła moje hasła na GitHuba?

Nie. Plik settings.local.json zostaje na naszym dysku. Wyciek następuje dopiero wtedy, gdy plik trafi do commita i do publicznego repozytorium.

Jak sprawdzić, czy mój plik settings.local.json jest w repozytorium?

Wystarczy git ls-files .claude w katalogu projektu. Jeśli na liście jest settings.local.json, git go śledzi. Warto też zajrzeć do samego pliku i poszukać w regułach allow haseł, tokenów i kluczy.

Czy wystarczy usunąć plik z repozytorium?

Nie. Plik zostaje w historii gita i w forkach, dlatego najważniejsze jest unieważnienie i wymiana ujawnionych danych logowania.