Claude Code tryb auto jako ustawienie domyślne

Zmiany w trybie auto od 14 sierpnia 2026

Tryb auto w Claude Code wykonuje wywołania narzędzi bez przerywania pracy w celu uzyskania potwierdzenia, przesyłając każdą akcję do osobnego modelu klasyfikującego w celu wstępnej weryfikacji. Od 14 sierpnia 2026 roku jest to tryb domyślny dla nowych sesji w planach Pro, Max oraz Team. Tryby można zmieniać w dowolnym momencie, a ustawienie domyślne zdefiniowane przez użytkownika nie zostanie nadpisane.

Dokumentacja opisuje tę zmianę w następujący sposób:

Od 14 sierpnia 2026 roku tryb auto staje się domyślnym trybem uprawnień dla nowych sesji w planach Pro, Max oraz Team. Tryby można zmieniać w dowolnym momencie. Ustawienie domyślne zdefiniowane przez użytkownika pozostaje bez zmian, chyba że użytkownik zaakceptuje jednorazowy monit o przełączenie; ustawienia domyślne zarządzane przez organizację również pozostają niezmienione.

Dwa zapisy są istotniejsze niż sama data. defaultMode zdefiniowany w pliku ustawień użytkownika pozostaje aktywny po wprowadzeniu zmiany. Ustawienie domyślne wdrożone przez organizację za pośrednictwem zarządzanych ustawień również pozostaje nienaruszone. Wpis z ogłoszeniem dodaje, że w pierwszej fazie wdrażania tryb auto pozostaje opcjonalny dla planów Enterprise oraz kont korzystających z API.

W przypadku uruchamiania Claude Code na serwerze VPS (virtual private server), warto zapoznać się z tą zmianą przed jej wprowadzeniem. Monit o uprawnienia stanowi punkt kontrolny wymagający obecności użytkownika przy klawiaturze. Na zdalnej maszynie użytkownik często nie jest obecny, więc tryb, w którym sesja się rozpoczyna, jest trybem, w którym pozostaje ona przez wiele godzin.

Tryby uprawnień Claude Code, od największego do najmniejszego stopnia nadzoru

Dostępnych jest sześć trybów. Nazwa na początku każdej linii to wartość wpisywana w ustawieniach lub przekazywana do --permission-mode.

• default: Claude pyta przed każdym użyciem nowego narzędzia. Odczyty wewnątrz katalogu roboczego nadal odbywają się bez pytania. Interfejs CLI (command line interface) oznacza ten tryb jako Manual i od wersji Claude Code v2.1.200 akceptuje manual jako alias.
• plan: Claude odczytuje pliki i uruchamia polecenia w celu eksploracji, ale nie edytuje kodu źródłowego. Edycja pozostaje zablokowana do momentu zatwierdzenia planu.
• acceptEdits: edycja plików odbywa się bez pytania, podobnie jak polecenia systemowe mkdir, touch, rm, rmdir, mv, cp oraz sed. Dotyczy to wyłącznie ścieżek wewnątrz katalogu roboczego lub additionalDirectories. Każde inne polecenie powłoki nadal wymaga potwierdzenia.
• auto: wszystko jest uruchamiane, przy czym klasyfikator sprawdza każdą akcję przed jej wykonaniem. Jawne reguły ask nadal wymuszają monit.
• dontAsk: Claude Code automatycznie odrzuca wszystko, co wymagałoby potwierdzenia. Uruchamiane są tylko reguły allow, wbudowane polecenia Bash typu read-only oraz wywołania zatwierdzone przez hook PreToolUse. Sesja nigdy nie oczekuje na dane wejściowe.
• bypassPermissions: monity i kontrole bezpieczeństwa są pomijane, w tym zapisy do chronionych ścieżek, takich jak .git oraz .claude.

Naciśnij Shift+Tab podczas sesji, aby przełączać się między default, acceptEdits oraz plan. Pasek stanu wskazuje aktualny tryb, na przykład ⏵⏵ auto mode on lub szare ⏸ manual mode on. Pozostałe tryby nie znajdują się domyślnie w tym cyklu. auto dołącza do niego, gdy konto spełni wymagania. bypassPermissions dołącza tylko wtedy, gdy sesja została uruchomiona z --permission-mode bypassPermissions lub --dangerously-skip-permissions. dontAsk nigdy się tam nie pojawia, dlatego należy ustawić go za pomocą claude --permission-mode dontAsk.

