# Claude Code 2.1.268: co naprawiono w regułach deny i MCP > Claude Code 2.1.268–2.1.269 naprawiły cztery problemy z uprawnieniami oraz wyciek sekretów w /mcp. Dowiedz się, kogo dotyczyły problemy, jak zaktualizować program i sprawdzić reguły. Source: https://ailoot.ai/blog/pl/claude-code-2-1-268-fixes/ Canonical: https://ailoot.ai/blog/pl/claude-code-2-1-268-fixes/ Language: pl Publisher: Ailoot (https://ailoot.ai/) Translation: guide-040 Revision: sha256-4c894fc17952feea7d16e6a1c50ef5e3ff36ffa7b89b88defc5aac506cb59740 Claude Code w wersji 2.1.268 został wydany 10 września 2026 r., a następnego dnia pojawiła się wersja 2.1.269. Zaktualizuj program jak najszybciej: w dwóch przypadkach reguły deny, których używasz do blokowania agentowi dostępu do `.env` i katalogów usług, po cichu nie działały. Ponadto polecenie `/mcp` mogło wyświetlać sekrety z konfiguracji w terminalu. Wszystkie poniższe informacje opierają się na oficjalnym dzienniku zmian i dokumentacji Anthropic w stanie na 17 września 2026 r., czyli datę materiału źródłowego. Najnowszą wersją tego dnia była 2.1.274. Opisujemy działanie błędów na podstawie tych wpisów; obejść nie odtworzono na podatnej wersji. Dodatkowe wskazówki dotyczące korzystania z Ailoot znajdziesz w [dokumentacji](https://ailoot.ai/docs/). ## Co naprawiono w Claude Code 2.1.268 i 2.1.269?
Najważniejsze informacje w tej sekcji Naprawiono cztery problemy z uprawnieniami. Reguły deny i ask nie działały w przypadku ścieżek prowadzących przez dowiązania symboliczne, a reguła deny dotycząca Read lub Edit mogła zawodzić w wierszach zawierających `env -C` lub `eval`. Reguła z „!” działała poza plikiem ustawień, w którym ją zapisano. Polecenie `tee` zapisywało pliki bez blokady wynikającej z reguły deny dla Edit. Ponadto `/mcp` i `claude mcp list` wyświetlały sekrety z konfiguracji, a błędy wtyczek pokazywały tokeny z adresów URL Git.
Cztery poprawki dotyczą reguł uprawnień: 1. **Odmowy dotyczące dowiązań symbolicznych nie działały.** Reguły deny i ask zapisane dla katalogów będących dowiązaniami symbolicznymi (`/etc`, `/tmp`, `/var` w systemie macOS, `/bin` w systemie Linux) nie uruchamiały się, gdy ścieżkę podano jako rzeczywistą lokalizację. Polecenia Bash również ignorowały reguły deny zapisane dla ścieżki prowadzącej przez dowiązanie symboliczne. 2. **Odmowa odczytu i edycji zawodziła w połączeniu z `env -C` lub `eval`.** Jeśli ten sam wiersz polecenia zawierał konstrukcję, której kontrola uprawnień nie potrafiła przeanalizować, reguła deny dotycząca Read lub Edit mogła się nie uruchomić. 3. **Reguła z „!” działała szerzej, niż zamierzono.** Reguła deny lub ask zaczynająca się od `!` działała poza plikiem ustawień, w którym ją zapisano. Teraz działa wyłącznie w obrębie własnego źródła, a samodzielny operator negacji `!` jest ignorowany. 4. **`tee` omijało odmowy podczas zapisu.** Reguły deny dla `Edit()` oraz kontrola ścieżki zapisu nie były stosowane do pliku utworzonego poleceniem Bash `tee`. Uprawnienie `Bash(tee:*)` nie obejmuje już zapisów poza katalogami roboczymi. W tych wersjach naprawiono także dwa problemy związane z ujawnianiem sekretów. WebFetch nie czeka już bez końca na odpowiedź serwera, który utrzymuje otwarte połączenie: żądanie kończy się niepowodzeniem po 300 sekundach, a limit czasu można skonfigurować za pomocą zmiennej `CLAUDE_CODE_WEBFETCH_DEADLINE_MS`. Usunięto również problem stale wysokiego użycia procesora w długo trwających, bezczynnych sesjach. ## Jak działają odmowy w Claude Code?
Najważniejsze informacje w tej sekcji Reguły zapisuje się w bloku `permissions` pliku `settings.json`: deny blokuje, ask prosi o potwierdzenie, a allow zezwala na działanie bez potwierdzenia. Kontrole są wykonywane w kolejności: deny, ask, allow. Reguła ma postać `Tool` lub `Tool(detail)`, na przykład `Read(./.env)`.
Claude Code ma trzy listy reguł: **deny** (zawsze zabronione), **ask** (przed wykonaniem działania poproś o potwierdzenie) i **allow** (dozwolone bez potwierdzenia). Gdy agent zamierza coś zrobić, reguły są sprawdzane ściśle w tej kolejności. Pasująca reguła deny unieważnia regułę allow dla tego samego działania: reguła zezwalająca nie może ustanowić wyjątku od odmowy. Reguły są przechowywane w trzech miejscach: reguły użytkownika w `~/.claude/settings.json`, reguły projektu w `.claude/settings.json` w repozytorium oraz reguły lokalne w `.claude/settings.local.json`. Oto przykład ustawień blokujących odczyt pliku zawierającego klucze: ```json { "permissions": { "deny": [ "Read(./.env)", "Read(./secrets/**)", "Bash(rm *)" ] } } ``` W sesji możesz uruchomić `/permissions`, aby zobaczyć wszystkie aktywne reguły i plik, z którego pochodzi każda z nich. Jeśli reguła blokuje odczyt, komunikat o odmowie wskazuje tę regułę, co przyda się podczas opisanej niżej kontroli. ## Jakie błędy wpłynęły na odmowy i zakres reguł? Błędy dotyczyły kontroli ścieżek i poleceń, a także zakresu reguł pochodzących z różnych plików ustawień. **Pierwszy przypadek: dowiązania symboliczne.** W systemie macOS `/etc`, `/tmp` i `/var` są dowiązaniami symbolicznymi do rzeczywistych katalogów w `/private`; w systemie Linux `/bin` jest często podobnym dowiązaniem. Jeśli regułę deny zapisano dla jednego zapisu ścieżki, a agent uzyskał dostęp, używając innego (na przykład rzeczywistej lokalizacji zamiast dowiązania symbolicznego), reguła się nie uruchamiała. Polecenia Bash również ignorowały odmowę zapisaną dla ścieżki prowadzącej przez dowiązanie symboliczne. W wersji 2.1.268 naprawiono oba przypadki: reguła działa teraz niezależnie od użytego zapisu ścieżki. **Drugi przypadek: `env -C` i `eval` w tym samym wierszu.** Kontrola uprawnień analizuje polecenie, aby ustalić, do jakich plików będzie ono miało dostęp. Nie potrafi analizować konstrukcji takich jak `env -C` lub `eval`. Błąd polegał na tym, że gdy taka konstrukcja pojawiała się w wierszu, reguła deny dotycząca Read lub Edit mogła nie zostać zastosowana. W rezultacie polecenie mogło ominąć odmowę odczytu lub edycji chronionego pliku. **Trzeci przypadek: reguła z „!” działała poza swoim zakresem.** Reguła zaczynająca się od `!` powinna działać wyłącznie w obrębie pliku ustawień, w którym ją zapisano. Przed wersją 2.1.269 obejmowała również inne źródła ustawień. Teraz jej zakres ogranicza się do własnego pliku, a reguła składająca się z samego `!` jest ignorowana. **Czwarty przypadek: zapis przez `tee`.** Polecenie Bash `tee` może zapisywać do pliku. Kontrola ścieżki zapisu i reguły deny `Edit()` nie były stosowane do tego pliku. Jednocześnie uprawnienie `Bash(tee:*)` obejmowało zapisy poza katalogami roboczymi. W wersji 2.1.269 te kontrole zaczęły obejmować również zapisy przez `tee`: odmowa dotycząca pliku zaczyna obowiązywać, a `Bash(tee:*)` obejmuje tylko katalogi robocze. Jeśli używasz ukierunkowanych odmów — aby blokować `.env`, kilka katalogów usług lub niebezpieczne polecenia — sprawdź również te reguły. Poniżej opisano, jak to zrobić. ## Dlaczego /mcp mogło pokazać Twoje klucze?
Najważniejsze informacje w tej sekcji Klucze w konfiguracjach MCP są często przekazywane za pomocą zmiennych `${VAR}`. Polecenia `/mcp`, `/plugin`, `claude mcp list` i `claude mcp get`, a także błędy logowania MCP wyświetlały podstawione wartości, czyli same klucze. W wersji 2.1.268 dane wyjściowe są redagowane.
W konfiguracjach serwerów MCP klucze często przechowuje się w zmiennych środowiskowych i odwołuje do nich za pomocą `${VAR}`, dzięki czemu plik można umieścić w repozytorium bez samych sekretów. Problem polegał na tym, że polecenia wyświetlające konfigurację (`/mcp`, `/plugin`, `claude mcp list`, `claude mcp get`) oraz komunikaty o błędach logowania MCP pokazywały ją z już podstawionymi wartościami. Na ekranie pojawiał się sam klucz. Inna poprawka dotyczy błędów wtyczek i marketplace'u: mogły one wyświetlać token lub hasło z źródłowego adresu URL Git. Jeśli dane wyjściowe `/mcp` lub `claude mcp list` ze starszej wersji pojawiły się w transmisji, na zrzucie ekranu, w wiadomości do współpracownika albo w dzienniku, który opuścił Twój komputer — również automatycznie — załóż, że klucze z konfiguracji MCP zostały ujawnione, i je zmień. Jeśli dane wyjściowe nigdy nie opuściły komputera, wystarczy aktualizacja. Osobny przewodnik po serwerach MCP i gotowych konfiguracjach znajdziesz tutaj: [Serwery MCP Claude Code](https://ailoot.ai/blog/pl/mcp-servers-claude-code/). ## Inne zmiany w tych wersjach **WebFetch i artefakty.** Wcześniej reguła `WebFetch` bez szczegółów w deny lub ask obejmowała również odczyt i modyfikowanie opublikowanych artefaktów. Od wersji 2.1.268 nie ma już do nich zastosowania. Aby zablokować artefakty, potrzebujesz osobnej reguły `Artifact` albo reguły dla domeny, takiej jak `WebFetch(domain:claude.ai)`. Jeśli polegałeś na ogólnej odmowie WebFetch, aby chronić przed odczytem artefaktów, ponownie sprawdź ustawienia: poprzednia reguła nie blokuje już tych działań. **WebFetch ma teraz limit czasu.** Żądanie do serwera, który utrzymuje otwarte połączenie i nie kończy odpowiedzi, kończy się teraz niepowodzeniem po 300 sekundach. Wcześniej takie żądanie mogło zawiesić się bez końca. Zachowanie można skonfigurować za pomocą zmiennej `CLAUDE_CODE_WEBFETCH_DEADLINE_MS`; ustawienie jej na 0 wyłącza limit czasu. **Usunięto problem stale wysokiego użycia procesora podczas bezczynnych sesji.** W długich, bezczynnych sesjach pętla bezczynności w Claude Code mogła powodować stale wysokie użycie procesora. Błąd naprawiono w wersji 2.1.268. Mógł on również dotyczyć osób, które pozostawiają sesje otwarte przez cały dzień. **Zainstaluj najnowszą wersję.** W wersji 2.1.269 pojawił się nowy błąd: po długim czasie działania sesji polecenia Bash Git, które tylko odczytywały dane, zaczynały prosić o uprawnienia. Naprawiono go w wersji 2.1.270. Zaktualizuj więc program do najnowszej wersji (na 17 września 2026 r. była to 2.1.274); nie zatrzymuj się na wersji 2.1.268 ani 2.1.269. ## Jak zaktualizować program i sprawdzić, czy odmowy działają?
Najważniejsze informacje w tej sekcji Sprawdź wersję poleceniem `claude --version`, zaktualizuj program do najnowszego wydania, a następnie przetestuj regułę na bezpiecznym pliku bez sekretów: dodaj dla niego regułę deny, poproś agenta o odczytanie pliku i sprawdź, czy komunikat o odmowie wskazuje Twoją regułę.
1. **Sprawdź aktualną wersję.** Uruchom w terminalu `claude --version`. Poprawki opisanych wyżej problemów wydano w wersjach 2.1.268 i 2.1.269. Jeśli numer wersji jest niższy niż 2.1.268, Twoja wersja nie zawiera jeszcze tych poprawek, choć to, czy dotyczy Cię każdy z problemów, zależy od używanych ścieżek, poleceń i reguł. 2. **Zaktualizuj program.** W przewodniku [jak zaktualizować Claude Code do najnowszej wersji](https://ailoot.ai/blog/pl/update-claude-code/) znajdziesz instrukcje krok po kroku i wskazówki dotyczące rozwiązywania problemów. Wybierz najnowszą wersję; nie zatrzymuj się na 2.1.268. 3. **Przetestuj odmowę.** Nie testuj reguły na prawdziwym pliku `.env`: jeśli odmowa zawiedzie, agent zobaczy prawdziwe klucze. Utwórz plik testowy, na przykład `secret-test.txt`, zawierający dowolny tekst, taki jak „to jest test”; dodaj regułę `"Read(./secret-test.txt)"` do listy deny w pliku `.claude/settings.json` projektu; uruchom ponownie sesję, a następnie poproś: „odczytaj plik secret-test.txt i powiedz mi, co zawiera”. Oczekiwanym działaniem jest odmowa wskazująca nazwę Twojej reguły. Jeśli agent odczyta plik, odmowa nie zadziałała w tym teście. Zacznij od sprawdzenia składni w powyższej sekcji i otwórz `/permissions`, aby zobaczyć aktywne reguły oraz pliki, z których je wczytano. Sam wynik testu nie wskazuje przyczyny. Jedna odmowa potwierdza, że działa reguła dotycząca tego pliku; nie mówi nic o pozostałych regułach, więc sprawdź je pojedynczo w ten sam sposób. 4. **Sprawdź przypadek dowiązań symbolicznych, jeśli używasz takich ścieżek.** Jeśli masz reguły odmowy dotyczące `/tmp`, `/etc` lub `/var` w systemie macOS albo `/bin` w systemie Linux, po aktualizacji powtórz test dla tych ścieżek. 5. **Przejrzyj reguły z „!”.** Jeśli ich używasz, sprawdź, czy każda jest zapisana w pliku, w którym ma obowiązywać. Jeśli odmowa działa, ale Claude Code nadal nie widzi potrzebnych plików, przeczytaj osobne wyjaśnienie: [dlaczego Claude Code nie może zobaczyć plików projektu](https://ailoot.ai/blog/pl/claude-code-cant-see-project-files/). ## Jeśli nie możesz teraz zaktualizować programu Czasami trzeba odłożyć aktualizację: nie możesz zmienić środowiska, komputer należy do firmy albo musisz dokończyć bieżące zadanie. Do czasu aktualizacji możesz ograniczyć ryzyko w następujący sposób: - zapisz reguły deny dla obu zapisów ścieżki — dowiązania symbolicznego i rzeczywistej lokalizacji (w systemie macOS rzeczywiste ścieżki znajdują się w `/private`); - nie łącz wielu poleceń w jednym wierszu i unikaj `env -C` oraz `eval` w poleceniach, których wykonanie zlecasz agentowi; - nikomu nie pokazuj danych wyjściowych `/mcp`, `/plugin`, `claude mcp list` ani `claude mcp get`; zmień klucze z konfiguracji MCP, które mogły trafić w niepowołane ręce; - pamiętaj, że `tee` omija deny dla Edit i zapisuje pliki — jeśli Bash jest dozwolony, nie uznawaj plików za chronione. Te środki zmniejszają prawdopodobieństwo wystąpienia określonych obejść, ale nie zastępują poprawki. Zaktualizuj program i wykonaj test z poprzedniej sekcji, gdy tylko będzie to możliwe. ## Krótkie podsumowanie Wersje 2.1.268 i 2.1.269 naprawiły cztery problemy z uprawnieniami w Claude Code: dowiązania symboliczne, wiersze z `env -C` i `eval`, reguły z „!” wykraczające poza własny plik oraz zapisy przez `tee`. Osobno naprawiono ujawnianie sekretów w danych wyjściowych `/mcp` i wyświetlanie tokenów w błędach wtyczek. Sprawdź numer wersji, zaktualizuj program do najnowszego wydania i wykonaj test z plikiem testowym opisany powyżej. Odmowa wskazująca Twoją regułę potwierdza, że działała ona w tym teście. Sama obecność reguły w ustawieniach nie wystarcza, aby ją zweryfikować.
### Źródła - Claude Code, oficjalny dziennik zmian (wpisy dotyczące wersji 2.1.268, 2.1.269 i 2.1.270): - Claude Code, daty wydań wersji w npm: - Claude Code, dokumentacja uprawnień (składnia deny/ask/allow): - Claude Code, wydania w GitHub:
Aby kontynuować pracę z modelami, przejdź do [Ailoot](https://ailoot.ai/). ## Pytania i odpowiedzi ### Jak przetestować regułę deny bez ujawnienia prawdziwego sekretu? Utwórz plik z nieszkodliwym tekstem, zabroń dostępu Read do tego pliku testowego, uruchom sesję ponownie i poproś agenta o odczyt. Oczekuj odmowy wskazującej Twoją regułę. Nigdy nie używaj prawdziwego pliku .env do testu, który może się nie udać. ### Czy jedna poprawna odmowa dowodzi bezpieczeństwa wszystkich uprawnień? Nie. Potwierdza tylko sprawdzony plik i ścieżkę dostępu. Przejrzyj aktywne reguły w /permissions i przetestuj inne potrzebne ścieżki oraz przypadki, również zapis przez dowiązanie symboliczne, jeśli ma znaczenie. ## Ailoot · Firma i jej portfel projektów Ailoot opiera się na zgromadzonym doświadczeniu operacyjnym, szerokiej bazie klientów, stabilnej usłudze i stałej kontroli KPI. Firma i jej portfel projektów: miliony klientów; miesięczna sprzedaż liczona w miliardach. Ailoot wykorzystuje to doświadczenie operacyjne, zapewniając dostęp przez API do funkcji AI w produktach klientów, agentach, aplikacjach i automatyzacjach.