Claude Code 2.1.217 ogranicza niekontrolowane agenty

Claude Code 2.1.217 wprowadza domyślny limit 20 równocześnie działających subagentów, wyłącza zagnieżdżone subagenty i naprawia błędy związane z budżetem, linkami symbolicznymi oraz przetwarzaniem plików konfiguracyjnych. To nie jest kosmetyczna aktualizacja interfejsu. Zmiany ograniczają liczbę sposobów, w jakie zbyt autonomiczny albo źle skonfigurowany agent mógł zużywać zasoby, przekraczać granice katalogu roboczego lub kontynuować pracę po wyczerpaniu budżetu.

Anthropic opisał wydanie w oficjalnym CHANGELOG-u Claude Code. Producent nie nadał poprawkom numerów CVE i nie poinformował o potwierdzonym wykorzystaniu ich w atakach. Trzeba więc precyzyjnie oddzielić trzy rzeczy: udokumentowane zachowanie wersji 2.1.217, potencjalne konsekwencje wcześniejszych błędów oraz nasze zalecenia dotyczące wdrożenia. Sam fakt, że poprawka dotyczy izolacji lub uprawnień, nie dowodzi incydentu.

Co dokładnie zmienia Claude Code 2.1.217

Najbardziej widoczna zmiana to limit 20 subagentów działających jednocześnie. Organizacja może go zmienić zmienną CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS, ale podniesienie wartości powinno być decyzją operacyjną, a nie domyślną reakcją na wolne zadanie. Każdy dodatkowy proces to kolejne zapytania do modelu, narzędzia, otwarte pliki, procesy powłoki, połączenia MCP i materiał, który trzeba objąć telemetrią.

Zagnieżdżone subagenty są teraz domyślnie wyłączone. Można je włączyć przez CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH. Ta kontrola ogranicza rekurencyjne tworzenie pracy: agent główny uruchamia podzadanie, podzadanie kolejne, a następne dzieli się ponownie. Bez limitu głębokości trudno przewidzieć koszt, maksymalną liczbę akcji i pełny graf delegowanych uprawnień. Jest to podobny problem do niekontrolowanego rozgałęziania procesów, chociaż mechanizm i skala są inne niż w klasycznej fork bombie.

Wydanie naprawia także działanie --max-budget-usd. Po osiągnięciu limitu nowe subagenty nie powinny już startować, a uruchomione w tle mają zostać zatrzymane. Wcześniej procesy tła mogły kontynuować pracę po osiągnięciu limitu. Budżet finansowy pełni tu również rolę bariery bezpieczeństwa: ogranicza liczbę możliwych prób, czas eksploracji repozytorium i wielkość skutków źle zdefiniowanego celu.

Link symboliczny nie może zmieniać granicy zaufania

Najważniejsza technicznie poprawka dotyczy kanonikalizacji katalogu roboczego dla sesji działających w tle. Według changelogu wcześniejszy mechanizm nie rozwiązywał poprawnie ścieżek z linkami symbolicznymi, co mogło pozwalać sesji wyjść poza oczekiwany folder workspace. Nie oznacza to automatycznie dostępu do całego systemu: znaczenie zależy od uprawnień procesu, polityki narzędzi, kontenera i systemu operacyjnego. Błąd osłabiał jednak założenie, że tekstowa ścieżka katalogu odpowiada rzeczywistej granicy danych.

Bezpieczna kontrola ścieżki powinna działać na ścieżce kanonicznej, po rozwiązaniu symlinków i normalizacji elementów . oraz ... Sprawdzenie samego prefiksu ciągu znaków jest niewystarczające. W środowisku CI agent może otrzymać repozytorium z kontrolowanym przez autora linkiem symbolicznym, a następnie zapisać plik w lokalizacji, której operator nie przewidział. Dlatego bezpieczny sandbox dla agentów AI powinien łączyć kontrolę ścieżek z izolacją systemową: osobnym użytkownikiem, ograniczonym montowaniem katalogów, filtrem wywołań systemowych oraz brakiem sekretów w przestrzeni roboczej.

W wersji 2.1.216, bezpośrednio poprzedzającej dzisiejsze wydanie, Anthropic domknął podobne obejścia w subagentach izolowanych przez Git worktree. Agent nie powinien już przekierować operacji do wspólnego checkoutu przez git -C, --git-dir, GIT_DIR lub GIT_WORK_TREE. Naprawiono też zapis zadań i workflow przez symlink .claude. Te zmiany warto oceniać razem, ponieważ pokazują ten sam wzorzec: logiczna izolacja agenta musi obejmować alternatywne sposoby wskazywania zasobu, nie tylko najbardziej oczywistą ścieżkę polecenia.

Ochrona przed wyczerpaniem pamięci

