Claude Code 2.1.304–2.1.306: zgoda człowieka w hookach i sandbox w CI

Trzy kolejne wydania Claude Code, 2.1.304, 2.1.305 i 2.1.306, opublikowane między 19 a 21 października 2026, układają się w jedną tezę: automatyzacja agenta jest bezpieczna tylko wtedy, gdy wiadomo, kto ma ostatnie słowo. Wersja 2.1.304 pozwala hookowi modu zażądać zgody człowieka, której nie da się zastąpić automatem. Wersja 2.1.305 dodaje opcję sandbox.allowNestedUserNamespaces, którą producent opisuje jako osłabienie ochrony plików. Wersja 2.1.306 to dwie drobne poprawki, ale jedna z nich dotyczy CI.

Ten tekst opiera się na notatkach wydań i na dokumentacji Claude Code. Co jest moją interpretacją albo czego nie udało mi się potwierdzić, oznaczam wprost. Wcześniejszą poprawkę sandboxa (zapis do katalogu --plugin-dir) opisałem w tekście o wersji 2.1.299, więc tu do niej nie wracam.

W skrócie:

• decider: "person" w odpowiedzi hooka tool.check (2.1.304) oznacza, że zgodę może dać tylko okno uprawnień albo callback hosta. Tam, gdzie nikt nie może zapytać, wywołanie jest odrzucane z powodem podanym przez mod.
• sandbox.allowNestedUserNamespaces (2.1.305) uruchamia w sandboxie Linuksa narzędzia, które potrzebują zagnieżdżonych przestrzeni nazw użytkownika. Kosztem jest utrata ochrony plików.
• Do CI i headless najważniejsze są: wersja 2.1.305 lub nowsza, ścisły sandbox, kontener jako zewnętrzna granica i projektowanie pipeline’u tak, żeby odmowa była oczekiwanym wynikiem.

Co zmieniły wersje 2.1.304, 2.1.305 i 2.1.306

Wybrałem pozycje związane ze zgodą człowieka, sandboxem i niezawodnością automatyzacji. Każda pochodzi dosłownie z notatek wydań, a pełne listy są znacznie dłuższe.

Dwie uwagi o dokładności. Po pierwsze, poprawka z worktree w 2.1.305 dotyczy repozytoriów bare, a nie każdego repozytorium. Po drugie, tego, że wersja 2.1.304 wprowadziła regresję z tool search, dowiadujemy się dopiero z notatek 2.1.305. Jeśli pracujesz przez Vertex, Bedrock albo własną bramkę, wersję 2.1.304 pomiń i przejdź od razu na 2.1.305 lub nowszą.

Teza pierwsza: człowiek w pętli jako twardy wymóg

Do tej pory hook modu w zdarzeniu tool.check mógł zwrócić allow, ask albo deny. Problem z ask polegał na tym, że nie gwarantował on, kto odpowie. Dokumentacja uprawnień opisuje, że mod potrafi zatwierdzić wywołanie, zanim zostaniesz zapytany, a bez ustawień zarządzanych lub logowania Team/Enterprise taki mod może nawet zatwierdzić coś, co odrzuca reguła deny. Szczegóły są w sekcji o pierwszeństwie reguł, hooków i modów w dokumentacji uprawnień. Moja interpretacja motywu zmiany (notatki go nie podają): przy kilku modach i automatyzacji „zapytaj” mogło w praktyce skończyć się odpowiedzią automatu.

Wersja 2.1.304 dodaje decider: "person". Dosłownie z notatek: tylko okno uprawnień albo callback hosta może zatwierdzić takie żądanie, a tam, gdzie nikt nie może zapytać, wywołanie jest odrzucane z powodem podanym przez mod.

Jak użyć decider: "person"

Zastrzeżenie, które musi stać przed kodem: dokumentacja modów na 22 października 2026 nie zawiera jeszcze pola decider. Sprawdziłem strony o zdarzeniach modów i o ich referencji, a jedynym źródłem jest notatka wydania 2.1.304. Poniższy przykład składam z dwóch potwierdzonych elementów: udokumentowanego kształtu odpowiedzi { decision, reason } i pola decider z notatek. Pełnego przykładu z dokumentacji nie ma, więc przetestuj go na własnej wersji, zanim na nim polegasz.

Szkielet pochodzi z przykładu z dokumentacji (blokada git push na gałęzi main), przerobionego tak, żeby push wymagał człowieka:

on('tool.check', { tool: 'Bash' }, async ($, e, next) => {
  // Claude Code's own decision
  const decided = await next(e)
  if (decided.decision === 'deny') return decided
  if (!e.input.command.includes('git push')) return decided
  return {
    decision: 'ask',
    decider: 'person', // shape assembled from the 2.1.304 release note
    reason: 'A push needs approval from a person',
  }
})

