# Az AI törölte az adatbázist: 7 perces helyreállítási terv > Teendők adattörlés után: állítsa le az ügynököt, dokumentálja az incidenst, használja a git reflogot, a PITR-t, a pillanatképeket és a fájl-helyreállítást. Példák és védelmi intézkedések. Source: https://ailoot.ai/blog/hu/ai-deleted-database-recovery/ Canonical: https://ailoot.ai/blog/hu/ai-deleted-database-recovery/ Language: hu Publisher: Ailoot (https://ailoot.ai/) Translation: guide-032 Revision: sha256-0877395c3e6217d2ff0eb4c965a4fe0657de8575a66569f1595144bcd9968af6
Fő tanulságok Egy AI-ügynök éppen most törölte az adatbázisát, a fájljait vagy a teljes éles környezetét. Az első 7 perc dönti el, hogy helyre tudja-e állítani az adatait, vagy örökre elveszíti őket. Ez az útmutató minden perchez konkrét parancsokat ad. Először állítsa le az ügynököt, majd dokumentálja az incidenst, végül végezze el a helyreállítást. Ne essen pánikba—kövesse az ellenőrzőlistát.
[Az Ailoot használatával kapcsolatos gyakorlati információk a dokumentációban találhatók](https://ailoot.ai/docs/). ## Teendők az első percben: ÁLLJON MEG, ne essen pánikba
Fő tanulságok Azonnal állítsa le a romboló írót, az ügynök leállása után tovább futó gyermekfolyamatát is. Ne indítsa újra a gépet, és ne állítson le független folyamatokat, amelyek törölt fájlokat tarthatnak nyitva. A visszaállíthatóság nem garantált: felülírás és SSD discard/TRIM lehetetlenné teheti. A sérült példány módosítása előtt külön ellenőrzött eszközön őrizze meg a bizonyítékot és fennmaradt adatokat.
Ha ez történik Önnel, **az első teendő az ügynök leállítása**. Ne próbálja saját maga visszavonni a műveleteit, ne kérje tőle, hogy „állítson helyre mindent”, és ne futtasson új promptokat. Az ügynök minden további művelete felülírhatja azokat a lemezblokkokat, ahol az adatai még tárolódhatnak. 1. ### Zárja be az ügynök terminálját A veszélyes parancsot azonnal szakítsa meg Ctrl+C-vel; ne várja meg a törlés végét. Az ügynök leállása nem feltétlenül állítja le gyermekparancsait, távoli feladatait vagy adatbázis-lekérdezését. Azonosítsa a tényleges írót, és azt állítsa le vagy szakítsa meg; folytatódó adatrombolásnál fokozza a leállítást. A visszanyerhető fájlt nyitva tartó független folyamatokat hagyja életben. 2. ### NE indítsa újra a laptopját Törölt adat visszanyerhető maradhat, de ezt a tároló, adatbázis-működés, SSD discard/TRIM és későbbi írás határozza meg. Minimalizálja az érintett kötet írásait; ne feltételezze a bájtok megmaradását. 3. ### NE zárja be a nyitott folyamatokat Őrizze meg a törölt fájlt nyitva tartó független folyamatokat, mert fájlleíróikon át lehetséges lehet a visszanyerés. Ez a romboló íróra nem vonatkozik: azt előbb állítsa le. Nyitott fájlleíró kedvéért ne hagyjon tovább futni törlést. 4. ### Indítson képernyőfelvételt Rögzítse a pontos időt, érintett útvonalakat és látható parancskimenetet. Felvételt vagy másolt naplót külön ellenőrzött eszközre mentsen, ne a sérült kötetre. Helyreállítás előtt ott őrizze meg a fennmaradt követett, nem követett, kizárt fájlokat és Git-metaadatokat. Ezután 6 perc áll rendelkezésére a helyreállításhoz. Lássunk hozzá. ## 2–3. perc: dokumentálja pontosan, mi történt
Fő tanulságok A helyreállítás előtt végezzen diagnózist. Ha nem tudja pontosan, „mit, ki, mikor és milyen parancsokkal törölt”, vaktában fogja végezni a helyreállítást, és az ép adatokat is tönkreteheti. Nyisson egy új terminálablakot (ne azt, amelyikben az ügynök fut), majd futtassa a `git status`, `git log --since` és `ps aux | grep claude` parancsokat. Azonnal másolja le a `~/.claude/projects/` mappát—ez tartalmazza az ügynök teljes munkamenetnaplóját, amely segíthet a helyreállításban.
Nyisson egy új terminálablakot. Ne azt, amelyikben az ügynök fut—egy másikat. Futtassa egymás után ezt a három parancsot. **1. Rögzítse pontosan, mi változott a git-tárolóban:** ```bash git status git log --since="30 minutes ago" --all --oneline ``` Törölt követett fájl még létezhet az indexben vagy commitban. Bármilyen restore előtt őrizze meg a jelenlegi munkafát, a nem követett és kizárt fájlokkal együtt; a helyben visszaállítás felülírhat megmaradt szerkesztéseket. Külön másolatban vizsgáljon és nyerjen vissza. **2. Ellenőrizze, mely ügynökfolyamatok futnak:** ```bash ps aux | grep -i claude ps aux | grep -i cursor ``` Azonosítsa a veszélyes írást ténylegesen végző folyamatot; névegyezés nem elég. Azt állítsa le, és igazolja a leállást. Hasznos nyitott fájlt tartó független folyamatot őrizzen meg; sikertelen kíméletes leállítás és folytatódó rombolás esetén kényszerített leállítás is szükséges lehet. **3. Mentse el az ügynök munkamenetnaplóját:** A Claude Code a JSONL-munkameneteket a `~/.claude/projects/` mappában tárolja. A Cursor a `~/.cursor/` mappában tárolja őket. Készítsen másolatot **most azonnal**: ```bash cp -r ~/.claude/projects /external/incident-evidence/claude-projects ``` A `/external/incident-evidence/` helyett külön ellenőrzött, csatolt eszköz meglévő bizonyítékkönyvtárát adja meg. Ne az érintett kötetre mentsen, és ne írjon felül meglévő bizonyítékot. Ez a mappa az ügynökkel folytatott szó szerinti beszélgetést tartalmazza—milyen parancsokat futtatott, mit válaszolt és milyen sorrendben. Ez az incidens kivizsgálásának fő forrása, és a kontextus alapján a törölt fájlok helyreállításában is segíthet (lásd a 4. lépést). ## 4. perc: git reflog—a legjobb esélye
Fő tanulságok A reflog megkereshet ág-előzményből eltűnt commitokat, de nem menti a nem commitolt munkafájlokat. A fennmaradt adat és Git-metaadat külön eszközre mentése után a másolt tárolót vizsgálja, és igazolt commitot külön worktree-be nyerjen vissza. Soha ne a sérült munkafa resetelésével kezdjen.
A `git reflog` a helyi hivatkozásmozgásokat rögzíti, amíg a bejegyzések megmaradnak. A lejárat és törlés változó, az elérhetetlen objektumok eltávolíthatók; nem minden korábbi commit garantált archívuma. Az alábbi visszanyerést a külön eszközön őrzött tárolómásolatból futtassa. **1. lépés. Tekintse meg a naplót:** ```bash git reflog --all ``` Ehhez hasonló listát fog kapni: ``` 1a2b3c4 HEAD@{0}: reset: moving to HEAD~3 9z8y7x6 HEAD@{1}: commit: working version of the dashboard 5w4v3u2 HEAD@{2}: commit: added admin panel ``` Keresse meg azt az állapotot, amely **megelőzte** az ügynök által okozott kárt. Minden bejegyzés a tároló akkori állapotának „pillanatképe”. **2. lépés. Visszanyerés külön munkafába:** A tároló és minden megmaradt munka külön eszközre másolása után ezt az őrzött tárolómásolatból futtassa. Az értéket a reflogban ellenőrzött pontos commit-SHA-ra cserélje, és még nem használt ágat és célhelyet válasszon: ```bash RECOVERY_COMMIT='replace-with-verified-commit-sha' git worktree add -b recovery-check ../recovery-check "$RECOVERY_COMMIT" ``` Nézze át a `../recovery-check` visszanyert fájljait, és bármi visszamásolása előtt vesse össze a megőrzött nem commitolt fájlokkal. A parancs külön választja ki a commitot, nem reseteli a sérült munkafát. A kapcsolt worktree-k a másolt tároló Git-objektumtárát használják közösen, ezért ez helyreállítási munkatér, nem független mentés. Lásd a [hivatalos git-worktree dokumentációt](https://git-scm.com/docs/git-worktree). **Ha a reflogot is törölték (az ügynöknek sikerült futtatnia a `git gc` parancsot):** ```bash git fsck --lost-found ``` Ez a parancs megkeresi azokat az „elveszett” commitokat és blobokat (fájlobjektumokat), amelyek már egyetlen ághoz sem kapcsolódnak. Ezek a `.git/lost-found/commit/` és `.git/lost-found/other/` mappában jelennek meg. Fájl helyreállításához onnan: ```bash git cat-file -p > recovered-file.ext ``` **Amikor a git reflog NEM segít:** - A fájl csak a working tree-ben volt, commit vagy stash nélkül → a reflog nem látja - Több mint 90 nap telt el (a szabványos `gc.reflogExpire` érték), és lefutott a `git gc` - A teljes tárolót törölték (`rm -rf .git`)—ekkor Time Machine-re vagy pillanatképre lesz szüksége ## 5. perc: állítsa vissza az adatbázist biztonsági másolatból
Fő tanulságok A PostgreSQL Point-In-Time Recovery (PITR) az adatbázist egy 7–35 napos időablak bármelyik másodpercére visszaállítja. Működik a Yandex Cloud Managed Postgres, az AWS RDS és a Supabase Pro esetén, valamint a Coolify helyi `pg_dump` cronfeladatával. A legfontosabb feltétel, hogy a PITR-t **az incidens előtt** engedélyezni kellett; utólag nem kapcsolható be. Mindig új példányra állítsa vissza az adatbázist, soha ne egy élő adatbázisra, nehogy a visszaállítás még több adatot semmisítsen meg. Ha a PITR nem volt engedélyezve, használja a legutóbbi pillanatképet.
Az adatbázist a `DROP DATABASE`, `DROP TABLE` vagy `DELETE FROM ... WHERE ...` paranccsal törölték (WHERE záradék nélkül). Mit tegyen? **1. lépés. Nézze meg, kínál-e a szolgáltatója PITR-t:** | Szolgáltató | PITR-időablak | Visszaállítási parancs | |----|----|----| | AWS RDS | 1–35 nap (konfigurálható) | `aws rds restore-db-instance-to-point-in-time --restore-time 2026-05-28T14:30:00Z` | | Yandex Cloud Managed Postgres | 7 nap (alapértelmezés szerint) | Visszaállítás biztonsági másolatból a konzolban + az időpont megadása | | Supabase Pro | 7 nap (csak Pro+) | UI: Database → Backups → Restore | | Coolify + helyi pg_dump | A cron ütemezése szerint | `pg_restore -d new_db backup.dump` | **2. lépés. Új példányra állítsa vissza, ne a régire:** Soha ne állítson vissza élő adatbázisra. Hozzon létre új példányt a biztonsági másolatból, majd állítsa át rá az alkalmazást. Ha valami rosszul sül el, visszaállíthatja a DNS-t. **3. lépés. Ha a PITR nem volt engedélyezve, használja a legutóbbi pillanatképet:** ```bash # AWS RDS, pillanatképek listázása: aws rds describe-db-snapshots --db-instance-identifier my-db # Visszaállítás pillanatképből: aws rds restore-db-instance-from-db-snapshot \ --db-instance-identifier my-db-restored \ --db-snapshot-identifier rds:my-db-2026-05-28-12-00 ``` **Fontos tudnivaló a Supabase-ről**, amely 2026-ban sokakat meglepett: ha a PITR engedélyezve van, a napi biztonsági másolatok **készítése leáll**. Ez ellentmond a várakozásoknak; előfordulhat, hogy egyáltalán nem marad biztonsági másolata. Ellenőrizze a Dashboard → Database → Backups részt, hogy a PITR aktív-e, ÉS van-e visszaállítható pillanatképe. ## 6. perc: Time Machine, lsof és lemezpillanatképek
Fő tanulságok Ha fájlokat töröltek a lemezről—nem a gitből vagy az adatbázisból—három gyakorlati helyreállítási módszer áll rendelkezésére. macOS-en használja a Time Machine óránkénti pillanatképeit (ha a laptop Time Capsule-hoz vagy külső meghajtóhoz volt csatlakoztatva). Linuxon futtassa a `sudo lsof | grep deleted` parancsot—ezzel visszanyerhetők azok a fájlok, amelyeket egy folyamat még nyitva tart (95% esély); másolja át őket a `/proc/PID/fd/N` útvonalon keresztül. Kritikus esetekben készítsen pillanatképet a teljes partícióról a `dd` paranccsal, majd állítsa helyre az adatokat az `extundelete` vagy a `photorec` segítségével.
**macOS—Time Machine:** ```bash # Pillanatképek listázása: tmutil listbackups # Fájl visszaállítása a legutóbbi biztonsági másolatból: tmutil restore /Volumes/Backup/.../my-project/file.tsx ~/projects/my-project/file.tsx ``` A Time Machine óránként készít pillanatképeket, egy napig megőrzi az óránkéntieket, egy hétig a naponta készülőket, a hetieket pedig határozatlan ideig. Ha laptopja Time Capsule-hoz vagy külső meghajtóhoz csatlakozik, a projekt óránkénti részletességgel rendelkezésre áll. **Linux—a fájlt törölték, de egy folyamat még nyitva tartja:** ```bash # Az összes olyan „törölt” fájl megkeresése, amelyet még nyitva tart egy folyamat: sudo lsof | grep deleted # Ilyen sorokat fog látni: # node 12345 user 24w REG 8,1 4096 1234567 /path/to/deleted/file.txt (deleted) # A fájl közvetlen másolása a /proc/PID/fd/N útvonalról: sudo cp /proc/12345/fd/24 ~/recovered-file.txt ``` Ha a folyamatot nem zárták be, a siker esélye ~95%. ext4, xfs és btrfs fájlrendszereken működik. **macOS—az `lsof` megfelelője:** ```bash lsof | grep deleted ``` A fájl másolása nehezebb (nincs `/proc/`), de az `lldb` segítségével megteheti: ```bash lldb -p 12345 (lldb) memory read --outfile recovered.txt --binary 0xADDRESS 0xSIZE ``` **A teljes lemez pillanatképe (Linux, végső megoldás):** ```bash sudo dd if=/dev/sda1 of=/external/disk-image.img bs=4M status=progress ``` Ez a teljes partíciót lemezképként menti el. Ezután állítsa helyre az adatokat az `extundelete` vagy a `photorec` segítségével. A helyreállítás esélye attól függ, mennyi adatot írtak a lemezre a törlés óta. Ha azóta semmit sem írtak rá, az esély 80–90%. Ha a rendszer már egy órája fut, az esély 20–30%. ## 7. perc: mi van, ha nincs biztonsági másolat
Fő tanulságok Nincs biztonsági másolat, üres a git reflog, és a lemezt már felülírták új adatokkal. Két végső lehetőség marad: vegye fel a kapcsolatot a szolgáltató támogatásával (az AWS, a Yandex Cloud és a Google Cloud időnként visszaállít adatokat a belső tárhelyéről), vagy állítsa vissza az adatokat az S3-verziókezeléssel (ha engedélyezve volt, minden verzió fizikailag megvan).
**1. lehetőség—a szolgáltató támogatása:** Az AWS, a Yandex Cloud, a Google Cloud és a DigitalOcean időnként visszaállít adatokat a belső tárhelyéről, ügyféloldali katasztrófa után is, különösen a fizetős csomagoknál. Nyisson támogatási jegyet, adja meg az incidens pontos időpontját, és mellékeljen képernyőképeket az állapotról. Ez leggyakrabban azoknál a nagy szolgáltatóknál működik, amelyek a saját oldalukon automatikus biztonsági másolatokat őriznek. Az esély 40–60%; a válaszra 24–72 órát kell várni. **2. lehetőség—S3-verziókezelés:** Ha a fájlok az S3-ban (vagy a Yandex Object Storage-ban) voltak, és a verziókezelés engedélyezve volt, minden verzió **fizikailag létezik**; csupán „töröltként” van megjelölve. ```bash # AWS—verziók listázása: aws s3api list-object-versions --bucket my-bucket --prefix files/ # Egy verzió visszaállítása: aws s3api copy-object \ --bucket my-bucket \ --copy-source my-bucket/files/data.json?versionId=ABC123 \ --key files/data.json ``` **Kritikus tudnivaló:** a Claude Code nem őrzi meg örökké a munkameneteket—a régi JSONL-fájlok néhány hét után automatikusan törlődnek. Ha katasztrófa esetére egy hónapnyi JSONL-előzményt szeretne megőrizni, hetente egyszer másolja a `~/.claude/projects/` mappát egy külső meghajtóra egy egyszerű cronfeladattal: ```bash # A crontabban, minden vasárnap 03:00-kor: 0 3 * * 0 rsync -av ~/.claude/projects/ /external/claude-history-backup/ ``` Ingyenes, és megmenti, amikor „minden elveszett, nincs biztonsági másolat, és a reflog is üres”. ## 7 szabály, hogy ez soha többé ne történjen meg
Fő tanulságok Hét szabály, amelyek megakadályozzák, hogy egy AI-ügynök törölje az adatbázisát vagy a kódját. Destruktív műveletek előtt használja a Plan Mode-ot. Tesztelt hookokkal kiválasztott veszélyes parancsszövegeket észleljen kikényszerített jogosultságkorlátok mellett. Adjon az ügynöknek csak olvasási jogosultságú adatbázis-felhasználót. Minden fájlmódosítás után automatikusan készítsen commitot. Kísérletekhez használjon elkülönített sandboxmappát. Készítsen lemez-pillanatképeket a `restic` segítségével óránként. Archiválja a JSONL-munkameneteket külső meghajtóra.
**1. Plan Mode minden destruktív művelet előtt.** A Claude Code-ban: ```bash claude --plan ``` Az ügynök **mielőtt** cselekedne, tervet készít. Elolvassa, meglátja benne a `DROP TABLE users` parancsot, és megszakítja. Plan Mode nélkül az ügynök maga dönt, és milliszekundumok alatt végrehajtja a műveletet. További információ a [Plan Mode a Claude Code-ban útmutatóban](https://ailoot.ai/blog/hu/claude-code-plan-mode/). **2. Hookok kiegészítő jelzőként.** Tesztelt PreToolUse hookot használjon, amely stdinről olvassa az esemény JSON-ját, és észlelt kockázatos műveletnél 2-vel lép ki. Az alábbi teljes példa Bash, Write és Edit eszközöket fed; nem biztonsági határ, és közvetett műveleteket kihagyhat. Az adatbázisjogok és sandbox maradjanak korlátozottak. **3. Csak olvasási jogosultságú DB-felhasználó az ügynöknek.** Hozzon létre külön felhasználót az ügynök számára, akinek **nincs** `DROP`, `TRUNCATE` vagy `DELETE` jogosultsága: ```sql CREATE USER claude_readonly WITH PASSWORD 'xxx'; GRANT CONNECT ON DATABASE myapp TO claude_readonly; GRANT USAGE ON SCHEMA public TO claude_readonly; GRANT SELECT ON ALL TABLES IN SCHEMA public TO claude_readonly; ``` Ha az ügynöknek valóban írnia kell, manuálisan váltson egy másik felhasználóra. A csak olvasási jogosultságú felhasználó elegendő a mindennapi feladatokhoz (adatelemzés, jelentések, irányítópultok). **4. Az ellenőrzött változtatásokat mentse Gitbe.** A `.claude/settings.json` fájlban egy `PostToolUse` hook emlékeztetőt írhat ki a `Write` és `Edit` műveletek után: ```json { "hooks": { "PostToolUse": [ { "matcher": "Write|Edit", "hooks": [ { "type": "command", "command": "printf '%s\\n' 'Ellenőrizze a diffet, és kézzel csak a megbeszélt fájlokat commitolja.' >&2" } ] } ] } } ``` Ez a példa csak emlékeztetőt ír ki; nem ad fájlokat az indexhez, és nem készít commitot. Ellenőrizze a diffet, és kézzel csak a megbeszélt fájlokat commitolja. A reflog nem menti a commitba nem került változtatásokat. **5. Sandboxprojekt a kísérletekhez.** Ne engedje, hogy az ügynök olyan projektben dolgozzon, amely valódi ügyféladatokat tartalmaz. Hozzon létre külön `~/sandbox-projects/` mappát a projekt másolatával és szintetikus adatokkal. Itt próbáljon ki új promptot, ügynököt vagy MCP-szervert. Ha valami elromlik, nem történik baj. **6. Lemez-pillanatképek a `restic` segítségével óránként.** ```bash # Telepítés: brew install restic # macOS sudo apt install restic # Linux # Tároló létrehozása: restic init --repo /external/backups # Az aktuális projekt biztonsági mentése: restic --repo /external/backups backup ~/projects # Óránkénti cronfeladat ütemezése: crontab -e # Adja hozzá: 0 * * * * restic --repo /external/backups backup ~/projects ``` Hét napnyi óránkénti és négy hétig napi biztonsági másolat—így bármikor visszaállhat egy korábbi állapotra. Ingyenes, és 10 perc alatt beállítható. **7. Archiválja a Claude Code JSONL-munkameneteket.** Már említettük fent, de külön szabályként is megismételjük: ütemezze a `~/.claude/projects/` mappa heti `rsync`-másolását egy külső meghajtóra. Ingyenes, és egyetlen crontab-sorra van szükség. ## Kész hookok veszélyes parancsok blokkolására
Fő tanulságok Az alábbi példa PreToolUse jelző kiválasztott Bash-parancsszövegekre és érzékeny Write/Edit útvonalakra. Stdinről olvas JSON-t, egyezésnél 2-vel lép ki. Közvetett vagy elrejtett műveleteket kihagyhat, ezért sandboxot és korlátozott hitelesítő adatokat egészít ki, nem helyettesíti őket. A hookot a meglévő konfigurációba illessze, és használat előtt tesztelje a működését.
E bejegyzést a meglévő hookok cseréje nélkül illessze a `.claude/settings.json` fájlba: ```json { "hooks": { "PreToolUse": [ { "matcher": "Bash|Write|Edit", "hooks": [ { "type": "command", "command": "python3 \"$CLAUDE_PROJECT_DIR/.claude/hooks/check-risk.py\"" } ] } ] } } ``` Hozza létre a `.claude/hooks/check-risk.py` fájlt e Python 3-szkripttel: ```python import json import re import sys from pathlib import Path try: event = json.load(sys.stdin) tool = event["tool_name"] data = event["tool_input"] blocked = False if tool == "Bash": command = data["command"] blocked = bool(re.search( r"drop\s+(database|table)|truncate\s+table|" r"delete\s+from.*where\s+1|rm\s+-rf|" r"git\s+reset\s+--hard|git\s+push.*(--force|-f)|" r"chmod\s+-R\s+777", command, re.IGNORECASE | re.DOTALL)) elif tool in ("Write", "Edit"): path = Path(data["file_path"]).resolve() blocked = (".git" in path.parts or path.name.startswith( (".env", "credentials", "secrets"))) except (ValueError, KeyError, TypeError, OSError): print("BLOCKED: invalid hook input", file=sys.stderr) sys.exit(2) if blocked: print("BLOCKED: high-risk command or sensitive path", file=sys.stderr) sys.exit(2) sys.exit(0) ``` A hook a dokumentált JSON-eseményt **stdinről** olvassa, a `tool_input.command` vagy `tool_input.file_path` mezőt vizsgálja, egyezésnél 2-vel lép ki. Write és Edit esetén is ellenőriz. Támaszkodás előtt ártalmatlan engedett és blokkolt mintát teszteljen, és igazolja a Python és beállított szkript tényleges indulását. Ez lexikai jelző: átrendezett kapcsolókat, szkripteket, aliasokat, elrejtett parancsokat, más eszközöket és közvetett írásokat kihagyhat; ártalmatlan idézett példát is elutasíthat. Operációsrendszer- vagy adatbázisjogot nem ad és nem vesz el. Az éles hitelesítő adatokat tartsa az ügynök környezetén kívül, használjon csak olvasó adatbázisszerepet és kikényszerített sandboxot, és védje a hook konfigurációját a módosítástól. Lásd a [hivatalos hookbemeneti és kilépésikód-referenciát](https://code.claude.com/docs/en/hooks). Szándékos kivételes műveletet nézzen át, és az ügynökön kívül, megfelelően korlátozott fiókkal futtassa. A shell-környezeti változó nem dokumentált hookkikapcsolási felület, a hookok pedig nem szabályozzák a szokásos terminálparancsokat. ## Mikor adjon jogosultságokat az AI-nak (és mikor ne)
Fő tanulságok Valódi adatokat tartalmazó projektekben kategorikusan NE adja az ügynöknek a `--dangerously-skip-permissions` jelzőt. Ebben a YOLO módban minden védelem ki van kapcsolva, az ügynök bármilyen Bash-parancsot lefuttat és megerősítés nélkül ír fájlokat, az elindított alügynökök pedig úgy öröklik a YOLO módot, hogy ezt nem lehet felülbírálni. A YOLO módot csak sandboxmappában használja, új MCP-szerverekkel vagy promptokkal, tesztadatokon végzett kísérletekhez. Minden más esetben használjon pontos jogosultságokat a `.claude/settings.json` fájl explicit `allow` és `deny` szabályaival.
Az Anthropic a `--dangerously-skip-permissions` jelzőt (más néven YOLO módot) „megbízható környezetekhez” használható lehetőségként dokumentálja. A 2026-os valóságban ez **egyenes út a katasztrófához**. Ha az ügynöknek nem kell engedélyt kérnie, akkor: - Bármilyen Bash-parancsot megerősítés nélkül lefuttat - Kérdezés nélkül ír fájlokat - Elindíthat egy alügynököt, amely **örökli** a YOLO módot, és ezt nem lehet visszavonni A harmadik pont a legveszélyesebb. Ha a fő ügynököt YOLO módban indítja, az alügynökei is YOLO módban lesznek, és ezt nem írhatja felül. Egy prompt—és 10 párhuzamos ügynökből álló láncolat bármit megtehet a rendszerén. **Szabály:** | Helyzet | Elfogadható a YOLO? | |--------------------------------------------------|--------------------| | Kísérletezés új MCP-szerverrel egy sandboxmappában | ✅ Igen | | Új prompt tesztelése tesztadatokon | ✅ Igen | | Munka valódi projektfájlokkal | ❌ Nem | | Bármilyen adatbázist érintő parancs | ❌ Soha | | Éles környezetbe történő telepítés | ❌ Soha | | Infrastruktúra kezelése (AWS, Yandex Cloud) | ❌ Soha | **Alternatíva—pontos jogosultságok.** A `.claude/settings.json` fájlban: ```json { "permissions": { "allow": [ "Bash(git status:*)", "Bash(git log:*)", "Bash(npm run build:*)", "Read(*)", "Edit(src/**)" ], "deny": [ "Bash(rm:*)", "Bash(git push:*)", "Edit(.env)", "Edit(prisma/migrations/*)" ] } } ``` Az ügynök látja, mi engedélyezett és mi nem. Nem kell minden alkalommal az „igen” vagy a „nem” gombra kattintania—az ügynök gyorsan dolgozhat, Ön pedig szabályozza a határokat. ## Következő lépés: egy 7 perces ellenőrzőlista könyvjelzőbe mentéshez
Fő tanulságok Mentse el könyvjelzőként ezt az útmutatót most. Ha bekövetkezik a katasztrófa, nyissa meg az oldalt, és kövesse sorrendben a 10 pontos ellenőrzőlistát. Ezzel 30 percnyi pánikot takaríthat meg, és megelőzheti, hogy véletlenül felülírja a még helyreállítható adatokat. A helyreállítás után térjen vissza, és állítsa be a 7 megelőző szabályt, hogy jövő héten ne következzen be újabb katasztrófa.
**Ellenőrzőlista: „Az AI törölte—mit tegyek?”** 1. Azonnal állítsa le a tényleges romboló írót; igazolja a gyermek- vagy távoli műveletek leállását 2. Ne indítsa újra; őrizze meg a törölt fájlt nyitva tartó független folyamatokat 3. Külön ellenőrzött eszközön rögzítse az incidens idejét és parancsbizonyítékát 4. A fennmaradt fájlokat, Git-metaadatokat és releváns munkamenetnaplókat másolja ugyanarra a külön eszközre 5. Az őrzött tárolómásolatban nézze meg a `git reflog --all` eredményét, és igazolt commitot nyerjen vissza külön worktree-be 6. Ha a git nem segített—`git fsck --lost-found` 7. Adatbázis: PITR (AWS/Yandex/Supabase) vagy a legutóbbi pillanatkép 8. Fájlok: Time Machine Macen, lsof Linuxon 9. Végső lehetőség: szolgáltatói támogatás + S3-verziókezelés 10. A helyreállítás után állítsa be az útmutató 7 megelőző szabályát **Következő lépés—szisztematikus védelem:** - [Plan Mode a Claude Code-ban](https://ailoot.ai/blog/hu/claude-code-plan-mode/)—hogy az ügynök **mielőtt** destruktív műveletet végezne, tervet készítsen - [Hooks a Claude Code-ban](https://ailoot.ai/blog/hu/claude-code-hooks/)—kész sablonok veszélyes parancsok blokkolására - [Változtatások visszavonása a Claude Code-ban](https://ailoot.ai/blog/hu/claude-code-undo-changes/)—részletes útmutató a `/rewind`, a git és 5 szokásos visszaállítási módszer használatához - [Biztonsági felülvizsgálat a Claude Code-ban](https://ailoot.ai/blog/hu/claude-code-security-review/)—rendszeres kód-biztonsági ellenőrzések
### Források - [Anthropic Claude Code Hooks dokumentáció](https://code.claude.com/docs/en/hooks-guide) - [Anthropic Claude Code Plan Mode dokumentáció](https://code.claude.com/docs/en/common-workflows) - [PostgreSQL Point-In-Time Recovery (PITR) dokumentáció](https://www.postgresql.org/docs/current/continuous-archiving.html) - [AWS RDS—DB-példány visszaállítása egy adott időpontra](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIT.html) - [Yandex Cloud Managed PostgreSQL—Biztonsági mentés és helyreállítás](https://yandex.cloud/ru/docs/managed-postgresql/concepts/backup) - [Git reflog dokumentáció](https://git-scm.com/docs/git-reflog) - [Git fsck—`--lost-found` mód](https://git-scm.com/docs/git-fsck)
[Ailoot megnyitása](https://ailoot.ai/). ## Kérdések és válaszok: Az AI törölte az adatbázist: 7 perces helyreállítási terv ### Várjam meg az ügynök aktuális parancsának végét? Nem. A romboló írót azonnal állítsa le, és igazolja gyermek-, távoli vagy adatbázis-műveletének leállását. A visszanyerhető törölt fájlt nyitva tartó független folyamatot őrizze meg; az ügynök megállása másik írót tovább futva hagyhat. ### Kezdhetek git reset --hard paranccsal helyreállítani? Előbb külön eszközön őrizze meg a fennmaradt követett, nem követett és kizárt fájlokat és Git-metaadatokat. A másolt tárolót vizsgálja, és igazolt commitot külön worktree-be nyerjen vissza; a helyben hard reset tönkretehet túlélő nem commitolt szerkesztéseket. ## 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.