Tryb automatyczny wymaga również nowszego modelu, co jest najczęstszą przyczyną jego braku. Według stanu na sierpień 2026 dokumentacja wymienia Claude Opus 4.6 lub nowszy, Sonnet 4.6 lub nowszy oraz Fable 5 w API Anthropic i zaznacza, że starsze modele, takie jak Sonnet 4.5, nie są wspierane u żadnego dostawcy. Jeśli Claude Code zgłasza niedostępność trybu automatycznego, oznacza to, że jeden z tych wymogów nie jest spełniony. Nie jest to tymczasowa awaria, więc czekanie nie rozwiąże problemu.

Dwa mechanizmy kontrolne działają w każdym trybie, w tym w bypassPermissions: reguły deny oraz jawne reguły ask. Są to dźwignie, które pozostają w rękach użytkownika niezależnie od trybu, w jakim rozpoczyna się sesja.

Co blokuje klasyfikator trybu automatycznego

Klasyfikator to drugi model, który analizuje oczekujące działanie i sprawdza, czy jest ono zgodne z żądaniem użytkownika. Dokumentacja opisuje jego zadanie w jednym zdaniu:

Osobny model klasyfikatora weryfikuje działania przed ich uruchomieniem, blokując wszystko, co wykracza poza zakres żądania, dotyczy nierozpoznanej infrastruktury lub wydaje się wynikać z wrogich treści odczytanych przez Claude.

Domyślnie blokowane są kategorie, z którymi administrator serwera spotyka się najczęściej:

• Pobieranie i wykonywanie kodu, na przykład curl | bash
• Wdrożenia produkcyjne i migracje
• Force push
• Modyfikowanie współdzielonej infrastruktury
• Otwieranie tunelu lub reverse shell, które udostępniają usługę lokalną w publicznym Internecie
• Wypisywanie aktywnego poświadczenia lub tokena w transkrypcji lub pliku

Domyślnie dozwolone są:

• Operacje na plikach lokalnych w katalogu roboczym
• Instalowanie zależności zadeklarowanych w plikach blokad lub manifestach
• Żądania HTTP typu read-only
• Wypychanie zmian do dowolnej gałęzi repozytorium, w którym trwa praca

Nie należy opierać się wyłącznie na powyższym podsumowaniu. Uruchom claude auto-mode defaults, aby wyświetlić pełne listy reguł w formacie JSON i zapoznać się z zestawem dostarczonym wraz z zainstalowaną wersją.

Przed rozpoczęciem pracy należy uwzględnić dwa udokumentowane ograniczenia. Po pierwsze, klasyfikator widzi wiadomości, wywołania narzędzi oraz zawartość CLAUDE.md, natomiast wyniki narzędzi są usuwane, więc tekst wewnątrz pliku lub strony internetowej odczytanej przez Claude nie może bezpośrednio wpłynąć na klasyfikator. Po drugie, gdy klasyfikator zablokuje działanie 3 razy z rzędu lub 20 razy w jednej sesji, tryb automatyczny zostaje wstrzymany, a Claude Code powraca do trybu zapytań. Te progi nie podlegają konfiguracji. W trybie nieinteraktywnym z flagą -p nie ma użytkownika, który mógłby odpowiedzieć na zapytanie, więc powtarzające się blokady powodują przerwanie sesji.

To drugie zachowanie jest szczególnie problematyczne w przypadku pracy na zdalnej maszynie. Uruchomienie bez nadzoru, które przekroczy limit, zatrzyma się i będzie oczekiwać na osobę, która nie obserwuje terminala. Ograniczenie zakresu działań agenta stanowi drugą część rozwiązania, a umiejętność kierowania agenta ku najmniejszej działającej zmianie zapobiega sytuacji, w której sesja zmierza w stronę rozległych działań blokowanych przez klasyfikator.

Gdzie znajdują się tryby w pliku settings.json

Wszystkie powyższe elementy stanowią jeden obiekt w pliku ustawień.

{
  "permissions": {
    "defaultMode": "auto",
    "allow": [
      "Bash(npm run test *)",
      "Bash(git status)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(docker compose up *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)",
      "Bash(curl *)"
    ]
  }
}

Reguły są oceniane w kolejności: odmowa (deny), następnie pytanie (ask), a na końcu zezwolenie (allow). Pierwsze dopasowanie w tej kolejności decyduje o wyniku, a węższa reguła nie ma pierwszeństwa przed szerszą, która występuje wcześniej. Reguła odmowy dla Bash(aws *) blokuje aws s3 ls nawet wtedy, gdy jednocześnie zezwolono na to konkretne polecenie, zatem reguła odmowy nie może zawierać wyjątków.

