Claude Code 2.1.325: Bash w sandboxie pyta o uprawnienia

Claude Code 2.1.325 (otwiera się w nowej karcie), opublikowany 13 listopada 2026, łata błąd bezpieczeństwa w dekodowaniu odpowiedzi skompresowanych zstd, więc warto go zainstalować. Najpierw jednak zmień ustawienia: wydanie każe pytać o zgodę w trzech miejscach, w których dotąd nikt nie pytał. Polecenia Bash w sandboxie przechodzą teraz zwykłą ścieżkę uprawnień; ustaw sandbox.autoAllowBashIfSandboxed: true, żeby dalej szły bez pytania, a w ustawieniach zarządzanych ustaw ten klucz w najwyżej postawionym źródle. Zaplanowane zadania i /loop pytają teraz przed uruchomieniem skilla, który deklaruje allowed-tools albo hooki; dla każdego takiego skilla dodaj Skill(nazwa) do permissions.allow. Polecenia git tylko do odczytu pytają w repozytorium, które nie jest repozytorium projektu ani zaufanym; wskaż je przez --add-dir. W przebiegu claude -p, w którym nikt nie odpowie, pytanie bez odpowiedzi oznacza odrzucone polecenie: przebieg idzie dalej bez niego, więc zadanie CI nie zatrzymuje się na kroku, który się już nie wykonuje. Na 15 listopada 2.1.325 ma w npm tagi latest i next, a stable wskazuje wciąż 2.1.311, które niczego z tego nie zawiera. Każde twierdzenie sprawdziliśmy 15 listopada 2026 w informacjach o wydaniu, changelogu, rejestrze npm i dokumentacji Claude Code; nowej wersji nie uruchamialiśmy.

Co się zmieniło w Claude Code 2.1.325

Informacje o wydaniu 2.1.325 mają 139 pozycji: 88 poprawek, 30 zmian, 14 ulepszeń, sześć nowości i jedno usunięcie. Pierwsza to poprawka bezpieczeństwa: „Fixed a security issue in how zstd-compressed responses are decoded”. To, co zmienia działanie bez pytania, jest wśród 30 zmian:

Daty ustala rejestr. Rejestr npm (otwiera się w nowej karcie) notuje 2.1.323 o 20:29 UTC 12 listopada, 2.1.324 o 18:42 UTC 13 listopada i 2.1.325 o 20:07 UTC tego samego dnia, 85 minut później; GitHub opublikował wydanie o 20:40 UTC. 2.1.324 nie ma wydania na GitHubie ani wpisu w changelogu (otwiera się w nowej karcie), który przeskakuje z 2.1.323 od razu do 2.1.325. A jednak dokumentacja ustawień (otwiera się w nowej karcie) mówi o autoAllowBashIfSandboxed: „Default: false. Before v2.1.324, the default was true”. Traktuj więc każdą maszynę na 2.1.324 jak już zmienioną, a 2.1.323 jako ostatnią wersję ze starymi ustawieniami domyślnymi. To druga w ciągu miesiąca zmiana domyślnych uprawnień, która dotyka przebiegów headless: Claude Code 2.1.299 do 2.1.302 w październikowym przeglądzie opisuje wydanie, które zmieniło tryb uprawnień, w którym startują niektóre przebiegi claude -p, i to, dlaczego w CI przypinamy wersję.

Reszta pracy nad bezpieczeństwem jest w poprawkach. Kilka zamyka luki w sprawdzaniu uprawnień Basha: niektóre polecenia złożone działały bez pytania, reguła allow dla Basha mogła uruchomić inny program niż ten, który nazywa, a część reguł deny i ask nie obejmowała niektórych poleceń Bash albo, zapisana jako ścieżka względna, jak Read(./.env), przestawała obejmować projekt po cd. Trzy uszczelniają sandbox: w niektórych przypadkach blokuje teraz zapis poleceń z sandboxa do folderu pobierania natywnego updatera, w pełni chroni ustawienia i hooki worktree oraz wspólny folder git podpiętego worktree. Sandbox odmawia też teraz zapisu do ustawień, skilli, agentów, komend i hooków w .claude w dodanych katalogach, tak jak robił to w folderze startowym, a własne programy pomocnicze, takie jak most sieciowy, uruchamia bez tokenów logowania i kluczy API Claude Code w środowisku.