Co ten kod robi i czego nie gwarantuje:

• Odmowy (deny) przepuszcza bez zmian, a polecenia bez git push zostawia z decyzją, którą Claude Code podjąłby bez modu.
• Dla git push zwraca prośbę o zgodę, którą ma wydać człowiek. W sesji interaktywnej zobaczysz okno uprawnień. W SDK rolę hosta pełni callback zatwierdzania (moja interpretacja: chodzi o mechanizm w rodzaju canUseTool z dokumentacji uprawnień, notatki nie podają nazwy).
• Dokumentacja ostrzega, że hook dopasowuje tekst polecenia, więc to przypomnienie dla Claude’a, a nie zabezpieczenie. Prawdziwą ochroną gałęzi main jest jej zabezpieczenie po stronie hosta Git.

Jak to przetestować: dokumentacja ma stronę o testowaniu modu bez sesji i bez sieci. Sprawdź tam trzy przypadki: polecenie z git push (oczekiwana prośba o człowieka), polecenie bez git push (bez zmian) i polecenie odrzucone regułą deny (nadal odrzucone). Potem uruchom claude -p bez callbacku i upewnij się, że git push kończy się odmową z Twoim powodem. Co dokładnie dzieje się wtedy w trybie dontAsk, notatki nie mówią, więc sprawdź to na własnej instalacji.

Czego notatki nie mówią o decider: "person"

• Nie wyjaśniają, którzy zatwierdzający są wykluczeni (inne mody, hooki PermissionRequest, klasyfikator trybu auto). Czytam to jako „nikt automatyczny”, ale to wniosek z jednego zdania, a nie zapis z dokumentacji.
• Nie określają, czy działa w sesjach w chmurze i w Cowork. Jedna z poprawek 2.1.304 mówi, że zaplanowane sesje Cowork czekały pięć minut na każdą zgodę na adres URL, której nikt nie mógł wydać. To ten sam rodzaj sytuacji, ale notatki nie łączą obu zmian.

Jeśli dopiero poznajesz mody, zacznij od przewodnika po modach w Claude Code i od panelu subagentów. Różnicę między hookiem, MCP, skillem i subagentem porządkuje wpis MCP, skill, subagent, hook. Analogiczne podejście w Copilocie, czyli wymuszanie granic z zewnątrz, a nie prośbą do modelu, opisuje tekst o granicach dostępu agentów GitHub Copilot.

Dwie pokrewne poprawki

Obie z 2.1.304 i obie o tym, że hook ma działać przewidywalnie:

• Powód odmowy z hooka PreToolUse nie jest już zastępowany błędem przekroczenia czasu, gdy callback hooka z Agent SDK na tym samym wywołaniu przekroczył limit.
• Wtyczka nie podtrzymuje uruchomienia headless ponad --max-turns, Stop ani koniec wejścia przez uruchamianie subagentów. To następca poprawki z 2.1.299, w której chodziło o mod wysyłający prompt co turę.

Teza druga: nie osłabiaj sandboxa bez dodatkowej izolacji

Wersja 2.1.305 dodaje sandbox.allowNestedUserNamespaces. Na Linuksie i w WSL2 polecenia w sandboxie domyślnie nie mogą tworzyć przestrzeni nazw użytkownika, więc nie działają narzędzia, które tego potrzebują. Chodzi o wbudowany sandbox Chromium i Electrona, zagnieżdżony bubblewrap oraz unshare. Objawy z dokumentacji to np. komunikat Chromium No usable sandbox!.

Notatka wydania ostrzega wprost, że ta opcja pozwala poleceniom obejść ochronę plików przez sandbox. Dokumentacja jest ostrzejsza:

• Po ustawieniu true „wyłączasz granicę bezpieczeństwa”: kod z polecenia w sandboxie może wylądować poza nim.
• Nie polegaj wtedy na żadnym ograniczeniu sandboxa, także na chronionych ścieżkach i wpisach credentials.files.
• W trybie auto-allow takie polecenie może się wykonać bez pytania o zgodę.
• Claude Code liczy true tylko z ~/.claude/settings.json, z JSON-a podanego przez --settings i z ustawień zarządzanych. W .claude/settings.json projektu i w .claude/settings.local.json jest ignorowane, więc repozytorium samo go nie włączy.
• Przy CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=1 ignorowane jest true ze wszystkich źródeł.
• Domyślnie wartość to false. Opcja wymaga wersji 2.1.305 lub nowszej.

Notatka wydania wymienia „Chromium, rootless podman”, ale dokumentacja to koryguje: same allowNestedUserNamespaces nie wystarcza dla rootless Podmana i Buildah, bo sandbox zatrzymuje je także w inny sposób. Dla nich dokumentacja każe użyć sandbox.excludedCommands. Jeśli czytałeś tylko notatkę, możesz więc włączyć ryzykowną opcję i nadal nie uruchomić Podmana.