ask to typ reguły, który sprawdza się w trybie auto. Tryb auto eliminuje rutynowe monity, a reguła ask przywraca je dla konkretnego polecenia, w przypadku którego wymagana jest interakcja użytkownika. Twoje polecenie wdrożeniowe powinno się tam znaleźć. Podobnie Bash(git push *), jeśli chcesz utworzyć punkt kontrolny przed opuszczeniem środowiska przez kod. Przechowywanie plików z danymi uwierzytelniającymi w deny stanowi drugą połowę tego rozwiązania i łączy się z utrzymywaniem danych uwierzytelniających poza zasięgiem agenta.

Same pliki ustawień, od najniższego priorytetu:

• ~/.claude/settings.json: ustawienia użytkownika, stosowane w każdym projekcie.
• .claude/settings.json: ustawienia projektu, zatwierdzane w repozytorium.
• .claude/settings.local.json: własne ustawienia dla pojedynczego repozytorium, ignorowane przez git.
• Ustawienia zarządzane, wdrażane przez administratora. W systemie Linux plik ten to /etc/claude-code/managed-settings.json. Nic nie nadpisuje reguły uprawnień zarządzanych, w tym flaga wiersza poleceń.

Jedna pułapka w tym miejscu ma udokumentowaną przyczynę. defaultMode: "auto" jest ignorowane, jeśli pochodzi z .claude/settings.json lub .claude/settings.local.json, począwszy od wersji Claude Code v2.1.142, aby repozytorium nie mogło samodzielnie przyznać sobie trybu auto poprzez dołączenie pliku ustawień. Ustawienie go tam spowoduje uruchomienie sesji w trybie default bez wyświetlenia żadnego błędu. Przenieś tę linię do ~/.claude/settings.json. Uruchom /permissions, aby wyświetlić listę wszystkich aktywnych reguł wraz z plikiem, z którego pochodzą.

Dwa przełączniki wyłączające tryb

Administratorzy mają do dyspozycji dwa wyłączniki bezpieczeństwa, z których oba przyjmują ciąg znaków "disable" zamiast wartości logicznej.

{
  "permissions": {
    "disableAutoMode": "disable",
    "disableBypassPermissionsMode": "disable"
  }
}

Dokumentacja precyzyjnie określa miejsce ich umieszczenia:

Aby zapobiec użyciu trybu bypassPermissions lub auto, należy ustawić permissions.disableBypassPermissionsMode lub permissions.disableAutoMode na "disable" w dowolnym pliku ustawień. Jest to najbardziej przydatne w środowiskach zarządzanych, gdzie ustawienia te nie mogą zostać nadpisane.

disableAutoMode usuwa auto z cyklu Shift+Tab i odrzuca --permission-mode auto podczas uruchamiania. disableBypassPermissionsMode wykonuje to samo zadanie dla trybu bypass i działa z dowolnego zakresu, więc można ustawić to w swoim własnym ~/.claude/settings.json, aby zablokować sobie dostęp do trybu, którego wolelibyśmy nie używać o godzinie 2 nad ranem na serwerze produkcyjnym. Na maszynie używanej przez inne osoby należy umieścić oba wpisy w /etc/claude-code/managed-settings.json, ponieważ plik ustawień użytkownika należy do użytkownika, a plik zarządzany nie.

Dlaczego tryb automatyczny na serwerze VPS wymaga izolacji

Klasyfikator analizuje działania pojedynczo. Nie zawiera on informacji o tym, co wykonuje zatwierdzone działanie. Dokumentacja jasno wyznacza granicę:

Klasyfikator jest mechanizmem kontroli poszczególnych działań, a nie barierą izolacji, dlatego bariera izolacji nadal stanowi dodatkową warstwę ochrony w przypadku uruchomień bez nadzoru i nie jest wymagana w taki sam sposób, jak w przypadku --dangerously-skip-permissions.

Zatem połączenie dla zdalnej maszyny to tryb automatyczny oraz środowisko, którego utrata jest akceptowalna, a nie bypassPermissions i nadzieja. Tryb obejścia (bypass mode) jest udokumentowany wyłącznie dla środowisk izolowanych: kontenerów, maszyn wirtualnych lub kontenerów deweloperskich bez dostępu do Internetu, w których Claude Code nie może uszkodzić systemu hosta. Serwer VPS obsługujący bazę danych i reverse proxy nie spełnia tych warunków.

