Η AI διέγραψε τη βάση δεδομένων: σχέδιο ανάκτησης 7 λεπτών

Πρακτικές πληροφορίες για τη χρήση του Ailoot είναι διαθέσιμες στην τεκμηρίωση.

Τι να κάνετε στο πρώτο λεπτό: ΣΤΑΜΑΤΗΣΤΕ, μην πανικοβάλλεστε#

Όταν σας συμβεί αυτό, το πρώτο πράγμα που πρέπει να κάνετε είναι να σταματήσετε τον agent. Μην προσπαθήσετε να αναιρέσετε μόνοι σας τις ενέργειές του, μην του πείτε «επαναφορά όλων» και μην εκτελέσετε νέες προτροπές. Κάθε επόμενη ενέργεια του agent μπορεί να αντικαταστήσει τα μπλοκ του δίσκου όπου ίσως εξακολουθούν να είναι αποθηκευμένα τα δεδομένα σας.

1. Κλείστε το τερματικό του agent

   Διακόψτε αμέσως την επικίνδυνη εντολή με Ctrl+C· μην περιμένετε να τελειώσει η διαγραφή. Το σταμάτημα agent δεν σταματά απαραίτητα παιδικές εντολές, απομακρυσμένες εργασίες ή ερωτήματα βάσης. Εντοπίστε τον πραγματικό writer και σταματήστε ή ακυρώστε εκείνη την ενέργεια· κλιμακώστε τερματισμό αν συνεχίζει καταστροφή δεδομένων. Κρατήστε ζωντανές άσχετες διεργασίες με δυνητικά ανακτήσιμα ανοιχτά αρχεία.

2. ΜΗΝ επανεκκινήσετε τον φορητό υπολογιστή σας

   Διαγραμμένα δεδομένα μπορεί να παραμένουν ανακτήσιμα, αλλά αυτό εξαρτάται από αποθήκευση, συμπεριφορά βάσης, SSD discard/TRIM και επόμενες εγγραφές. Ελαχιστοποιήστε εγγραφές στον επηρεασμένο τόμο· μη θεωρείτε ότι υπάρχουν ακόμη τα bytes.

3. ΜΗΝ κλείσετε ανοιχτές διεργασίες

   Διατηρήστε άσχετες διεργασίες που κρατούν διαγραμμένα αρχεία ανοιχτά, επειδή μπορεί να είναι δυνατή ανάκτηση μέσω περιγραφέων αρχείων. Αυτό δεν ισχύει για τον καταστροφικό writer: σταματήστε τον πρώτο. Μην κρατάτε ενεργή διαγραφή μόνο για διατήρηση ανοιχτού handle.

4. Ξεκινήστε εγγραφή οθόνης

   Καταγράψτε ακριβή χρόνο, επηρεασμένες διαδρομές και ορατή έξοδο εντολών. Αν καταγράφετε ή αντιγράφετε logs, αποθηκεύστε σε ξεχωριστή επαληθευμένη συσκευή αντί κατεστραμμένου τόμου. Διασώστε εκεί σωζόμενα tracked, untracked και ignored αρχεία και μεταδεδομένα Git πριν επιχειρήσετε ανάκτηση.

Απομένουν 6 λεπτά για την ανάκτηση. Ας ξεκινήσουμε.

Λεπτά 2–3: καταγράψτε με ακρίβεια τι πήγε στραβά#

Ανοίξτε ένα νέο παράθυρο τερματικού. Όχι εκείνο όπου εκτελείται ο agent—ένα άλλο. Εκτελέστε αυτές τις τρεις εντολές διαδοχικά.

1. Καταγράψτε ακριβώς τι άλλαξε στο αποθετήριο git:

git status
git log --since="30 minutes ago" --all --oneline

Ένα διαγραμμένο tracked αρχείο μπορεί ακόμη να υπάρχει στο index ή σε commit. Διασώστε τρέχον δέντρο εργασίας, μαζί με untracked και ignored αρχεία, πριν από οποιαδήποτε αποκατάσταση· η επί τόπου αποκατάσταση μπορεί να αντικαταστήσει σωζόμενες αλλαγές. Εξετάστε και ανακτήστε σε χωριστό αντίγραφο.

2. Ελέγξτε ποιες διεργασίες agent εκτελούνται:

ps aux | grep -i claude
ps aux | grep -i cursor

