# AI maʼlumotlar bazasini oʻchirib yubordi: 7 daqiqalik tiklash rejasi > Maʼlumotlar oʻchirilgandan keyin nima qilish kerak: agentni toʻxtating, hodisani hujjatlashtiring, git reflog, PITR, snapshotlar va fayllarni tiklashdan foydalaning. Misollar va himoya choralari. Source: https://ailoot.ai/blog/uz/ai-deleted-database-recovery/ Canonical: https://ailoot.ai/blog/uz/ai-deleted-database-recovery/ Language: uz Publisher: Ailoot (https://ailoot.ai/) Translation: guide-032 Revision: sha256-0f10579d59cc56a2cadfaf6bd9eb05ccab4c3d91a4656b436712533e380d42f6
Asosiy xulosa AI agent hozirgina maʼlumotlar bazangizni, fayllaringizni yoki butun ishlab chiqarish muhitingizni oʻchirib yubordi. Dastlabki 7 daqiqa maʼlumotlarni tiklashingiz yoki ularni butunlay yoʻqotishingizni belgilaydi. Ushbu qoʻllanmada har bir daqiqa uchun aniq buyruqlar berilgan. Avval agentni toʻxtating, keyin hodisani hujjatlashtiring, soʻng tiklang. Vahimaga tushmang — tekshiruv roʻyxatiga amal qiling.
[Ailoot bilan ishlashga oid amaliy maʼlumotlar hujjatlarda mavjud](https://ailoot.ai/docs/). ## Birinchi daqiqada nima qilish kerak: TOʻXTANG, vahimaga tushmang
Asosiy xulosa Buzuvchi yozuvchini, agent to‘xtagach qolgan child jarayonni ham darhol to‘xtating. Qayta yuklamang, o‘chgan faylni ochiq tutishi mumkin bo‘lgan aloqasiz jarayonni tugatmang. Tiklash kafolatlanmagan: ustiga yozish va SSD discard/TRIM imkonsiz qilishi mumkin. Zararlangan nusxani o‘zgartirishdan oldin dalil va qolgan ma’lumotni tekshirilgan alohida qurilmaga saqlang.
Bu siz bilan sodir boʻlsa, **birinchi navbatda agentni toʻxtating**. Uning harakatlarini oʻzingiz bekor qilishga urinmang, unga “hammasini tikla” demang va yangi soʻrovlar yubormang. Agentning keyingi har bir harakati maʼlumotlaringiz hali saqlanib turgan disk bloklari ustiga yozishi mumkin. 1. ### Agent terminalini yoping Ctrl+C bilan xavfli buyruqni darhol uzing, o‘chirish tugashini kutmang. Agentni to‘xtatish child, remote job yoki baza query’sini to‘xtatmasligi mumkin. Haqiqiy yozuvchini topib, ayni amalni to‘xtating/bekor qiling; buzish davom etsa kuchliroq tugatish kerak bo‘lishi mumkin. Foydali ochiq faylli aloqasiz jarayonlarni saqlang. 2. ### Noutbukni qayta yuklamang O‘chgan ma’lumot tiklanishi mumkin, lekin storage, baza xulqi, SSD discard/TRIM va keyingi yozuv hal qiladi. Zararlangan volume’ga yozishni kamaytiring; baytlar hanuz bor deb olmang. 3. ### Ochiq jarayonlarni yopmang O‘chgan faylni ochiq tutgan aloqasiz jarayonni saqlang: deskriptor orqali tiklash mumkin bo‘lishi mumkin. Bu buzuvchi yozuvchiga tegishli emas; avval uni to‘xtating. Ochiq handle uchun o‘chirishni ishlatib turmang. 4. ### Ekran yozuvini boshlang Aniq vaqt, zararlangan yo‘l va ko‘ringan buyruq chiqishini yozing. Yozuv/log nusxasini zararlangan volume emas, tekshirilgan alohida qurilmaga saqlang. Tiklashdan oldin qolgan tracked, untracked, ignored fayl va Git metama’lumotini o‘sha yerda asrang. Keyin tiklash uchun 6 daqiqa bor. Boshlaymiz. ## 2–3-daqiqalar: aynan nima notoʻgʻri boʻlganini hujjatlashtiring
Asosiy xulosa Tiklashdan oldin tashxis qoʻying. “Nima, kim tomonidan, qachon va qaysi buyruqlar bilan oʻchirildi” degan savollarga aniq javob boʻlmasa, koʻr-koʻrona tiklashga urinib, hali butun boʻlgan maʼlumotlarni ham yoʻq qilishingiz mumkin. Yangi terminal oynasini oching (agent ishlayotgan oynani emas), `git status`, `git log --since` va `ps aux | grep claude` buyruqlarini bajaring. Darhol `~/.claude/projects/` papkasidan nusxa oling — unda agentning toʻliq sessiya jurnali bor, u tiklashga yordam berishi mumkin.
Yangi terminal oynasini oching. Agent ishlayotgan oynani emas — boshqa oynani. Quyidagi uchta buyruqni ketma-ket bajaring. **1. Git omborida aynan nima oʻzgarganini qayd eting:** ```bash git status git log --since="30 minutes ago" --all --oneline ``` O‘chgan tracked fayl indeks yoki commit’da bo‘lishi mumkin. Restore’dan oldin joriy daraxtni, untracked va ignored faylni ham saqlang. Joyida tiklash qolgan tahrirni bosishi mumkin. Alohida nusxada tekshirib tiklang. **2. Qaysi agent jarayonlari ishlayotganini tekshiring:** ```bash ps aux | grep -i claude ps aux | grep -i cursor ``` Qaysi jarayon xavfli yozishni davom ettirayotganini aniqlang; nom mosligi yetmaydi. Shu yozuvchini to‘xtatib, to‘xtaganini tekshiring. Foydali faylli aloqasiz jarayonni saqlang. Yumshoq tugatish ishlamay, buzish davom etsa, majburiy tugatish kerak bo‘lishi mumkin. **3. Agent sessiyasi jurnalini saqlang:** Claude Code JSONL sessiyalarini `~/.claude/projects/` ichida saqlaydi. Cursor esa `~/.cursor/` ichida saqlaydi. Hoziroq nusxa oling: ```bash cp -r ~/.claude/projects /external/incident-evidence/claude-projects ``` `/external/incident-evidence/` ni alohida tekshirilgan mounted qurilmadagi mavjud dalil papkasiga almashtiring. Zararlangan volume’ga yozmang yoki eski dalil ustiga yozmang. Bu papkada agent bilan boʻlgan suhbatning aynan oʻzi — qaysi buyruqlarni bajargani, nima deb javob bergani va qanday tartibda qilgani — saqlanadi. Bu hodisani tekshirish va ehtimol uning kontekstidan oʻchirilgan fayllarni tiklash uchun asosiy manbangiz (4-qadamga qarang). ## 4-daqiqa: git reflog — eng yaxshi imkoniyatingiz
Asosiy xulosa Reflog branch tarixidan yo‘qolgan commit’ni topishi mumkin, commit qilinmagan faylni saqlamaydi. Qolgan ma’lumot va Git holatini alohida qurilmada asragach, repo nusxasida tekshirilgan commit’ni alohida worktree’ga tiklang. Zararlangan daraxtni reset qilishdan boshlamang.
`git reflog` yozuvlar saqlanguncha local reference harakatini qayd qiladi. Muddat va pruning farq qiladi, yetilmaydigan obyekt o‘chishi mumkin. Har eski commit’ning kafolatli arxivi emas. Keyingi tiklashni alohida qurilmadagi asralgan repo nusxasidan bajaring. **1-qadam. Jurnalni koʻring:** ```bash git reflog --all ``` Taxminan shunday roʻyxat chiqadi: ``` 1a2b3c4 HEAD@{0}: reset: moving to HEAD~3 9z8y7x6 HEAD@{1}: commit: working version of the dashboard 5w4v3u2 HEAD@{2}: commit: added admin panel ``` Agent zarar yetkazishidan **oldingi** holatni toping. Har bir yozuv omborning oʻsha paytdagi “snapshot”idir. **2-qadam. Alohida ishchi daraxtga tiklang:** Repo va saqlanib qolgan barcha ishni alohida qurilmaga nusxalagach, shu saqlangan nusxadan bajaring. Qiymatga reflog’da tekshirilgan aniq SHA, ishlatilmagan branch va manzilni tanlang: ```bash RECOVERY_COMMIT='replace-with-verified-commit-sha' git worktree add -b recovery-check ../recovery-check "$RECOVERY_COMMIT" ``` `../recovery-check` fayllarini tekshirib, qaytarishdan oldin saqlangan commit qilinmagan ish bilan solishtiring. Buyruq tanlangan commit’ni alohida ochadi, zararlangan daraxtni reset qilmaydi. Worktree’lar nusxa repo obyektlarini bo‘lishadi: bu tiklash workspace’i, mustaqil zaxira emas. [Rasmiy git-worktree hujjatini](https://git-scm.com/docs/git-worktree) ko‘ring. **Agar reflog ham tozalangan boʻlsa (agent `git gc` ni ishga tushirgan boʻlsa):** ```bash git fsck --lost-found ``` Bu buyruq endi hech bir branchga biriktirilmagan “yoʻqolgan” commit va bloblarni (fayl obyektlarini) topadi. Ular `.git/lost-found/commit/` va `.git/lost-found/other/` ichida paydo boʻladi. U yerdan faylni tiklash uchun: ```bash git cat-file -p > recovered-file.ext ``` **git reflog yordam bermaydigan holatlar:** - Fayl faqat ishchi daraxtda boʻlgan, commit yoki stash qilinmagan → reflog uni koʻra olmaydi - Standart `gc.reflogExpire` muddati boʻyicha 90 kundan ortiq vaqt oʻtgan va `git gc` ishga tushirilgan - Butun ombor oʻchirilgan (`rm -rf .git`) — unda Time Machine yoki snapshot kerak boʻladi ## 5-daqiqa: maʼlumotlar bazasini zaxira nusxasidan tiklang
Asosiy xulosa PostgreSQL Point-In-Time Recovery (PITR) maʼlumotlar bazasini 7–35 kunlik oraliqdagi istalgan soniyaga tiklaydi. U Yandex Cloud Managed Postgres, AWS RDS, Supabase Pro va Coolify’dagi mahalliy `pg_dump` cron vazifasi bilan ishlaydi. Asosiy talab: PITR hodisadan **oldin** yoqilgan boʻlishi kerak; uni orqaga qarab yoqib boʻlmaydi. Har doim yangi instansiyaga tiklang, hech qachon faol maʼlumotlar bazasi ustiga tiklamang, toki qaytarish jarayoni yanada koʻproq maʼlumotni yoʻq qilmasin. Agar PITR yoqilmagan boʻlsa, eng soʻnggi snapshotdan foydalaning.
Maʼlumotlar bazasi `DROP DATABASE`, `DROP TABLE` yoki `DELETE FROM ... WHERE ...` (WHERE shartisiz) bilan oʻchirildi. Nima qilish kerak? **1-qadam. Provayderingiz PITR taklif qiladimi, aniqlang:** | Provayder | PITR muddati | Tiklash buyrugʻi | |----|----|----| | AWS RDS | 1–35 kun (sozlanadi) | `aws rds restore-db-instance-to-point-in-time --restore-time 2026-05-28T14:30:00Z` | | Yandex Cloud Managed Postgres | 7 kun (standart boʻyicha) | Konsolda zaxira nusxasidan tiklang + vaqtni belgilang | | Supabase Pro | 7 kun (faqat Pro+) | UI: Database → Backups → Restore | | Coolify + mahalliy pg_dump | Cron jadvaliga muvofiq | `pg_restore -d new_db backup.dump` | **2-qadam. Eski instansiyaga emas, yangisiga tiklang:** Faol maʼlumotlar bazasi ustiga hech qachon tiklamang. Zaxira nusxasidan yangi instansiya yarating, keyin ilovani unga oʻtkazing. Biror narsa notoʻgʻri ketsa, DNS’ni qayta oʻzgartirishingiz mumkin. **3-qadam. Agar PITR yoqilmagan boʻlsa, eng soʻnggi snapshotdan foydalaning:** ```bash # AWS RDS, snapshotlarni roʻyxatlash: aws rds describe-db-snapshots --db-instance-identifier my-db # Snapshotdan tiklash: 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 ``` **Supabase bilan bogʻliq muhim jihat**, 2026-yilda koʻpchilikni hayratda qoldirgan: PITR yoqilganda, kunlik zaxira nusxalari **yaratilmay qoladi**. Bu kutilmagan xatti-harakat; natijada umuman zaxira nusxasiz qolishingiz mumkin. PITR faol ekanini VA tiklash uchun snapshot borligini tekshirish uchun Dashboard → Database → Backups boʻlimiga qarang. ## 6-daqiqa: Time Machine, lsof va disk snapshotlari
Asosiy xulosa Fayllar git yoki maʼlumotlar bazasidan emas, diskdan oʻchirilgan boʻlsa, tiklashning uchta amaliy usuli bor. macOS’da, agar noutbuk Time Capsule yoki tashqi diskka ulangan boʻlsa, soatlik snapshotlardan foydalaning. Linux’da `sudo lsof | grep deleted` ni bajaring — jarayon hali ochiq tutgan fayllarni qaytarib olishi mumkin (95% ehtimol); ularni `/proc/PID/fd/N` orqali nusxalang. Muhim holatlarda butun boʻlim snapshotini `dd` yordamida yarating, keyin `extundelete` yoki `photorec` bilan tiklang.
**macOS — Time Machine:** ```bash # Snapshotlarni roʻyxatlash: tmutil listbackups # Eng soʻnggi zaxira nusxasidan faylni tiklash: tmutil restore /Volumes/Backup/.../my-project/file.tsx ~/projects/my-project/file.tsx ``` Time Machine har soatda snapshot oladi, soatlik snapshotlarni bir kun, kunliklarini bir hafta, haftaliklarini esa muddatsiz saqlaydi. Noutbukingiz Time Capsule yoki tashqi diskka ulangan boʻlsa, loyihangiz soatlik aniqlikda saqlangan boʻladi. **Linux — fayl oʻchirilgan, lekin jarayon uni hali ochiq tutib turibdi:** ```bash # Jarayon hali ochiq tutgan barcha “oʻchirilgan” fayllarni topish: sudo lsof | grep deleted # Shunga oʻxshash satrlar chiqadi: # node 12345 user 24w REG 8,1 4096 1234567 /path/to/deleted/file.txt (deleted) # Faylni bevosita /proc/PID/fd/N dan nusxalash: sudo cp /proc/12345/fd/24 ~/recovered-file.txt ``` Jarayon yopilmagan boʻlsa, muvaffaqiyat ehtimoli ~95%. ext4, xfs, btrfs’da ishlaydi. **macOS — `lsof` yordamida shunga oʻxshash usul:** ```bash lsof | grep deleted ``` Faylni nusxalash qiyinroq (`/proc/` mavjud emas), ammo buni `lldb` bilan bajarish mumkin: ```bash lldb -p 12345 (lldb) memory read --outfile recovered.txt --binary 0xADDRESS 0xSIZE ``` **Butun disk snapshoti (Linux, oxirgi chora):** ```bash sudo dd if=/dev/sda1 of=/external/disk-image.img bs=4M status=progress ``` Bu butun boʻlimni tasvir fayli sifatida saqlaydi. Keyin `extundelete` yoki `photorec` yordamida tiklang. Tiklash ehtimoli oʻchirilgandan beri diskka qancha maʼlumot yozilganiga bogʻliq. Hech narsa yozilmagan boʻlsa, ehtimol 80–90%. Bir soat ishlatilgan boʻlsa, 20–30%. ## 7-daqiqa: zaxira nusxasi boʻlmasa nima qilish kerak
Asosiy xulosa Zaxira nusxasi yoʻq, git reflog boʻsh va disk ustiga yangi maʼlumotlar yozib boʻlingan. Oxirgi chora sifatida ikkita imkoniyat qoladi: provayderingiz yordam xizmatiga murojaat qilish (AWS, Yandex Cloud va Google Cloud vaqti-vaqti bilan oʻz ichki xotirasidan maʼlumotlarni tiklaydi) yoki S3 versiyalarini tiklash (agar yoqilgan boʻlsa, barcha versiyalar jismonan mavjud).
**1-variant — provayder yordami:** AWS, Yandex Cloud, Google Cloud va DigitalOcean mijoz boshiga falokat tushganidan keyin ham, ayniqsa pulli tariflarda, vaqti-vaqti bilan oʻz ichki xotirasidan maʼlumotlarni tiklaydi. Yordam xizmatiga murojaat oching, hodisaning aniq vaqtini bering va holat skrinshotlarini qoʻshing. Bu koʻpincha oʻz tomonida avtomatik zaxira nusxalarini saqlaydigan yirik provayderlarda ish beradi. Muvaffaqiyat ehtimoli 40–60%; javob muddati 24–72 soat. **2-variant — S3 versiyalash:** Fayllar S3’da (yoki Yandex Object Storage’da) boʻlgan va versiyalash yoqilgan boʻlsa, barcha versiyalar **jismonan mavjud**; ular shunchaki “oʻchirilgan” deb belgilangan. ```bash # AWS — versiyalarni roʻyxatlash: aws s3api list-object-versions --bucket my-bucket --prefix files/ # Versiyani tiklash: aws s3api copy-object \ --bucket my-bucket \ --copy-source my-bucket/files/data.json?versionId=ABC123 \ --key files/data.json ``` **Muhim ogohlantirish:** Claude Code sessiyalarni abadiy saqlamaydi — eski JSONL fayllari bir necha haftadan keyin avtomatik oʻchiriladi. Falokat yuz berganda bir oylik JSONL tarixi borligiga ishonch hosil qilish uchun haftasiga bir marta oddiy cron vazifasi yordamida `~/.claude/projects/` papkasini tashqi diskka nusxalang: ```bash # Crontab’da, har yakshanba 03:00 da: 0 3 * * 0 rsync -av ~/.claude/projects/ /external/claude-history-backup/ ``` Bu bepul va “hammasi yoʻqoldi, zaxira nusxasi yoʻq, reflog boʻsh” boʻlganida yordam beradi. ## Bunday holat boshqa takrorlanmasligi uchun 7 qoida
Asosiy xulosa AI agent maʼlumotlar bazangiz yoki kodingizni oʻchirib yuborishiga yoʻl qoʻymaydigan yetti qoida. Buzuvchi amallardan oldin Plan Mode’dan foydalaning. Tanlangan xavfli buyruq satriga sinalgan hook va majburiy ruxsat limitini birga ishlating. Agentga faqat oʻqish huquqiga ega maʼlumotlar bazasi foydalanuvchisini bering. Har bir fayl tahriridan keyin avtomatik commit qiling. Tajribalar uchun ajratilgan sandbox papkasidan foydalaning. Har soatda `restic` bilan disk snapshotlarini oling. JSONL sessiyalarini tashqi diskka arxivlang.
**1. Har qanday buzuvchi amaldan oldin Plan Mode.** Claude Code’da: ```bash claude --plan ``` Agent ish boshlashidan **oldin** reja tuzadi. Siz uni oʻqib, `DROP TABLE users` ni koʻrib, bekor qilasiz. Plan Mode boʻlmasa, agent oʻzi qaror qiladi va millisekundlarda bajaradi. [Claude Code’dagi Plan Mode qoʻllanmasi](https://ailoot.ai/blog/uz/claude-code-plan-mode/)dan batafsil maʼlumot oling. **2. Hook qo‘shimcha ogohlantiruvchi chegara sifatida.** Stdin JSON’ni o‘qib, topilgan yuqori xatarga exit 2 beradigan sinalgan PreToolUse qo‘llang. Quyidagi to‘liq misol Bash, Write va Edit’ni qamraydi; xavfsizlik chegarasi emas, bilvosita amalni o‘tkazishi mumkin. Baza vakolati va sandbox tor bo‘lsin. **3. Agent uchun faqat oʻqish huquqiga ega DB foydalanuvchisi.** Agent uchun `DROP`, `TRUNCATE` yoki `DELETE` ruxsatlariga **ega boʻlmagan** alohida foydalanuvchi yarating: ```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; ``` Agentga haqiqatan yozish kerak boʻlganda, boshqa foydalanuvchiga qoʻlda oʻting. Maʼlumotlarni tahlil qilish, hisobotlar va boshqaruv panellari kabi kundalik vazifalar uchun faqat oʻqish huquqi yetarli. **4. Tekshirilgan oʻzgarishlarni Git’da saqlang.** `.claude/settings.json` ichidagi `PostToolUse` hooki `Write` va `Edit` amallaridan keyin eslatma chiqarishi mumkin: ```json { "hooks": { "PostToolUse": [ { "matcher": "Write|Edit", "hooks": [ { "type": "command", "command": "printf '%s\\n' 'Diffni tekshiring va faqat kelishilgan fayllarni qoʻlda commit qiling.' >&2" } ] } ] } } ``` Bu misol faqat eslatma chiqaradi; fayllarni indeksga qoʻshmaydi va commit yaratmaydi. Diffni tekshiring va faqat kelishilgan fayllarni qoʻlda commit qiling. Reflog commit qilinmagan oʻzgarishlarni saqlamaydi. **5. Tajribalar uchun sandbox loyiha.** Agentga haqiqiy mijozlar maʼlumotlari bor loyihada ishlashga hech qachon ruxsat bermang. Loyiha nusxasi va sunʼiy maʼlumotlar bilan alohida `~/sandbox-projects/` papkasini yarating. Unda yangi soʻrov, agent yoki MCP serverni sinab koʻring. Biror narsa buzilsa, zarar boʻlmaydi. **6. Har soatda `restic` bilan disk snapshotlari.** ```bash # Oʻrnatish: brew install restic # macOS sudo apt install restic # Linux # Ombor yaratish: restic init --repo /external/backups # Joriy loyihani zaxiralash: restic --repo /external/backups backup ~/projects # Har soatlik cron jadvalini sozlash: crontab -e # Qoʻshing: 0 * * * * restic --repo /external/backups backup ~/projects ``` Yetti kunlik soatlik zaxira nusxalari, toʻrt haftalik kunlik nusxalar — oʻtmishdagi istalgan nuqtaga qaytishingiz mumkin. Bu bepul va sozlashga 10 daqiqa ketadi. **7. Claude Code JSONL sessiyalarini arxivlang.** Yuqorida aytib oʻtilgan, ammo alohida qoida sifatida takrorlaymiz: haftalik `rsync` vazifasi orqali `~/.claude/projects/` papkasini tashqi diskka nusxalang. Bu bepul va crontab’ga bir qator qoʻshish kifoya. ## Xavfli buyruqlarni toʻsish uchun tayyor hooklar
Asosiy xulosa Quyidagi PreToolUse tanlangan Bash satri va maxfiy Write/Edit yo‘liga signal. Stdin JSON o‘qib, match’da exit 2 qaytaradi. Bilvosita/yashirin amalni o‘tkazishi mumkin: sandbox va tor credential’ga qo‘shimcha. Mavjud konfiguratsiyaga birlashtirib, oldin xulqini sinang.
Mavjud hook’larni almashtirmay, `.claude/settings.json` ga birlashtiring: ```json { "hooks": { "PreToolUse": [ { "matcher": "Bash|Write|Edit", "hooks": [ { "type": "command", "command": "python3 \"$CLAUDE_PROJECT_DIR/.claude/hooks/check-risk.py\"" } ] } ] } } ``` `.claude/hooks/check-risk.py` ni quyidagi Python 3 skripti bilan yarating: ```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) ``` Hook hujjatdagi JSON’ni **stdin** dan o‘qib, `tool_input.command` yoki `tool_input.file_path` ni tekshiradi, match’da exit 2 beradi. Write ham, Edit ham tekshiriladi. Zararsiz ruxsatli va bloklangan fixture’da sinang; Python va skript haqiqatan boshlanishini tasdiqlang. Bu leksik signal: qayta tartiblangan bayroq, skript, alias, yashirilgan buyruq, boshqa vosita va bilvosita yozishni o‘tkazishi, zararsiz iqtibosni rad etishi mumkin. OS/baza ruxsatini bermaydi yoki olmaydi. Production credential’ini agentdan tashqarida, bazani read-only rolda, sandbox’ni majburiy tuting; hook konfiguratsiyasini tahrirdan himoyalang. [Rasmiy kirish va exit-code manbasini](https://code.claude.com/docs/en/hooks) ko‘ring. Ataylab istisno amalni ko‘rib chiqib, agentdan tashqarida mos tor hisobda bajaring. Shell o‘zgaruvchisi hujjatli hook-disable interfeysi emas; hook oddiy terminalni boshqarmaydi. ## AI’ga qachon ruxsat berish kerak (va qachon bermaslik kerak)
Asosiy xulosa Haqiqiy maʼlumotlari bor loyihalarda agentga `--dangerously-skip-permissions` bayrogʻini mutlaqo bermang. Bu YOLO rejimida barcha himoyalar oʻchiriladi, agent har qanday Bash buyrugʻini bajaradi va fayllarni tasdiqsiz yozadi; ishga tushirilgan subagentlar ham YOLO rejimini meros qilib oladi va uni bekor qilib boʻlmaydi. YOLO’dan faqat yangi MCP serverlar yoki soʻrovlarni soxta maʼlumotlar bilan sinash uchun sandbox papkasida foydalaning. Boshqa barcha holatlarda `.claude/settings.json` orqali aniq `allow` va `deny` qoidalaridan iborat nozik ruxsatlardan foydalaning.
Anthropic `--dangerously-skip-permissions` bayrogʻini (YOLO rejimi nomi bilan ham tanilgan) “ishonchli muhitlar” uchun imkoniyat sifatida hujjatlashtiradi. 2026-yil voqeligida esa bu **falokatga eltuvchi toʻgʻri yoʻl**. Agent tasdiq soʻramasa, u: - Istalgan Bash buyrugʻini tasdiqsiz bajaradi - Fayllarni soʻramasdan yozadi - Subagentni ishga tushirishi mumkin, u esa YOLO rejimini **meros qilib oladi** va uni bekor qilib boʻlmaydi Uchinchi jihat eng makkoridir. Asosiy agentni YOLO bilan ishga tushirsangiz, subagentlari ham YOLO boʻladi va siz buni oʻzgartira olmaysiz. Bitta soʻrov va 10 ta parallel agent tizimingizda istalgan ishni qilishi mumkin. **Qoida:** | Vaziyat | YOLO maqbulmi? | |--------------------------------------------------|--------------------| | Sandbox papkasida yangi MCP server bilan tajriba oʻtkazish | ✅ Ha | | Soxta maʼlumotlarda yangi soʻrovni sinash | ✅ Ha | | Haqiqiy loyiha fayllari bilan ishlash | ❌ Yoʻq | | Maʼlumotlar bazasiga tegadigan har qanday buyruq | ❌ Hech qachon | | Ishlab chiqarish muhitiga joylash | ❌ Hech qachon | | Infratuzilmani boshqarish (AWS, Yandex Cloud) | ❌ Hech qachon | **Muqobil — nozik ruxsatlar.** `.claude/settings.json` da: ```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/*)" ] } } ``` Agent nimalarga ruxsat borligini va yoʻqligini koʻradi. Har safar “ha” yoki “yoʻq” tugmasini bosishingiz shart emas — agent tez ishlaydi, chegaralarni esa siz nazorat qilasiz. ## Keyingi qadam: xatchoʻp qilib qoʻyish uchun 7 daqiqalik tekshiruv roʻyxati
Asosiy xulosa Ushbu qoʻllanmani hoziroq xatchoʻplarga qoʻshing. Falokat yuz berganda sahifani ochib, 10 bandli tekshiruv roʻyxatiga tartib bilan amal qiling. Bu vahimaga sarflanadigan 30 daqiqani tejaydi va hali tiklash mumkin boʻlgan maʼlumotlar ustiga tasodifan yozib yuborishdan saqlaydi. Tiklaganingizdan soʻng qaytib, kelasi hafta falokat yana yuz bermasligi uchun oldini oluvchi 7 qoidani sozlang.
**Tekshiruv roʻyxati: “AI oʻchirib yubordi — nima qilaman?”** 1. Haqiqiy buzuvchi yozuvchini darhol to‘xtating; child va remote amal ham to‘xtaganini tekshiring 2. Qayta yuklamang; o‘chgan faylni ochiq tutgan aloqasiz jarayonni saqlang 3. Vaqt va buyruq dalilini tekshirilgan alohida qurilmaga yozing 4. Qolgan fayl, Git metama’lumoti va tegishli seans logini shu qurilmaga nusxalang 5. Saqlangan nusxada `git reflog --all` ko‘rib, tekshirilgan commit’ni alohida worktree’ga oching 6. Git yordam bermasa — saqlangan nusxada `git fsck --lost-found` 7. Baza: PITR (AWS/Yandex/Supabase) yoki so‘nggi snapshot 8. Fayl: Mac’da Time Machine, Linux’da lsof 9. Oxirgi chora: provayder yordami va S3 versiyalash 10. Tiklagach, oldini olish qoidalarini sozlang **Keyingi qadam — tizimli himoya:** - [Claude Code’da Plan Mode](https://ailoot.ai/blog/uz/claude-code-plan-mode/) — agent buzuvchi amaldan **oldin** reja tuzishi uchun - [Claude Code’da Hooks](https://ailoot.ai/blog/uz/claude-code-hooks/) — xavfli buyruqlarni toʻsish uchun tayyor shablonlar - [Claude Code’dagi oʻzgarishlarni qanday qaytarish kerak](https://ailoot.ai/blog/uz/claude-code-undo-changes/) — `/rewind`, git va qaytarishning 5 ta standart usuli boʻyicha batafsil qoʻllanma - [Claude Code’da xavfsizlik tekshiruvi](https://ailoot.ai/blog/uz/claude-code-security-review/) — kod xavfsizligini muntazam tekshirish
### Manbalar - [Anthropic Claude Code Hooks hujjatlari](https://code.claude.com/docs/en/hooks-guide) - [Anthropic Claude Code Plan Mode hujjatlari](https://code.claude.com/docs/en/common-workflows) - [PostgreSQL Point-In-Time Recovery (PITR) hujjatlari](https://www.postgresql.org/docs/current/continuous-archiving.html) - [AWS RDS — maʼlumotlar bazasi instansiyasini muayyan vaqtga tiklash](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIT.html) - [Yandex Cloud Managed PostgreSQL — zaxiralash va tiklash](https://yandex.cloud/ru/docs/managed-postgresql/concepts/backup) - [Git reflog hujjatlari](https://git-scm.com/docs/git-reflog) - [Git fsck — `--lost-found` rejimi](https://git-scm.com/docs/git-fsck)
[Ailoot’ni oching](https://ailoot.ai/). ## Ko‘p beriladigan savollar ### Agentning joriy buyrug‘i tugashini kutish kerakmi? Yo‘q. Buzuvchi yozuvchini darhol to‘xtatib, child, remote yoki baza amali to‘xtaganini tekshiring. Tiklanadigan faylni ochiq tutgan aloqasiz jarayonni asrang. Agentning o‘zi to‘xtashi boshqa yozuvchini qoldirishi mumkin. ### Tiklashni git reset --hard bilan boshlash mumkinmi? Avval qolgan tracked, untracked, ignored fayl va Git holatini alohida qurilmaga saqlang. Nusxada tekshirilgan commit’ni alohida worktree’ga tiklang. Joyidagi hard reset qolgan commit qilinmagan ishni yo‘q qilishi mumkin. ## Ailoot · Kompaniya va uning loyihalar portfeli Ailoot to‘plangan faoliyat tajribasi, keng mijozlar bazasi, barqaror xizmat va doimiy KPI nazoratiga tayanadi. Kompaniya va uning loyihalar portfeli: millionlab mijozlar; oylik sotuvlar hajmi milliardlarda. Ailoot bu faoliyat tajribasini mijozlar mahsulotlari, agentlar, ilovalar va avtomatlashtirishlarda AI imkoniyatlariga API orqali kirishni ta’minlashda qo‘llaydi.