Claude Code 2.1.268: co naprawiono w regułach deny i MCP

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.

Co naprawiono w Claude Code 2.1.268 i 2.1.269?#

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?#

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:

{
  "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?#

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.

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ą?#

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 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.

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ć.

Aby kontynuować pracę z modelami, przejdź do Ailoot.