Claude Code odczytuje instrukcje z plików CLAUDE.md i SKILL.md. W ich frontmatter pole paths może korzystać z rozwijania nawiasów klamrowych. Wydanie 2.1.217 ogranicza to rozwijanie, aby złośliwy lub błędny wzorzec nie powodował braku pamięci albo zawieszenia. Jest to kontrola dostępności: mały fragment konfiguracji potrafił wygenerować bardzo dużą liczbę kombinacji, zanim agent wykonał właściwe zadanie.

Taki plik należy traktować jak wykonywalną politykę, nawet jeśli formalnie jest Markdownem. Może sterować doborem kontekstu, narzędzi i instrukcji. W repozytorium przyjmującym pull requesty od niezaufanych osób konfiguracja agenta powinna przejść osobny przegląd. Dobrą praktyką jest limit wielkości pliku, liczby wzorców, liczby dopasowanych ścieżek i czasu parsowania. Mechanizm fail-closed powinien przerwać zadanie, zamiast próbować kontynuować z niepełną polityką.

Producent naprawił również wyciek pamięci, w którym obcięty wynik narzędzia MCP zachowywał w pamięci pełny rezultat. To ważne zarówno dla dostępności, jak i minimalizacji danych. Jeśli użytkownik widzi wyłącznie skrócony wynik, nie powinien zakładać, że pełna odpowiedź została usunięta z procesu. Po aktualizacji nadal trzeba kontrolować maksymalny rozmiar odpowiedzi MCP, retencję logów oraz dane przekazywane do Model Context Protocol.

Zmiany istotne dla Windows i środowisk firmowych

Claude Code 2.1.217 przywraca automatyczną aktualizację na Windows, gdy po nieudanej aktualizacji brakuje claude.exe. Poprzednia wersja naprawiła walidację poleceń PowerShell zawierających niewidoczne znaki Unicode i sprawiła, że polecenia tylko do odczytu na ścieżkach sieciowych Windows ponownie wymagają potwierdzenia. Z punktu widzenia administratora oznacza to, że test regresji powinien objąć nie tylko Linux i macOS, ale też UNC, PowerShell, lokalne polityki wykonania oraz zachowanie klienta po przerwanym update.

W sesjach uruchamianych z Claude Desktop mają być respektowane ustawienia korporacyjnego mTLS, weryfikacji TLS, zakresów OAuth i proxy. Zarządzana wartość OTEL_EXPORTER_OTLP_ENDPOINT otrzymała pierwszeństwo dla sygnałów telemetrycznych, aby konfiguracje o niższym poziomie zaufania nie przekierowywały ich do innego odbiorcy. Jest to rozsądny kierunek, ale administrator powinien potwierdzić go w swoim środowisku: przechwycić ruch testowej stacji, sprawdzić łańcuch certyfikatów, odbiorcę OTLP i zachowanie po błędnym certyfikacie.

Model zagrożeń: przed czym te limity chronią

Nowe zabezpieczenia ograniczają cztery klasy ryzyka. Pierwsza to eksplozja pracy: cel o niejasnym końcu powoduje tworzenie kolejnych subagentów i rosnące koszty. Druga to ucieczka z logicznego workspace przez alternatywną reprezentację ścieżki. Trzecia to odmowa usługi przez konfigurację o ogromnej liczbie rozwinięć albo wynik narzędzia trzymany w pamięci. Czwarta to utrata kontroli nad ruchem i telemetrią, jeśli agent omija korporacyjny proxy lub wysyła sygnały do niezarządzanego endpointu.

Aktualizacja nie usuwa jednak ryzyka prompt injection, błędnych poleceń powłoki, nadmiernych uprawnień tokenu ani złośliwego serwera MCP. Nie zastąpi red teamingu agentów LLM, modelowania zagrożeń i ochrony tożsamości agentów AI. Limit liczby agentów ogranicza skalę, ale jeden proces z kluczem administratora nadal może spowodować poważny incydent.

Bezpieczny plan aktualizacji

Najpierw zinwentaryzuj wszystkie instalacje Claude Code: laptopy, obrazy deweloperskie, self-hosted runnery, kontenery CI i automaty tworzące pull requesty. Sam numer wersji na stacji administratora nie mówi nic o wersji działającej w obrazie zbudowanym miesiąc temu. Ustal właściciela każdego wdrożenia i sposób wymuszania wersji.

Następnie utwórz reprezentatywny zestaw testów:

zadanie próbujące uruchomić więcej niż 20 subagentów;
podagent próbujący utworzyć kolejnego podagenta;
zadanie w tle, które osiąga --max-budget-usd;
repozytorium z symlinkiem wskazującym poza katalog roboczy;
worktree z próbą użycia GIT_DIR i git -C;
SKILL.md z kontrolowanym, dużym rozwinięciem nawiasów;
serwer MCP zwracający bardzo duży rezultat;
sesję Windows z UNC, PowerShell i wymuszonym proxy;
błędny certyfikat mTLS oraz próbę zmiany odbiorcy OTLP;
osiągnięcie limitu przy aktywnym procesie narzędziowym.

Wynik testu powinien obejmować kod zakończenia, zdarzenia audytowe, aktywne procesy potomne, liczbę zapytań do modelu i stan zmodyfikowanych plików. Sam komunikat w UI nie dowodzi, że proces w tle rzeczywiście przestał działać.

Konfiguracja, której nie warto poluzować bez pomiaru

Nie podnoś CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS, dopóki nie znasz szczytowego użycia CPU, pamięci, tokenów, połączeń i blokad repozytorium. Ustaw głębokość tworzenia subagentów na zero lub jeden, jeżeli przypadek użycia nie wymaga dalszej delegacji. Osobno limituj czas zadania, koszt, liczbę wywołań narzędzi i maksymalny rozmiar danych wyjściowych. Różne limity zatrzymują różne pętle awarii.

Agenta uruchamiaj z krótkotrwałą tożsamością workloadu, nie z osobistym tokenem programisty. Uprawnienia do repozytorium rozdziel na odczyt, zapis gałęzi i operacje administracyjne. Produkcja, menedżer sekretów i system wdrożeniowy nie powinny być osiągalne z tego samego kontekstu sieciowego. Zmiany kodu muszą przejść kontrolę człowieka, testy i politykę CI, nawet jeżeli model deklaruje wysoką pewność.

Monitoring po wdrożeniu

W pierwszej kolejności obserwuj liczbę aktywnych subagentów, głębokość grafu, odrzucone próby utworzenia procesu, zatrzymania budżetowe i odwołania do ścieżek poza workspace. Dodaj metryki pamięci procesu, rozmiaru odpowiedzi MCP i czasu parsowania instrukcji. Dla ruchu sieciowego rejestruj docelową domenę i klasę narzędzia, ale nie kopiuj bez potrzeby sekretów ani pełnych promptów do centralnych logów.

Alert powinien powstać, gdy agent próbuje zmienić GIT_DIR, odwołuje się do rodzica katalogu roboczego, uruchamia nietypowo dużo podprocesów albo wielokrotnie trafia w odmowę polityki. Takie zdarzenie nie musi oznaczać ataku; może wskazywać źle rozpisane zadanie. Jest jednak dobrym sygnałem do zatrzymania i analizy. Obserwowalność agentów AI powinna umożliwiać odtworzenie grafu decyzji bez polegania na narracji wygenerowanej przez sam model.

Zachowaj także punkt odniesienia sprzed aktualizacji: medianę i percentyle liczby subagentów, kosztu, czasu oraz pamięci dla kilku typowych zadań. Pozwoli to odróżnić regresję wydajności od prawidłowego zadziałania nowego limitu. W logach warto rozdzielić odmowę wynikającą z polityki, brak zasobu, osiągnięcie budżetu i błąd narzędzia. Bez tego zespół zacznie podnosić limity, choć rzeczywistą przyczyną może być pętla planowania albo wadliwe polecenie.

Retencja telemetryki powinna odpowiadać ryzyku repozytorium. Dla kodu krytycznego zachowaj wystarczający okres do powiązania później wykrytej zmiany z sesją agenta, wersją klienta i zestawem narzędzi. Dostęp do tych zapisów ogranicz tak samo jak dostęp do kodu, ponieważ argumenty poleceń i nazwy plików mogą ujawniać architekturę lub tajemnice projektu.

Co powinien zrobić zespół dzisiaj

Zaktualizuj Claude Code do wersji zawierającej opisane poprawki, ale traktuj rollout jak zmianę narzędzia wykonującego kod. Sprawdź sumę i źródło pakietu, przetestuj polityki, uruchom etap pilotażowy na repozytorium bez sekretów, a następnie wymuś wersję w obrazach CI. Zachowaj poprzedni obraz do kontrolowanego rollbacku, lecz nie pozostawiaj podatnej wersji jako łatwo dostępnej ścieżki domyślnej.

Jeśli Claude Code ma dostęp do kodu klientów, infrastruktury albo procesu publikacji, ogólny hardening Claude Code powinien zostać uzupełniony o testy regresji dla wersji 2.1.217. Potrzebujesz niezależnej oceny sandboxa, integracji MCP lub pipeline’u agentowego? Umów audyt bezpieczeństwa AI z BreachRoad — sprawdzimy rzeczywiste granice uprawnień, a nie tylko deklaracje w konfiguracji.