Co zrobić zamiast włączać tę opcję

Dokumentacja zaczyna od łagodniejszych rozwiązań, każde z nich oddaje trochę izolacji:

Polecenie zaczynające się od unshare zostaje w sandboxie bez względu na wpisy w excludedCommands, bo unshare może uruchomić dowolny inny program.

Jak sprawdzić, co zostaje po włączeniu opcji

To moja rekomendacja, a nie procedura z dokumentacji, ale wynika wprost z jej ostrzeżenia. Skoro po włączeniu opcji sandbox przestaje być granicą, testować trzeba granicę zewnętrzną, czyli kontener albo maszynę wirtualną, w której biegnie runner. Zasady:

1. Testuj wyłącznie w jednorazowym środowisku, bez prawdziwych poświadczeń, i z tą samą konfiguracją, z jaką pójdzie do produkcji.
2. Ustal, co ma pozostać niedostępne po włączeniu opcji: sekrety w zmiennych środowiskowych, pliki spoza zamontowanego katalogu roboczego, host, tokeny CI, sieć poza listą dozwolonych adresów.
3. Połóż w tych miejscach nieszkodliwe znaczniki, na przykład plik z nieistotną treścią, i sprawdź, czy proces z włączoną opcją dociera do nich spoza kontenera. Odpowiedź „nie” dla każdego znacznika to dowód, że granicę trzyma kontener, a nie sandbox.
4. Powtórz test po każdej zmianie obrazu kontenera, wersji Claude Code i konfiguracji. Wynik z jednego dnia nie przenosi się na następną wersję.
5. Zacznij od pytania, czy opcja jest w ogóle potrzebna. Dokumentacja podaje diagnostykę: unshare -U true kończy się błędem Operation not permitted, gdy przestrzenie nazw są zablokowane. Jeśli problem rozwiązuje --no-sandbox albo excludedCommands, nie ruszaj opcji.

Dokumentacja dodaje jeszcze jedno zdanie: jeśli Twoja organizacja ma zespół bezpieczeństwa, skonsultuj z nim włączenie tej opcji. To dobra wskazówka, a nie formalność.

Checklista dla CI i headless

Poniższa lista łączy zmiany z trzech wydań z zaleceniami z dokumentacji. Pozycje oznaczone „moje zalecenie” nie pochodzą z dokumentacji.

1. Zaktualizuj Claude Code do 2.1.305 lub nowszej. Wersja 2.1.304 miała regresję przy bramkach odrzucających tool search, a 2.1.306 naprawia błędne „Not logged in” w claude -p w sesji chmurowej oraz maskowanie błędu API komunikatem „prompt is too long” przy wielu narzędziach MCP. Przypnij konkretną wersję w obrazie runnera (moje zalecenie).
2. Ściśle skonfiguruj sandbox. Przykład z dokumentacji dla wdrożeń zarządzanych: sandbox.enabled: true, failIfUnavailable: true (brak bubblewrap blokuje start, zamiast cicho uruchamiać polecenia bez sandboxa) i allowUnsandboxedCommands: false (Claude nie ponowi polecenia bez sandboxa).
3. Nie włączaj allowNestedUserNamespaces na zwykłym runnerze. Jeśli już musisz, to tylko w osobnym kontenerze lub maszynie wirtualnej, z kontrolowaną siecią i bez sekretów, których nie wymaga zadanie (moje zalecenie, oparte na ostrzeżeniu producenta).
4. Praca bez nadzoru wymaga zewnętrznej granicy. Dokumentacja o środowiskach sandboxowych mówi, że sam sandbox Bash obejmuje tylko polecenia powłoki, więc nie wystarcza do w pełni nienadzorowanych uruchomień. Narzędzia plikowe, serwery MCP i hooki działają poza nim. Uruchamiaj całość w kontenerze, maszynie wirtualnej lub dev containerze, jako użytkownik niebędący rootem.
5. Zaprojektuj pipeline na odmowę. Hook z decider: "person" odrzuci wywołanie, gdy nikt nie może zapytać. Pipeline powinien traktować to jako czytelny wynik z powodem, a nie błąd do ponawiania w pętli. Zestaw to z --max-turns i --max-budget-usd jako bezpiecznikami kosztów.
6. Worktree przy --worktree. Po aktualizacji do 2.1.304 Claude Code pyta przed usunięciem worktree i gałęzi, gdy HEAD jest odłączony lub na innej gałęzi. W repozytoriach bare zaktualizuj do 2.1.305. Moje zalecenie dla runnerów trwałych: wypychaj pracę przed końcem zadania, bo prośba o potwierdzenie nic nie da, gdy nikt jej nie widzi.
7. Serwery MCP w SDK i chmurze. Po 2.1.305 serwer przekazany przez setMcpServers nie jest później zastępowany serwerem o tej samej nazwie z lokalnych ustawień. Jeśli opierałeś się na obejściu, sprawdź, który serwer faktycznie działa.
8. Obserwuj zdarzenia bezpieczeństwa. Wersja 2.1.307 (21 października 2026) dodaje zdarzenie OpenTelemetry claude_code.safety_event dla każdego wywołania, które zatrzymała, o które zapytała albo które odesłała reguła uprawnień, tryb auto, kontrola bezpieczeństwa, hook lub sandbox. To było dobre źródło do alertów w CI, ale aktualizacja z 28 października: wersja 2.1.312 przestaje to zdarzenie wysyłać, więc nie buduj na nim nadzoru. Szczegóły w tekście o wersjach 2.1.309–2.1.312.
9. Sprawdź konfigurację Managed Agents. Jeśli używasz Managed Agents, /claude-api managed-agents-secure porównuje ustawienia agenta z poradnikiem bezpieczeństwa Anthropic, niczego nie zmieniając. Notatki nie opisują formatu raportu, więc nie opisuję go tutaj.