Εντοπίστε ποια διεργασία συνεχίζει τις επικίνδυνες εγγραφές· αντιστοίχιση ονόματος μόνη της δεν αρκεί. Σταματήστε εκείνον τον writer και επαληθεύστε ότι σταμάτησε. Διατηρήστε άσχετες διεργασίες με χρήσιμα ανοιχτά αρχεία· αν αποτύχει ο ομαλός τερματισμός και συνεχίζεται καταστροφή, μπορεί να απαιτείται αναγκαστικός τερματισμός.

3. Αποθηκεύστε το αρχείο καταγραφής της συνεδρίας του agent:

Το Claude Code αποθηκεύει συνεδρίες JSONL στο ~/.claude/projects/. Το Cursor τις αποθηκεύει στο ~/.cursor/. Δημιουργήστε αντίγραφο αμέσως τώρα:

cp -r ~/.claude/projects /external/incident-evidence/claude-projects

Αντικαταστήστε το /external/incident-evidence/ με υπάρχοντα κατάλογο στοιχείων σε ξεχωριστή επαληθευμένη προσαρτημένη συσκευή. Μη γράφετε το backup στον επηρεασμένο τόμο ή αντικαθιστάτε υπάρχοντα στοιχεία. Αυτός ο φάκελος περιέχει την αυτούσια συνομιλία με τον agent—τις εντολές που εκτέλεσε, τις απαντήσεις του και τη σειρά τους. Είναι η κύρια πηγή σας για τη διερεύνηση του περιστατικού και ενδεχομένως για την ανάκτηση διαγραμμένων αρχείων από το περιεχόμενό της (δείτε το βήμα 4).

Λεπτό 4: git reflog—η καλύτερη ευκαιρία σας#

Το git reflog καταγράφει τοπικές μετακινήσεις αναφορών όσο διατηρούνται οι καταχωρίσεις. Λήξη και pruning διαφέρουν και μη προσβάσιμα αντικείμενα μπορούν να αφαιρεθούν· δεν είναι εγγυημένο αρχείο κάθε παλιού commit. Εκτελέστε τα παρακάτω βήματα από διασωσμένο αντίγραφο αποθετηρίου στη ξεχωριστή συσκευή.

Βήμα 1. Προβάλετε το αρχείο καταγραφής:

git reflog --all

Θα λάβετε μια λίστα όπως η εξής:

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. Κάθε καταχώριση είναι ένα «στιγμιότυπο» της κατάστασης του αποθετηρίου εκείνη τη στιγμή.

Βήμα 2. Ανάκτηση σε χωριστό δέντρο εργασίας:

Αφού αντιγράψετε το αποθετήριο και όλη τη σωζόμενη εργασία σε ξεχωριστή συσκευή, εκτελέστε από εκείνο το διασωσμένο αντίγραφο. Αντικαταστήστε την τιμή με το ακριβές commit SHA που ελέγξατε στο reflog και επιλέξτε αχρησιμοποίητο κλάδο και προορισμό:

RECOVERY_COMMIT='replace-with-verified-commit-sha'
git worktree add -b recovery-check ../recovery-check "$RECOVERY_COMMIT"

Εξετάστε τα ανακτημένα αρχεία στο ../recovery-check και συγκρίνετέ τα με τα διασωσμένα αρχεία χωρίς commit πριν αντιγράψετε οτιδήποτε πίσω. Η εντολή κάνει χωριστό checkout του επιλεγμένου commit· δεν επαναφέρει το κατεστραμμένο δέντρο εργασίας. Συνδεδεμένα worktrees μοιράζονται την αποθήκη αντικειμένων Git του αντιγραμμένου αποθετηρίου, οπότε είναι χώρος ανάκτησης, όχι ανεξάρτητο backup. Δείτε την επίσημη τεκμηρίωση git-worktree.

Αν καθαρίστηκε και το reflog (ο agent κατάφερε να εκτελέσει git gc):

git fsck --lost-found

Αυτή η εντολή βρίσκει «χαμένα» commits και blobs (αντικείμενα αρχείων) που δεν είναι πλέον συνδεδεμένα με κάποιο branch. Θα εμφανιστούν στα .git/lost-found/commit/ και .git/lost-found/other/. Για να επαναφέρετε ένα αρχείο από εκεί:

git cat-file -p <SHA1-blob> > recovered-file.ext

Πότε το git reflog ΔΕΝ βοηθά:

• Το αρχείο υπήρχε μόνο στο working tree, χωρίς commit ή stash → το reflog δεν μπορεί να το δει
• Έχουν περάσει περισσότερες από 90 ημέρες (το τυπικό gc.reflogExpire) και εκτελέστηκε git gc
• Διαγράφηκε ολόκληρο το αποθετήριο (rm -rf .git)—τότε χρειάζεστε Time Machine ή στιγμιότυπο

Λεπτό 5: επαναφέρετε τη βάση δεδομένων από αντίγραφο ασφαλείας#

Η βάση δεδομένων διαγράφηκε με DROP DATABASE, DROP TABLE ή DELETE FROM ... WHERE ... (χωρίς όρο WHERE). Τι πρέπει να κάνετε;

Βήμα 1. Μάθετε αν ο πάροχός σας προσφέρει PITR:

Βήμα 2. Επαναφέρετε σε νέα παρουσία, όχι στην παλιά:

Μην κάνετε ποτέ επαναφορά πάνω από μια ενεργή βάση δεδομένων. Δημιουργήστε μια νέα παρουσία από το αντίγραφο ασφαλείας και μετά αλλάξτε την εφαρμογή ώστε να τη χρησιμοποιεί. Αν κάτι πάει στραβά, μπορείτε να επαναφέρετε το DNS.

Βήμα 3. Αν δεν είχε ενεργοποιηθεί το PITR, χρησιμοποιήστε το πιο πρόσφατο στιγμιότυπο:

# AWS RDS, λίστα στιγμιότυπων:
aws rds describe-db-snapshots --db-instance-identifier my-db

# Επαναφορά από στιγμιότυπο:
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, που αιφνιδίασε πολλούς το 2026: όταν είναι ενεργοποιημένο το PITR, σταματούν να δημιουργούνται καθημερινά αντίγραφα ασφαλείας. Απρόσμενη συμπεριφορά· μπορεί να καταλήξετε χωρίς κανένα αντίγραφο ασφαλείας. Ελέγξτε Dashboard → Database → Backups για να βεβαιωθείτε ότι το PITR είναι ενεργό ΚΑΙ ότι έχετε στιγμιότυπο από το οποίο μπορείτε να κάνετε επαναφορά.

Λεπτό 6: Time Machine, lsof και στιγμιότυπα δίσκου#

macOS—Time Machine:

# Λίστα στιγμιότυπων:
tmutil listbackups

# Επαναφορά αρχείου από το πιο πρόσφατο αντίγραφο ασφαλείας:
tmutil restore /Volumes/Backup/.../my-project/file.tsx ~/projects/my-project/file.tsx

Το Time Machine δημιουργεί στιγμιότυπα κάθε ώρα, διατηρεί ωριαία στιγμιότυπα για μία ημέρα, ημερήσια για μία εβδομάδα και εβδομαδιαία επ' αόριστον. Αν ο φορητός υπολογιστής σας είναι συνδεδεμένος σε Time Capsule ή εξωτερικό δίσκο, το έργο σας βρίσκεται εκεί με ωριαία ανάλυση.

Linux—το αρχείο διαγράφηκε, αλλά μια διεργασία εξακολουθεί να το έχει ανοιχτό:

# Εύρεση όλων των «διαγραμμένων» αρχείων που εξακολουθεί να έχει ανοιχτά μια διεργασία:
sudo lsof | grep deleted

# Θα δείτε γραμμές όπως:
# node 12345 user 24w REG 8,1 4096 1234567 /path/to/deleted/file.txt (deleted)

# Αντιγραφή του αρχείου απευθείας από το /proc/PID/fd/N:
sudo cp /proc/12345/fd/24 ~/recovered-file.txt

Η πιθανότητα επιτυχίας είναι ~95%, αν δεν έκλεισε η διεργασία. Λειτουργεί σε ext4, xfs, btrfs.

macOS—αντίστοιχη χρήση του lsof:

lsof | grep deleted

Η αντιγραφή του αρχείου είναι δυσκολότερη (δεν υπάρχει /proc/), αλλά μπορείτε να την κάνετε με το lldb:

lldb -p 12345
(lldb) memory read --outfile recovered.txt --binary 0xADDRESS 0xSIZE

Στιγμιότυπο ολόκληρου του δίσκου (Linux, τελευταία λύση):

sudo dd if=/dev/sda1 of=/external/disk-image.img bs=4M status=progress