Co robi autoAllowBashIfSandboxed

sandbox.autoAllowBashIfSandboxed decyduje, czy polecenie działające w sandboxie wymaga zgody. Dokumentacja sandboxa (otwiera się w nowej karcie) nazywa wartość true trybem auto-allow: Claude Code zatwierdza polecenie automatycznie, bez pytania, gdy działa ono w sandboxie. Przy false, w zwykłym trybie uprawnień, wszystkie polecenia Bash przechodzą zwykłą ścieżkę uprawnień, nawet w sandboxie. Dokumentacja ustawień dodaje granice auto-allow: reguły deny i reguły ask z treścią, takie jak Bash(git push *), nadal działają, gołą regułę ask Bash sandbox pomija, a polecenie, którego nie da się uruchomić w sandboxie, i tak przechodzi zwykłą ścieżkę. Klucz zmienia krok zatwierdzania przed sandboxem, a nie to, co sandbox pozwala poleceniu czytać, zapisywać czy otwierać w sieci.

Kogo to dotyczy i jak to sprawdzić

Dotyczy cię, jeśli maszyna albo runner przechodzi na 2.1.324 lub nowszą wersję i spełniony jest jeden z warunków:

• Sandbox jest włączony, a ty liczysz na to, że pomija pytania. Sesje interaktywne zaczynają pytać o każde polecenie w sandboxie, którego nie obejmuje żadna reguła allow. Jeśli zespół wybrał sandbox po to, żeby nie zatwierdzać każdego npm test, to tę zmianę zauważy pierwszą.
• Organizacja włącza sandbox przez ustawienia zarządzane. Każdy programista objęty tą polityką dostaje pytania, dopóki sama polityka nie ustawi autoAllowBashIfSandboxed.
• Uruchamiasz Claude Code bez nadzoru: claude -p w CI, zadanie z crona, aplikację na Agent SDK, zaplanowane zadanie albo /loop. Według dokumentacji trybu headless (otwiera się w nowej karcie) przebieg claude -p w trybie Manual odrzuca wywołanie wymagające zgody, chyba że zatwierdzi je hook PermissionRequest albo --permission-prompt-tool, a od 2.1.302 przebieg -p startuje w trybie Manual, gdy nic nie ustawia trybu (tę zmianę opisaliśmy w przeglądzie z 18 października, linkowanym wyżej). W zwykłym CI zadanie więc nie wisi: polecenie zostaje odrzucone, a praca, którą miało wykonać, się nie odbywa. Inaczej jest w aplikacji Agent SDK z callbackiem canUseTool albo w przebiegu z narzędziem do pytań o zgodę: tam, jak opisuje dokumentacja o pytaniach o zgodę w przebiegach bez nadzoru (otwiera się w nowej karcie), przebieg czeka na odpowiedź hosta.
• Zaplanowane zadania lub pętle wywołują skille, które deklarują allowed-tools albo hooki. allowed-tools w skillu daje te narzędzia bez zgody na turę, która go wywołuje, jak mówi dokumentacja skilli (otwiera się w nowej karcie), i właśnie dlatego zaplanowane uruchomienie pyta teraz przed takim skillem.

Trzy polecenia mówią, gdzie jest dana maszyna. claude --version podaje wersję. claude doctor pokazuje instalację i ostatnią próbę automatycznej aktualizacji. /status w sesji pokazuje wiersz Setting sources, który nazywa obowiązujące źródło zarządzane, na przykład Enterprise managed settings (file).

Kiedy zmiana do ciebie dotrze, zależy od kanału wydań. Instalacje natywne domyślnie idą za latest; z autoUpdatesChannel: "stable" idą za wersją, która według dokumentacji instalacji (otwiera się w nowej karcie) ma zwykle około tygodnia i pomija wydania z poważnymi regresjami. 15 listopada 2026 tag stable w rejestrze wskazuje 2.1.311, opublikowane 26 października. Cask Homebrew claude-code idzie za stable, a claude-code@latest za latest; instalacje z Homebrew, WinGet, apt, dnf i apk domyślnie same się nie aktualizują.

