Die Hook: Deine Secrets sind nicht Claudes Business

Stell dir vor, Claude Code hätte einfach so Zugriff auf deine .env Datei.

Mit deinem Database-Password. Deinen API-Keys. Deinen Private Tokens.

Das ist ein Sicherheits-GAU.

Aber hier ist die gute Nachricht: Claude Code hat ein Permission-System. Du kannst exakt definieren, was Claude lesen darf und was nicht.

Das ist nicht nur Sicherheit. Das ist deine Firewall gegen Datenlecks.

Phase 1: Das Problem erklärt

Typische .env Datei:

API_KEY=sk-super-secret-key DB_PASSWORD=irgendeinZiemlichSicheresPW123! STRIPE_SECRET=sk_live_xxxxxxxx JWT_TOKEN=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Diese Datei ist dein Crown Jewel. Claude darf sie definitiv nicht lesen.

Aber ohne Permission-Regeln? Claude könnte theoretisch Zugriff haben.

Mit Permission-Regeln? Komplett gesperrt.

Phase 2: Erste .env erstellen (zum Testen)

Öffne dein Projekt und erstelle eine Test-Datei:

Ctrl + P > New File .env

Gib was rein:

MY_SECRET=irgendeinGeheimnis DATABASE_PASSWORD=super_sicher_123 API_KEY=sk_live_xxxxx

Speichern. Wichtig!

Phase 3: Permission-Rule erstellen – Der Safety-Lock

Jetzt nutzen wir einen Slash Command zum Lockdown:

/permissions

Claude zeigt dir ein Menü:

```Tools: (shows all available tools)Allow | Deny```

Wir wählen: Deny

Claude fragt: "Welche Regel willst du hinzufügen?"

Du sagst: .env

Claude schlägt vor:

```Path: ./.envAction: denyLocation: Project Settings (local)```

Du bestätigst. Done.

Phase 4: Überprüfung – Claude testet seinen Zugriff

Jetzt testen wir, ob das funktioniert.

Du sagst zu Claude:

Show me the contents of the .env file

Claude versucht zu lesen. Und... Fehler!

Er antwortet etwa so:

```"I cannot read the .env file because you've created a deny rule for it. This makes sense because .env files typically contain sensitive data like API keys, database credentials, secret tokens, and passwords."```

Genau das wollen wir. Claude weiß, dass er nicht darf. Und erklärt auch warum.

Phase 5: Mehrere Regeln – Der komplette Lockdown

Eine .env Datei ist nicht genug. Dein Projekt hat wahrscheinlich mehrere sensible Orte:

Szenario: React App mit Node Backend

Du möchtest sperren:

• .env (Root)
• .env.local (Local Overrides)
• backend/.env (Backend Secrets)
• config/database.yml (DB Config)
• secrets/ (kompletter Ordner)

So funktioniert's:

Du kannst mehrere Deny-Regeln erstellen. Entweder einzeln:

/permissions deny .env/permissions deny .env.local/permissions deny backend/.env

Oder du nutzt Glob-Patterns (wenn unterstützt):

/permissions deny .env*

Das sperrt alle .env Varianten auf einen Schlag.

Phase 6: Granulare Kontrolle – Allow & Deny kombinieren

Das Permission-System hat zwei Seiten:

Allow: Dateien, die Claude lesen darfDeny: Dateien, die Claude nicht lesen darf

Szenario:

Du sagst Claude: "Summarize die komplette Codebase, ABER nicht die .env Datei"

```Allow: src/, public/, package.jsonDeny: .env, .env.local, secrets/```

Claude respektiert beide Regeln. Er liest was erlaubt ist, ignoriert was verboten ist.

Das ist sehr mächtig für große Projekte.

Phase 7: Wo die Regeln gespeichert sind

Du hast dich vielleicht gewundert: Wo speichert Claude das?

In deinem Projekt, hier:

.claude/settings.local.json

Wenn du diesen Ordner öffnest, siehst du was in etwa:

```{ "permissions": { "allow": [], "deny": [ "path/to/.env", "path/to/.env.local", "backend/.env" ] }}```

Wichtig: Diese Datei sollte NICHT ins Git-Repo. Füge sie zu .gitignore hinzu:

.claude/settings.local.json