Αυτό αποθηκεύει ολόκληρο το διαμέρισμα ως εικόνα. Έπειτα κάντε ανάκτηση χρησιμοποιώντας extundelete ή photorec. Η πιθανότητα ανάκτησης εξαρτάται από το πόσα δεδομένα έχουν γραφτεί στον δίσκο από τη διαγραφή. Αν δεν έχει γραφτεί τίποτα, είναι 80–90%. Αν λειτουργεί ήδη επί μία ώρα, είναι 20–30%.

Λεπτό 7: τι γίνεται αν δεν υπάρχει αντίγραφο ασφαλείας#

Επιλογή 1—υποστήριξη παρόχου:

Οι AWS, Yandex Cloud, Google Cloud και DigitalOcean ανακτούν περιοδικά δεδομένα από τον εσωτερικό χώρο αποθήκευσής τους, ακόμη και μετά από καταστροφή που προκλήθηκε από πελάτη, ιδίως στα επί πληρωμή προγράμματα. Ανοίξτε αίτημα υποστήριξης, δώστε την ακριβή ώρα του περιστατικού και συμπεριλάβετε στιγμιότυπα της κατάστασης. Αυτό λειτουργεί συχνότερα με μεγάλους παρόχους που διατηρούν αυτόματα αντίγραφα ασφαλείας από την πλευρά τους. Η πιθανότητα επιτυχίας είναι 40–60%· το χρονικό περιθώριο απάντησης είναι 24–72 ώρες.

Επιλογή 2—διαχείριση εκδόσεων S3:

Αν τα αρχεία βρίσκονταν στο S3 (ή στο Yandex Object Storage) και ήταν ενεργοποιημένη η διαχείριση εκδόσεων, όλες οι εκδόσεις υπάρχουν φυσικά· απλώς έχουν επισημανθεί ως «διαγραμμένες».

# AWS—λίστα εκδόσεων:
aws s3api list-object-versions --bucket my-bucket --prefix files/

# Επαναφορά έκδοσης:
aws s3api copy-object \
  --bucket my-bucket \
  --copy-source my-bucket/files/data.json?versionId=ABC123 \
  --key files/data.json

Κρίσιμη επιφύλαξη: Το Claude Code δεν διατηρεί τις συνεδρίες για πάντα—παλιά αρχεία JSONL διαγράφονται αυτόματα μετά από αρκετές εβδομάδες. Για να εξασφαλίσετε ότι έχετε ιστορικό JSONL ενός μήνα σε περίπτωση καταστροφής, αντιγράφετε τον φάκελο ~/.claude/projects/ σε εξωτερικό δίσκο μία φορά την εβδομάδα με μια απλή εργασία cron:

# Στο crontab, κάθε Κυριακή στις 03:00:
0 3 * * 0 rsync -av ~/.claude/projects/ /external/claude-history-backup/

Είναι δωρεάν και σας σώζει όταν «έχουν χαθεί τα πάντα, δεν υπάρχει αντίγραφο ασφαλείας και το reflog είναι κενό».

7 κανόνες για να βεβαιωθείτε ότι αυτό δεν θα ξανασυμβεί#

1. Plan Mode πριν από κάθε καταστροφική ενέργεια. Στο Claude Code:

claude --plan

Ο agent δημιουργεί ένα σχέδιο πριν ενεργήσει. Το διαβάζετε, βλέπετε DROP TABLE users και ακυρώνετε. Χωρίς το Plan Mode, ο agent αποφασίζει μόνος του και εκτελεί μέσα σε χιλιοστά του δευτερολέπτου. Μάθετε περισσότερα στον οδηγό Plan Mode στο Claude Code.

2. Hooks ως πρόσθετος ανιχνευτής κινδύνου. Χρησιμοποιήστε δοκιμασμένο PreToolUse hook που διαβάζει συμβάν JSON από stdin και επιστρέφει 2 για εντοπισμένη ενέργεια υψηλού κινδύνου. Το πλήρες παράδειγμα παρακάτω καλύπτει Bash, Write και Edit· δεν είναι όριο ασφάλειας και μπορεί να χάσει έμμεσες ενέργειες. Κρατήστε περιορισμένα δικαιώματα βάσης και sandbox.

3. Χρήστης DB μόνο για ανάγνωση για τον agent. Δημιουργήστε ξεχωριστό χρήστη για τον agent που δεν έχει δικαιώματα DROP, TRUNCATE ή DELETE:

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;

