Jeśli w Claude Code zatwierdziłeś polecenie z hasłem albo kluczem API opcją “Yes, and don’t ask again”, sekret mógł zostać zapisany otwartym tekstem w pliku .claude/settings.local.json projektu. Sprawdź treść zapisanej reguły i to, czy plik nie trafił do repozytorium. Firma Apiiro, która sprzedaje narzędzia do bezpieczeństwa aplikacji, policzyła na publicznym GitHubie 1 122 kopie tego pliku z sekretami. Narzędzie Anthropic chroni plik przed commitem tylko regułą w globalnych ustawieniach gita na komputerze programisty. Zgłoszenie opisujące ten problem zamknął w styczniu automat GitHuba, bez poprawki. Stan na 7 listopada 2026 roku, godz. 9:30, według dokumentacji Claude Code, zgłoszenia #5544 na GitHubie i relacji iTWire z badania Apiiro.
Co zapisuje “Yes, and don’t ask again”
Opcja “Yes, and don’t ask again” przy poleceniu w terminalu zapisuje regułę allow w pliku .claude/settings.local.json, a reguła może zawierać całe polecenie razem z hasłem. Tak działa narzędzie według dokumentacji ustawień: to plik na osobiste ustawienia jednej osoby w jednym projekcie. Dzięki regule agent nie pyta drugi raz o to samo polecenie.
Hasło trafia do pliku wtedy, gdy jest częścią polecenia. Przykład: łączenie z bazą z hasłem w zmiennej ustawionej w tej samej linii albo curl z tokenem w nagłówku. Zgłoszenie #5544 z 11 sierpnia 2025 roku opisuje to wprost: zatwierdzone polecenia z kluczami API i tokenami są zapisywane w pliku dosłownie, bez maskowania. Automat GitHuba zamknął zgłoszenie 3 stycznia 2026 roku ze statusem “not planned”. W liście zmian najnowszej wersji 2.1.319 z 6 listopada nie ma wzmianki o maskowaniu sekretów w tym pliku.
Dlaczego plik może trafić do repozytorium
Plik trafia do repozytorium, gdy ochrona przed commitem nie działa w konkretnym projekcie. Gdy agent tworzy plik po raz pierwszy w repozytorium, dopisuje regułę **/.claude/settings.local.json do globalnego pliku wykluczeń gita. To plik ustawiony w core.excludesFile albo ~/.config/git/ignore. Reguła działa we wszystkich repozytoriach, ale tylko na tym jednym komputerze. Nie ma jej w .gitignore projektu, więc nie przechodzi na komputer kolegi ani na serwer.
Ochrona nie zadziała w trzech sytuacjach:
- plik utworzono ręcznie, agent jeszcze do niego nie zapisał i żadna reguła go nie ignoruje (dokumentacja każe wtedy samemu dopisać go do
.gitignore), - plik jest już śledzony przez gita, bo ktoś go wcześniej dodał,
- ktoś pracuje nad repozytorium na komputerze, na którym globalnej reguły nie ma.
Sprawdziliśmy drugi przypadek w testowym repozytorium (git 2.47, 7 listopada 2026). Po dopisaniu pliku do .gitignore git nadal go śledził, a git check-ignore niczego nie zgłaszał. Według dokumentacji gita reguły ignorowania nie dotyczą plików, które już są w repozytorium.
Co policzyło Apiiro
Raportu Apiiro nie przeczytaliśmy, bo strona firmy blokuje automatyczne pobieranie. Liczby podajemy za relacją iTWire z 7 listopada. Badanie opublikowali 5 listopada Shmulik Cohen i Matan Giladi.
| Co | Liczba według Apiiro |
|---|---|
Publiczne kopie .claude/settings.local.json na GitHubie | 104 185 |
| Kopie z co najmniej jednym sekretem | 1 122 (ok. 1,1%) |
| Różne sekrety w tych plikach | 1 379 |
Sekrety łącznie z historią gita, settings.json i zapisami rozmów agenta | 2 539 w 1 994 repozytoriach |
| Repozytoria z commitami współtworzonymi przez Claude, które zmieniały plik | 539 z 1 105 prześledzonych |
Dane z GitHuba zebrane 1–3 listopada 2026 roku, za iTWire, odczyt 7.11.2026.
Apiiro nie sprawdzało, czy sekrety działają. Rozpoznawało je po formacie i kontekście, a kandydatów oceniał dodatkowo model językowy. Firmy powiadomiono 2 i 3 listopada, jedna potwierdziła, że jej klucz był aktywny. Nie wiadomo, czy ktoś te sekrety wykorzystał. iTWire zaznacza też, że commity współtworzone przez Claude nie dowodzą, że to agent wypchnął każdy sekret.
Jak sprawdzić swoje repozytoria
Sprawdzenie zajmuje kilka minut na repozytorium. Polecenia uruchamiaj w katalogu głównym repozytorium. Wzorzec '*settings.local.json' łapie też pliki w podkatalogach, na przykład backend/.claude/. Wszystkie polecenia uruchomiliśmy w testowym repozytorium z fałszywym hasłem (git 2.47, 7 listopada 2026).
- Zobacz, czy plik jest śledzony:
git ls-files '*settings.local.json'. Każda wypisana ścieżka to plik, który jest w repozytorium. - Sprawdź historię:
git log --all --oneline -- '*settings.local.json'. Każdy wiersz to commit, który zmieniał taki plik. Pusty wynik dotyczy tylko historii dostępnej w twojej kopii repozytorium. Nie wyklucza, że plik był kiedyś opublikowany w usuniętej gałęzi albo w forku. - Przejrzyj treść z historii:
git log --all -p -- '*settings.local.json'. Szukaj haseł, tokenów i adresów baz w regułachallow. - Sprawdź, co ignoruje plik:
git check-ignore -v .claude/settings.local.json. Wynik pokazuje plik i regułę. Brak wyniku znaczy, że plik nie jest ignorowany albo jest już śledzony. - Otwórz lokalny plik
.claude/settings.local.jsoni przejrzyj reguły, nawet jeśli nigdy go nie commitowałeś.
Ten sam przegląd warto zrobić dla .claude/settings.json, który zespoły commitują celowo. W Windows plik lokalny może leżeć obok .claude/settings.json w katalogu, z którego uruchomiono sesję, a nie w katalogu głównym repozytorium.
Co zrobić, gdy hasło trafiło na GitHuba
Najpierw zmień albo unieważnij sekret, dopiero potem sprzątaj repozytorium. Tak każe instrukcja GitHuba: po rotacji stary sekret nie daje dostępu, a czyszczenie historii może już nie być potrzebne.
- Zmień hasło do bazy, wygeneruj nowy klucz API albo token i unieważnij stary. Sprawdź w logach usługi, czy ktoś go używał.
- Usuń z lokalnego pliku reguły z sekretami. Reguły można też przejrzeć poleceniem
/permissionsw sesji agenta. - Przestań śledzić plik:
git rm --cached .claude/settings.local.json(albo ścieżka z podkatalogu), dopisz**/.claude/settings.local.jsondo.gitignoreprojektu i zrób commit. W naszym teście plik został na dysku, a git przestał go śledzić. - Pamiętaj, że commit nie usuwa sekretu z historii, forków ani cudzych klonów. W teście stare hasło nadal było widoczne w
git log. Przepisanie historii narzędziemgit-filter-repoopisuje instrukcja GitHuba. Wymaga uzgodnienia z każdym, kto ma kopię repozytorium.
Jak tego uniknąć
Trzymaj hasła poza poleceniami, które zatwierdzasz na stałe. Hasło ustawione w zmiennej środowiskowej przed sesją albo w menedżerze sekretów nie trafi do reguły, bo w poleceniu jest tylko nazwa zmiennej. iTWire zwraca uwagę, że przypisanie hasła do zmiennej w tej samej linii polecenia nadal zapisuje je w regule.
Dopisz **/.claude/settings.local.json do .gitignore w każdym repozytorium zespołu, nie licząc na globalną regułę na komputerze jednej osoby. Przed wyborem “Yes, and don’t ask again” przeczytaj, jaką regułę zapisze opcja. Według dokumentacji uprawnień zapisana reguła obejmuje tylko to, co nazywa opcja w oknie zgody. Szersze zasady pracy z uprawnieniami agenta opisaliśmy przy poleceniu rm -rf, a podstawy gita w poradniku dla początkujących.
To druga w tym tygodniu sprawa z danymi w tym narzędziu. Wcześniej opisaliśmy, jak Claude Code wysyłał adres e-mail w nagłówku User-Agent. Mechanizmy są różne i nie mają ze sobą związku.
{ dla firm }Co możemy zrobić dla Twojej firmy?
Budujemy strony, sklepy i aplikacje, łączymy systemy z KSeF i księgowością, wdrażamy automatyzacje i agentów AI, a na koniec dbamy o widoczność w Google. Zaczynamy od rozmowy o tym, co dziś zabiera Twojemu zespołowi najwięcej czasu.
Podsumowanie
Opcja “Yes, and don’t ask again” zapisuje regułę dla zatwierdzonego polecenia w .claude/settings.local.json. Jeśli reguła objęła hasło albo klucz, plik ma je otwartym tekstem. Ochrona przed commitem to reguła w globalnym pliku wykluczeń gita na komputerze programisty. Nie chroni pliku już śledzonego ani repozytorium na komputerze bez tej reguły. Apiiro policzyło na publicznym GitHubie 1 122 kopie z sekretami, ale nie sprawdzało, czy działają. Zgłoszenie z sierpnia 2025 roku zamknął automat bez poprawki. Sprawdź dziś git ls-files '*settings.local.json' i historię pliku w swoich repozytoriach. Sekret, który wyciekł, najpierw zmień, potem usuń plik z repozytorium i dopisz **/.claude/settings.local.json do .gitignore projektu. Stan na 7 listopada 2026 roku, godz. 9:30.