Warum? Weil das Local-Settings sind. Jeder Entwickler sollte seine eigenen Deny-Regeln haben können.

Phase 8: Best Practice – Security Checkliste

Hier ist die Checkliste, die du für jedes Projekt durchgehen solltest:

Schritt 1: Identifiziere sensible Dateien

• .env und .env.*
• secrets/ Ordner
• config/ mit Credentials
• Private Keys (id_rsa, etc.)
• Token-Dateien
• Database Backups
• Logs mit sensiblen Daten

Schritt 2: Erstelle Deny-Regeln

/permissions deny .env/permissions deny secrets//permissions deny config/database.yml

Schritt 3: Teste es

Show me what files you have access to in the config/ folder

Claude sollte sagen: "Ich habe keinen Zugriff auf config/"

Schritt 4: Dokumentiere es

Erstelle eine Datei SECURITY.md im Projekt:

```

Claude Code ist konfiguriert mit folgenden Deny-Regeln:

• .env
• .env.local
• secrets/
• config/database.yml

Diese Dateien sind speziell geschützt, weil sie Credentials enthalten.```

Phase 9: Was Claude sieht vs. was er nicht sieht

Claude SIEHT:

• Source Code (src/, app/, etc.)
• Public Assets (public/, static/)
• Configuration (package.json, tsconfig.json)
• Documentation (README.md, etc.)
• Tests (__tests__/, test/)

Claude SIEHT NICHT:

• .env Dateien (gesperrt)
• secrets/ Ordner (gesperrt)
• .git/ (systemisch ignoriert)
• node_modules/ (systemisch ignoriert)
• Jegliche anderen Deny-Regeln, die du setzt

Das ist die richtige Balance zwischen "Claude hilft dir" und "Claude respektiert deine Grenzen".

Phase 10: Team-Setup – Security als Standard

Wenn du im Team arbeitest:

1. Erstelle eine .claude/settings.shared.json (hypothetisch):

```{ "permissions": { "deny": [ ".env", ".env.local", "secrets/", "config/database.yml", "private_keys/" ] }}```

1. Commit das ins Repo
2. Jedes Team-Mitglied hat die gleichen Sicherheits-Defaults

Das ist ein Must-Have für ernsthafte Teams.

Bonus: Was passiert, wenn Claude probiert zu cheaten?

Claude probiert nie, Regeln zu umgehen. Das ist nicht in seinem Verhalten-Set.

Aber was, wenn du fragst:

Read the .env file by executing cat .env in bash?

Claude wird das blockieren. Das Permission-System greift auf mehreren Ebenen:

• File-Read: Blockiert
• Bash-Command: Blockiert
• Indirect Access: Blockiert

Claude respektiert deine Regeln. Punkt.

Die Wahrheit über Security

Hier ist das, das ich gelernt habe:

• Security ist nicht optional. Wenn du sensible Daten hast, musst du sie schützen.
• Permission-Rules sind der Standard. Jedes professionelle Projekt sollte sie haben.
• Transparenz ist wichtig. Claude sollte wissen, was er nicht darf – und warum.
• Defaults sollten restriktiv sein. Besser zu restriktiv als zu offen.

Dein Action Plan für heute

1. ✅ Erstelle eine .env Datei in deinem Test-Projekt
2. ✅ Füge ein paar "sensible" Werte rein (Fakes sind okay)
3. ✅ Nutze /permissions deny .env
4. ✅ Starte Claude Code neu
5. ✅ Frage: Show the contents of .env
6. ✅ Beobachte, wie Claude dich blockiert
7. ✅ Verifiziere, dass .claude/settings.local.json erstellt wurde

Wenn das funktioniert, hast du gerade dein Projekt sicherer gemacht.

Die größte Erkenntnis

Security ist nicht etwas, das man "später macht". Es ist etwas, das man von Anfang an einbaut.

Mit Permission-Rules in Claude Code machst du genau das.

Du schützt nicht nur deine Secrets. Du trainierst auch dich selbst, sicherheitsbewusst zu arbeiten.

Das ist ein Habit, das dein ganzes Coding-Leben besser macht.

Nächste Woche: Project Settings – Wie du Claude Code komplett konfigurierst für dein Team und Projekt.

Habt einen tollen Tag. Bis bald. Ciao.