Όταν ο agent χρειάζεται πραγματικά να γράψει, αλλάξτε χειροκίνητα σε διαφορετικό χρήστη. Ένας χρήστης μόνο για ανάγνωση αρκεί για καθημερινές εργασίες (ανάλυση δεδομένων, αναφορές, πίνακες ελέγχου).

4. Αποθηκεύστε στο Git τις αλλαγές που έχετε ελέγξει. Ένα hook PostToolUse στο .claude/settings.json μπορεί να εμφανίζει υπενθύμιση μετά τα Write και Edit:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "printf '%s\\n' 'Ελέγξτε το diff και κάντε χειροκίνητα commit μόνο τα συμφωνημένα αρχεία.' >&2"
          }
        ]
      }
    ]
  }
}

Το παράδειγμα εμφανίζει μόνο υπενθύμιση· δεν προσθέτει αρχεία στο index ούτε δημιουργεί commit. Ελέγξτε το diff και κάντε χειροκίνητα commit μόνο τα συμφωνημένα αρχεία. Το reflog δεν αποθηκεύει αλλαγές που δεν έχουν καταγραφεί σε commit.

5. Έργο sandbox για πειράματα. Μην αφήνετε ποτέ τον agent να εργάζεται σε έργο που περιέχει πραγματικά δεδομένα πελατών. Δημιουργήστε έναν ξεχωριστό φάκελο ~/sandbox-projects/, με αντίγραφο του έργου και συνθετικά δεδομένα. Χρησιμοποιήστε τον για να δοκιμάσετε μια νέα προτροπή, έναν agent ή έναν MCP server. Αν κάτι χαλάσει, δεν θα προκληθεί ζημιά.

6. Στιγμιότυπα δίσκου με restic κάθε ώρα.

# Εγκατάσταση:
brew install restic  # macOS
sudo apt install restic  # Linux

# Δημιουργία αποθετηρίου:
restic init --repo /external/backups

# Δημιουργία αντιγράφου ασφαλείας του τρέχοντος έργου:
restic --repo /external/backups backup ~/projects

# Προγραμματισμός cron κάθε ώρα:
crontab -e
# Προσθήκη:
0 * * * * restic --repo /external/backups backup ~/projects

Επτά ημέρες ωριαίων αντιγράφων ασφαλείας, τέσσερις εβδομάδες ημερήσιων αντιγράφων—και μπορείτε πάντα να επιστρέψετε σε οποιοδήποτε σημείο του παρελθόντος. Είναι δωρεάν και χρειάζονται 10 λεπτά για τη ρύθμιση.

7. Αρχειοθέτηση συνεδριών JSONL του Claude Code. Αναφέρθηκε ήδη παραπάνω, αλλά επαναλαμβάνεται ως ξεχωριστός κανόνας: προγραμματίστε εβδομαδιαίο rsync του ~/.claude/projects/ σε εξωτερικό δίσκο. Είναι δωρεάν και απαιτεί μία γραμμή στο crontab.

Έτοιμα hooks για τον αποκλεισμό επικίνδυνων εντολών#

Συγχωνεύστε την καταχώριση στο .claude/settings.json χωρίς αντικατάσταση υπαρχόντων hooks:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash|Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "python3 \"$CLAUDE_PROJECT_DIR/.claude/hooks/check-risk.py\""
          }
        ]
      }
    ]
  }
}

Δημιουργήστε .claude/hooks/check-risk.py με το ακόλουθο script Python 3:

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 διαβάζει το τεκμηριωμένο συμβάν JSON από stdin, ελέγχει tool_input.command ή tool_input.file_path και επιστρέφει 2 σε αντιστοίχιση. Ελέγχει και Write και Edit. Δοκιμάστε αβλαβές επιτρεπόμενο fixture και μπλοκαρισμένο fixture πριν βασιστείτε σε αυτό και επαληθεύστε ότι ξεκινούν πράγματι Python και διαμορφωμένο script.

Είναι λεκτικός ανιχνευτής: μπορεί να χάσει αναδιατεταγμένες σημαίες, scripts, aliases, συγκαλυμμένες εντολές, άλλα εργαλεία και έμμεσες εγγραφές· μπορεί επίσης να απορρίψει αβλαβή παραδείγματα σε εισαγωγικά. Δεν παραχωρεί ή αφαιρεί δικαιώματα λειτουργικού συστήματος/βάσης. Κρατήστε διαπιστευτήρια παραγωγής έξω από το περιβάλλον agent, χρησιμοποιήστε ρόλο βάσης μόνο για ανάγνωση και επιβεβλημένο sandbox και προστατέψτε τη διαμόρφωση hook από τροποποίηση. Δείτε την επίσημη αναφορά εισόδου hook και κωδικών εξόδου.