Trzy elementy mają kluczowe znaczenie dla bezpieczeństwa serwera. Uruchamiaj Claude Code jako zwykły użytkownik, nigdy jako root. Nadaj temu użytkownikowi katalog roboczy i nie zapewniaj dostępu do żadnych innych istotnych danych. Zamiast naprawiać serwer, należy go odtworzyć, co stanowi argument za maszyną wirtualną jednorazowego użytku, którą usuwa się po każdym zadaniu. Szczegóły dotyczące utwardzania systemu, od tworzenia użytkownika po reguły zapory sieciowej, zostały opisane w pełnym przewodniku bezpieczeństwa dla uruchamiania Claude Code na VPS, dlatego nie są tutaj powtarzane.

Claude Code samodzielnie wymusza zasadę dotyczącą konta root. W systemach Linux i macOS narzędzie odmawia uruchomienia w trybie obejścia pod użytkownikiem sudo lub jako root:

--dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons

Ta kontrola jest pomijana wewnątrz rozpoznanego środowiska typu sandbox, dlatego udokumentowanym rozwiązaniem dla autonomicznej pracy w kontenerach jest kontener deweloperski, w którym Claude Code działa jako użytkownik bez uprawnień roota. Jeśli sterujesz agentem z telefonu lub laptopa przez SSH, to samo rozumowanie odnosi się do długotrwałej sesji Claude Code utrzymywanej w tmux: nikt nie monitoruje promptu podczas działania sesji.

Konfiguracja piaskownicy Bash na serwerze Ubuntu VPS

Wbudowana piaskownica ogranicza dostęp do systemu plików i sieci dla każdego polecenia Bash wykonywanego przez Claude, a system operacyjny wymusza te same ograniczenia na procesach potomnych. W systemie Linux wymagane są dwa pakiety.

sudo apt-get install bubblewrap socat

Uruchom Claude Code i wykonaj /sandbox. Panel otworzy się z kartami Mode oraz Overrides, a także kartą Dependencies, która wyświetla brakujące zależności. Sprawdzanie zależności odbywa się podczas uruchamiania, więc po zainstalowaniu pakietów należy zrestartować Claude Code, w przeciwnym razie panel nadal będzie wskazywał ich brak.

W systemie Ubuntu 24.04 i nowszych domyślna polityka AppArmor uniemożliwia narzędziu bubblewrap tworzenie wymaganych przestrzeni nazw użytkownika (user namespaces), co powoduje niepowodzenie uruchomienia piaskownicy. Sprawdź, czy ten problem dotyczy Twojego systemu:

sysctl kernel.apparmor_restrict_unprivileged_userns

Wynik 0 lub błąd informujący o braku klucza oznacza, że nie trzeba podejmować żadnych działań. Wynik 1 oznacza, że bwrap wymaga własnego profilu:

sudo tee /etc/apparmor.d/bwrap > /dev/null <<'EOF'
abi <abi/4.0>,
include <tunables/global>

profile bwrap /usr/bin/bwrap flags=(unconfined) {
  userns,
  include if exists <local/bwrap>
}
EOF
sudo systemctl reload apparmor

Profil dotyczy samego bwrap, a nie poleceń wykonywanych wewnątrz piaskownicy. Następnie należy zawęzić zakres w ustawieniach:

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "denyRead": ["~/"],
      "allowRead": ["."]
    },
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"]
    }
  }
}

Ten blok powinien znaleźć się w pliku .claude/settings.json projektu, ponieważ . odnosi się do katalogu głównego projektu tylko z poziomu ustawień projektu. Umieszczenie tych samych linii w ~/.claude/settings.json spowoduje, że . zostanie rozwiązane do ~/.claude, przez co reguła denyRead zablokuje dostęp do plików projektu, a każde polecenie nie będzie mogło odczytać kodu, który ma edytować.

Należy pamiętać, czego to rozwiązanie nie obejmuje. Piaskownica ogranicza Bash oraz jego procesy potomne. Wbudowane narzędzia do obsługi plików działają wewnątrz procesu Claude Code, natomiast serwery MCP (model context protocol) oraz hooki są oddzielnymi procesami działającymi bez ograniczeń na hoście. Aby objąć je wszystkie jedną granicą bezpieczeństwa, należy uruchomić cały proces Claude Code wewnątrz kontenera, maszyny wirtualnej lub pakietu @anthropic-ai/sandbox-runtime, który w momencie pisania tego tekstu jest wersją beta (research preview).

Jaki tryb wybrać dla danej konfiguracji?

Samodzielne repozytorium na własnym laptopie

Użyj auto wraz z regułami ask dla akcji, które mają być monitorowane. Znajdujesz się przy klawiaturze, klasyfikator awaryjny może nawiązać z Tobą kontakt, a potencjalne szkody są ograniczone do jednej maszyny, którą kontrolujesz. Jest to scenariusz, dla którego stworzono ustawienie domyślne z 14 sierpnia.

Współdzielony serwer VPS