Jak zaktualizować Claude Code do 2.1.325 bez nowych pytań o zgodę

1. Znajdź każdą instalację i jej kanał

   Na każdym laptopie, obrazie runnera i serwerze uruchom claude --version i claude doctor. Zanotuj, które idą za latest (mogą już mieć 2.1.325), a które za stable albo przypiętą wersją (15 listopada 2.1.311 lub starszą). Obrazy CI, które instalują @anthropic-ai/claude-code@latest, dostaną zmianę przy najbliższym buildzie.

2. Zdecyduj o auto-allow w sandboxie i ustaw je tam, gdzie wygrywa

   Jeśli polecenia w sandboxie mają dalej działać bez pytania, ustaw sandbox.autoAllowBashIfSandboxed na true obok sandbox.enabled. Dla zespołu wpisz to do commitowanego .claude/settings.json, dla jednej osoby do ~/.claude/settings.json. W ustawieniach zarządzanych dodaj klucz do bloku sandbox w źródle, które wskazuje /status, czyli w najwyżej postawionym.

3. Zezwól na skille z zaplanowanych zadań i pętli

   Dla każdego skilla wywoływanego przez zaplanowane zadanie albo /loop, który deklaruje we frontmatterze allowed-tools lub hooks, dodaj Skill(nazwa) do permissions.allow, albo Skill(nazwa *), gdy przyjmuje argumenty. Zezwalaj tylko na skille, które mają działać bez nadzoru.

4. Wskaż dodatkowe repozytoria i sprawdź ścieżki runnerów

   Jeśli Claude uruchamia polecenia git tylko do odczytu w drugim repozytorium, startuj sesję z --add-dir <ścieżka>; ustawienie additionalDirectories już nie wyłącza pytania. Na self-hosted runnerach upewnij się, że folder sesji i ścieżka repozytorium nie są dowiązaniami symbolicznymi.

5. Niech przebiegi bez nadzoru zawodzą głośno

   Dodaj --permission-prompts none do zaplanowanych zadań claude -p albo ustaw permissions.denyInsteadOfPrompting: true w ustawieniach użytkownika lub zarządzanych, żeby przebieg nigdy nie czekał na pytanie, na które nikt nie odpowie. Z --output-format stream-json czytaj listę permission_denials w końcowym wyniku i oznaczaj zadanie jako nieudane, gdy nie jest pusta.

6. Zaktualizuj i uruchom każde zadanie raz pod okiem

   Uruchom claude update albo, dla instalacji z npm, npm install -g @anthropic-ai/claude-code@2.1.325. Potem uruchom jedno zadanie CI, jedno zaplanowane zadanie i jedną sesję interaktywną z włączonym sandboxem i sprawdź, że żadne nie pyta ani nie zgłasza odmowy, której się nie spodziewasz.

Ustawienia dla zespołu, który chce starego zachowania, w .claude/settings.json (zamień nightly-report na nazwę swojego skilla):

{
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": true
  },
  "permissions": {
    "allow": ["Skill(nightly-report)"]
  }
}

Ustawienia zarządzane: które źródło jest najwyżej