Koszty długich nienadzorowanych uruchomień warto zestawić z limitami planu: ceny i limity Claude Code, Codexa, Copilota i Antigravity. Wersja 2.1.305 dodała dla trybu ponawiania CLAUDE_CODE_RETRY_WATCHDOG zmienną CLAUDE_CODE_RETRY_WATCHDOG_USAGE_LIMIT_RECHECK_MS, dzięki której nienadzorowany proces zauważa limit zdjęty przed czasem. Notatki nie podają jej wartości domyślnej.

Najczęstsze pytania

Czy decider: "person" zastępuje reguły deny i ask? Nie. To dodatkowe pole w odpowiedzi hooka modu i dotyczy tego, kto może zatwierdzić prośbę. Reguły uprawnień nadal działają, a w dokumentacji uprawnień jest osobna lista, co się dzieje, gdy mod zatwierdza wywołanie.

Czy allowNestedUserNamespaces mogę ustawić w repozytorium projektu? Nie. Claude Code ignoruje true w .claude/settings.json i .claude/settings.local.json projektu. Liczy się tylko ~/.claude/settings.json, --settings i ustawienia zarządzane. To celowe zabezpieczenie przed repozytorium, które samo osłabiłoby sandbox.

Czy mogę włączyć tę opcję tylko dla jednego polecenia? Dokumentacja opisuje opcję jako ustawienie, a nie przełącznik dla pojedynczego polecenia. Dla pojedynczych narzędzi dokumentacja proponuje excludedCommands, które ma własne ryzyko, opisane wyżej.

Czy powinienem pominąć 2.1.304? Jeśli pracujesz przez Vertex, Bedrock lub bramkę odrzucającą tool search, tak: regresja została naprawiona w 2.1.305. W pozostałych przypadkach nic w notatkach nie przemawia za pominięciem, a 2.1.304 niesie poprawkę worktree, która chroni przed utratą commitów.

Czy 2.1.306 coś zmienia w bezpieczeństwie? Nie. To dwie poprawki niezawodności. Dla CI liczy się to, że claude -p w sesji chmurowej nie zgłasza fałszywego „Not logged in”, a błąd API nie jest maskowany komunikatem „prompt is too long”.

Podsumowanie

Dwa kierunki z tych wydań pasują do siebie. decider: "person" daje hookowi sposób na to, żeby ostatnią decyzję podjął człowiek, a nie kolejny automat. allowNestedUserNamespaces pokazuje drugą stronę: gdy chcesz więcej uprawnień dla narzędzi w sandboxie, oddajesz granicę, więc musisz dać ją z innego miejsca. Moja ocena: pierwsza zmiana jest warta wdrożenia w automatyzacjach, które mogą wypychać kod lub zmieniać środowisko, o ile sprawdzisz jej zachowanie w testach. Drugą włączaj dopiero po wyczerpaniu --no-sandbox i excludedCommands, i tylko w odizolowanym środowisku.

Źródła:

• Notatki wydań Claude Code: v2.1.304 (19 października 2026), v2.1.305 (20 października 2026), v2.1.306 (21 października 2026) oraz v2.1.307 (zdarzenie safety_event).
• Dokumentacja Claude Code: Configure the sandboxed Bash tool, Settings reference: sandbox.allowNestedUserNamespaces, Sandbox environments, React to events with a mod, Mods reference i Configure permissions.

Stan na 22 października 2026. Pole decider nie było wtedy opisane w dokumentacji modów, więc jego dokładną składnię potwierdź na własnej wersji.

EfektywnyDev pisze o AI w praktyce: co zmiana w narzędziu oznacza w codziennej pracy z agentami, a nie tylko w notatkach wydania.