Użyj auto dla każdego użytkownika, skonfigurowanego w jego własnym pliku ~/.claude/settings.json, na maszynie, gdzie konto uruchamiające Claude Code nie posiada uprawnień root i nie ma dostępu do plików innych użytkowników. Wdróż disableBypassPermissionsMode jako "disable" w /etc/claude-code/managed-settings.json, wraz z regułami odmowy chroniącymi współdzielone ścieżki. Współdzielony serwer to najbardziej oczywisty przypadek, w którym bypassPermissions jest niewłaściwe, ponieważ granica izolacji zakładana przez ten tryb nie istnieje: inni użytkownicy znajdują się wewnątrz niej.

CI i sesje bez nadzoru

Użyj dontAsk z jawną listą allow poleceń wymaganych przez zadanie. Automatyczna odmowa jest właściwym trybem awaryjnym, gdy żaden człowiek nie będzie widział monitu. Tryb automatyczny również działa w sposób nieinteraktywny, jednak powtarzające się blokady klasyfikatora przerywają sesję -p, co powoduje, że zadanie kończy się niepowodzeniem w trakcie pracy, pozostawiając ją częściowo wykonaną. Używaj bypassPermissions wyłącznie w kontenerze lub maszynie wirtualnej, którą odtwarzasz z obrazu, i nigdy na hoście, na którym uruchomione są ważne dla Ciebie usługi.

FAQ

Kiedy tryb auto stanie się domyślnym w Claude Code?

Od 14 sierpnia 2026 r. dla nowych sesji w planach Pro, Max oraz Team. Dokumentacja dodaje, że tryby można zmieniać w dowolnym momencie, samodzielnie ustawiona wartość domyślna pozostaje aktywna, dopóki użytkownik nie zaakceptuje jednorazowego monitu o zmianę, a ustawienia domyślne zarządzane przez organizację pozostają bez zmian. Ogłoszenie wskazuje, że tryb auto pozostaje opcjonalny dla planów Enterprise oraz dla kont korzystających z API w pierwszej fazie wdrażania. Bieżący tryb sesji można sprawdzić na pasku stanu, który w trybie auto wyświetla ⏵⏵ auto mode on.

Czy na serwerze VPS należy używać trybu auto czy bypassPermissions?

Trybu auto, w połączeniu z izolacją. Klasyfikator weryfikuje każdą akcję przed jej wykonaniem, jednak dokumentacja wyraźnie zaznacza, że jest to kontrola poszczególnych działań, a nie mechanizm izolacji. Dlatego uruchomienie bez nadzoru nadal wymaga kontenera, maszyny wirtualnej lub środowiska, które można w razie potrzeby odtworzyć. Flaga bypassPermissions całkowicie pomija kontrole i jest przeznaczona wyłącznie do odizolowanych środowisk. Claude Code odmawia uruchomienia w tym trybie z uprawnieniami root w systemie Linux i wyświetla komunikat --dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons.

Jak zablokować możliwość korzystania z trybu auto lub trybu bypass na serwerze?

Należy ustawić permissions.disableAutoMode oraz permissions.disableBypassPermissionsMode na wartość "disable" w pliku /etc/claude-code/managed-settings.json. Ustawienia zarządzane mają priorytet nad wszystkimi innymi zakresami, więc żaden plik ustawień użytkownika ani flaga wiersza poleceń nie mogą ich nadpisać. Opcja disableAutoMode usuwa auto z cyklu Shift+Tab i odrzuca --permission-mode auto podczas uruchamiania. Ustawienie disableBypassPermissionsMode działa również z dowolnego zakresu, więc pojedynczy użytkownik może je zdefiniować we własnym pliku ~/.claude/settings.json.

Dlaczego moje ustawienie defaultMode: "auto" jest ignorowane?

Ponieważ znajduje się w niewłaściwym pliku. Od wersji Claude Code v2.1.142 ustawienie defaultMode: "auto" jest ignorowane, jeśli pochodzi z .claude/settings.json lub .claude/settings.local.json, co zapobiega sytuacji, w której repozytorium mogłoby samodzielnie przyznać sobie tryb auto poprzez dołączenie pliku ustawień. Sesja uruchamia się w trybie default bez wyświetlania błędu. Należy przenieść ustawienie do ~/.claude/settings.json, a następnie wykonać /permissions, aby sprawdzić, z którego pliku pochodzi każda z aktywnych reguł. Jeśli tryb auto nadal jest niedostępny, należy sprawdzić wymagania dotyczące modelu: starsze modele, takie jak Sonnet 4.5, nie są obsługiwane u żadnego dostawcy.