Για σκόπιμη εξαιρετική ενέργεια, εξετάστε την και εκτελέστε την έξω από τον agent με κατάλληλο περιορισμένο λογαριασμό. Μια μεταβλητή περιβάλλοντος shell δεν είναι τεκμηριωμένη διεπαφή απενεργοποίησης hook και τα hooks δεν ελέγχουν συνηθισμένες εντολές τερματικού.

Πότε να δίνετε δικαιώματα στην AI (και πότε όχι)#

Η Anthropic τεκμηριώνει τη σημαία --dangerously-skip-permissions (γνωστή και ως λειτουργία YOLO) ως επιλογή για «έμπιστα περιβάλλοντα». Στην πραγματικότητα του 2026, είναι άμεσος δρόμος για μια καταστροφή. Όταν ένας agent δεν χρειάζεται να ρωτήσει, αυτός:

• Εκτελεί οποιαδήποτε εντολή Bash χωρίς επιβεβαίωση
• Γράφει αρχεία χωρίς να ρωτήσει
• Μπορεί να καλέσει έναν υπο-agent, ο οποίος κληρονομεί τη λειτουργία YOLO χωρίς δυνατότητα αναίρεσης

Το τρίτο σημείο είναι το πιο ύπουλο. Αν ξεκινήσετε τον κύριο agent με YOLO, και οι υπο-agent του λειτουργούν με YOLO και δεν μπορείτε να το παρακάμψετε. Μία προτροπή—και ένας καταιγισμός 10 παράλληλων agent μπορεί να κάνει οτιδήποτε στο σύστημά σας.

Κανόνας:

Εναλλακτική—ακριβή δικαιώματα. Στο .claude/settings.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 βλέπει τι επιτρέπεται και τι όχι. Δεν χρειάζεται να πατάτε «ναι» ή «όχι» κάθε φορά—ο agent εργάζεται γρήγορα και εσείς ελέγχετε τα όρια.

Επόμενο: λίστα ελέγχου 7 λεπτών για αποθήκευση στους σελιδοδείκτες#

Λίστα ελέγχου: «Η AI το διέγραψε—τι κάνω;»

1. Σταματήστε αμέσως τον πραγματικό καταστροφικό writer· επαληθεύστε ότι σταμάτησαν παιδικές ή απομακρυσμένες ενέργειες
2. Μην επανεκκινείτε· διατηρήστε άσχετες διεργασίες που κρατούν διαγραμμένα αρχεία ανοιχτά
3. Καταγράψτε χρόνο περιστατικού και στοιχεία εντολών σε ξεχωριστή επαληθευμένη συσκευή
4. Αντιγράψτε σωζόμενα αρχεία, μεταδεδομένα Git και σχετικά logs συνεδριών σε εκείνη τη χωριστή συσκευή
5. Στο διασωσμένο αντίγραφο αποθετηρίου, εξετάστε git reflog --all και ανακτήστε επαληθευμένο commit σε χωριστό worktree
6. Αν το git δεν βοήθησε—git fsck --lost-found
7. Βάση δεδομένων: PITR (AWS/Yandex/Supabase) ή πιο πρόσφατο στιγμιότυπο
8. Αρχεία: Time Machine σε Mac, lsof σε Linux
9. Έσχατη λύση: υποστήριξη παρόχου + διαχείριση εκδόσεων S3
10. Μετά την ανάκτηση, ρυθμίστε τους 7 προληπτικούς κανόνες αυτού του οδηγού

Επόμενο—συστηματική προστασία:

• Plan Mode στο Claude Code—ώστε ο agent να σχεδιάζει πριν από μια καταστροφική ενέργεια
• Hooks στο Claude Code—έτοιμα πρότυπα για τον αποκλεισμό επικίνδυνων εντολών
• Πώς να επαναφέρετε αλλαγές στο Claude Code—αναλυτικός οδηγός για το /rewind, το git και 5 συνήθεις μεθόδους επαναφοράς
• Έλεγχος ασφαλείας στο Claude Code—τακτικοί έλεγχοι ασφάλειας κώδικα

Μεταβείτε στο Ailoot.