„Najwyżej postawione źródło zarządzane” ma ścisłe znaczenie. Dokumentacja ustawień zarządzanych (otwiera się w nowej karcie) ustawia źródła w tej kolejności: ustawienia zdalne z claude.ai albo z bramy Claude apps, potem polityki MDM lub systemowe (plist w macOS albo klucz rejestru HKLM), potem pliki ustawień zarządzanych (managed-settings.json razem z managed-settings.d/*.json), na końcu rejestr HKCU w Windows. Domyślnie (managedSourcesBehavior: "first-wins") Claude Code bierze najwyższe źródło, które dostarcza choć jeden klucz polityki, a resztę pomija bez ostrzeżenia. autoAllowBashIfSandboxed nie należy do nielicznych kluczy czytanych ze wszystkich źródeł, więc wartość w niższym źródle nic nie da.

W praktyce: jeśli organizacja używa ustawień zarządzanych z serwera, z konsoli claude.ai, i do tego rozsyła managed-settings.json, klucz trzeba wpisać do polityki w konsoli. Jeśli plik jest jedynym źródłem, klucz idzie do pliku: /Library/Application Support/ClaudeCode/managed-settings.json w macOS, /etc/claude-code/managed-settings.json w Linuksie i WSL albo C:\Program Files\ClaudeCode\managed-settings.json w Windows:

{
  "sandbox": {
    "enabled": true,
    "allowUnsandboxedCommands": false,
    "autoAllowBashIfSandboxed": true
  }
}

Potem sprawdź jedną maszynę: /status powinien wskazać zmienione źródło, a wiersz Skipped sources wymienia źródła, które przykryło wyższe. Ustawienie klucza w ustawieniach zarządzanych ma drugi skutek: dokumentacja sandboxa zauważa, że przy sandboxie wymaganym przez administratora pliki repozytorium wciąż mogą ustawić autoAllowBashIfSandboxed, a ustawienie go w ustawieniach zarządzanych nie pozwala repozytorium tego zmienić.

Na co uważać

• Auto-allow to wybór, nie przycisk przywracania. Anthropic uczynił pytanie ustawieniem domyślnym. Jeśli włączasz auto-allow z powrotem, ustaw też allowUnsandboxedCommands: false (tryb strict sandbox w /sandbox). Według dokumentacji sandboxa (otwiera się w nowej karcie) Claude Code ignoruje wtedy ponowną próbę z dangerouslyDisableSandbox, więc polecenie, które zawiedzie w sandboxie, nie uruchomi się po prostu poza nim.
• Brak ostrzeżenia dla poprawki zstd. Na 15 listopada 2026 notatki nie linkują żadnego ostrzeżenia i nie podają CVE, wersji, których błąd dotyczy, ani wagi, więc my też ich nie podajemy. Obserwuj ostrzeżenia bezpieczeństwa (otwiera się w nowej karcie) repozytorium, gdyby jakieś pojawiło się później.
• Stable zostaje w tyle. Zespół na stable ma stare ustawienia domyślne i nie ma poprawek z 2.1.325, dopóki kanał nie przejdzie na 2.1.325 lub nowszą wersję. Wcześniejsze przejście na 2.1.325 oznacza przyjęcie nowych ustawień domyślnych od razu, więc najpierw wykonaj kroki powyżej. Z autoUpdatesChannel: "stable" instalacja natywna cofa się do wersji stable, nawet jeśli twoja jest nowsza, chyba że ustawisz minimumVersion.
• Zwykły Windows nie ma sandboxa. Według dokumentacji sandboxa (otwiera się w nowej karcie) sandbox działa na macOS, Linuksie i WSL2; na zwykłym Windowsie Claude Code uruchamia polecenia bez sandboxa i tak czy inaczej przechodzą one zwykłą ścieżkę uprawnień.
• Mniejsze zmiany dla przebiegów bez nadzoru. Również z notatek 2.1.325, linkowanych wyżej: „Always allow” w Desktop, IDE i hostach SDK proponuje teraz samą regułę tylko wtedy, gdy jej zapisanie znów zezwoli na to polecenie, więc zaplanowane zadanie, które na niej polegało, może teraz czekać na ciebie. claude -p bez zapisanych danych konta czeka teraz na nie przed pierwszym zapytaniem, więc pierwszy przebieg w czystym kontenerze CI może ruszyć kilka sekund później. Przebiegi -p i SDK w worktree albo submodule zamontowanym w kontenerze stosują reguły allow z .claude/settings.local.json dopiero wtedy, gdy folder jest zaufany. Claude Code w przeglądarce, zaplanowane zadania w chmurze i sesje Cowork w chmurze startują teraz mimo sandbox.failIfUnavailable, bo kontener w chmurze nie ma sandboxa poleceń.

Wszystkie źródła przeczytaliśmy 15 listopada 2026. Claude Code wychodzi niemal codziennie, więc przed wdrożeniem sprawdź w changelogu, czy nie ma czegoś nowszego.

Dalsza lektura