KI-Coding

Claude-Code-Berechtigungen: .env, Git und gefährliche Befehle schützen

Eine praxisnahe Anleitung für minimale Claude-Code-Berechtigungen: Geheimnisse isolieren, Git- und Shell-Befehle kontrollieren und Sicherheitsgrenzen vor dem Einsatz im Produktiv-Repository testen.

BetterToken

Redaktion

20. Aug. 20263 Min. Lesezeit

Bei der Einrichtung von Claude Code stehen Entwickler oft vor derselben falschen Wahl: Jede harmlose Leseoperation einzeln bestätigen oder den vollständigen Bypass (--dangerously-skip-permissions) aktivieren und damit Lecks aus .env, ein versehentliches git push --force oder ein beschädigtes Projektumfeld riskieren.

Keine der beiden Extreme ist sinnvoll. Sicheres Arbeiten folgt dem Prinzip der minimalen Rechte: Lesezugriffe, Schreibrechte, Shell-Aufrufe und Versionskontrolle müssen klar voneinander getrennt sein.

1. Berechtigungskarte: vom Lesen bis zu externen Auswirkungen

Teilen Sie Dateien und Befehle in vier Zugriffsebenen ein:

Ebene	Vorgänge	Standardrichtlinie	Beispiele
1. Code lesen	Projektdateien ansehen	Erlaubt (ohne Bestätigung)	`cat`, `grep`, Quellcode in `src/` lesen
2. Geheimnisse und Umgebung	Zugriff auf `.env`, Schlüssel, Tokens	Strikt verboten	`.env`, `id_rsa`, `.pem`, `credentials.json`
3. Dateien ändern	Code erstellen und bearbeiten	Innerhalb des Workspace erlaubt	`write_to_file`, `replace_file_content`
4. Gefährliche Shell- und Git-Befehle	Paketmanager, destruktive Operationen	Manuelle Freigabe erforderlich	`rm -rf`, `git push --force`, `npm publish`, `DROP TABLE`

2. `.env`-Dateien und Projektgeheimnisse isolieren

Transport Layer Security (TLS) verschlüsselt API-Traffic auf dem Übertragungsweg. Sie verhindert aber nicht, dass vertrauliche Zugangsdaten im Kontextfenster des Modells, in Fehlerprotokollen oder in Handoff-Zusammenfassungen landen.

Damit Claude Code keine privaten Zugangsdaten einliest:

Nehmen Sie alle Umgebungsdateien mit Geheimnissen in .gitignore auf.
Legen Sie eine saubere Vorlage .env.example mit Platzhalterwerten an. So kennt der Agent die Variablennamen, ohne Laufzeitwerte zu sehen.
Halten Sie eine harte Grenze in CLAUDE.md oder AGENTS.md fest:

Regel zum Schutz von Geheimnissen

Inhalte aus .env, .env.local oder privaten Schlüsseldateien niemals prüfen, ausgeben oder weiterreichen.
Um erforderliche Konfigurationsschlüssel zu prüfen, .env.example verwenden.



> [!IMPORTANT]
> **Umgang mit API-Schlüsseln**: Ihr Claude-Code-API-Key wird in Ihrer lokalen Umgebung konfiguriert und darf nie in Repository-Dateien eingecheckt werden. Folgen Sie dem sicheren Einrichtungsablauf in der [BetterToken-Dokumentation für Claude Code](https://docs.bettertoken.ai/ai-tools/claude-code).

---

3. Priorisierte Checkliste für Git und Befehle

Prüfen Sie bei Aufgaben mit Claude Code zuerst diese Reihenfolge:


Agent schlägt einen Befehl vor
  │
  ├─> Enthält er destruktive Muster (rm -rf, drop, force push)?
  │     └─> JA: Ablehnen oder unter Entwickleraufsicht manuell ausführen
  │
  └─> Betrifft er .git-Interna, .env-Dateien oder externe Netzwerke?
        │
        ├─> JA: Ausdrückliche Begründung verlangen und Umfang begrenzen
        │
        └─> NEIN: Ausführung im Ziel-Branch freigeben

Schutzmaßnahmen Schritt für Schritt

Schritt 1: Git-Änderungen sperren. Direkte automatisierte Pushes nach main erst nach einem manuellen git diff --check und einem Testlauf zulassen.
Schritt 2: Paketinstallationen isolieren. Befehle wie npm install <package> oder externe curl-Skripte müssen manuell geprüft werden, damit keine unzuverlässigen Abhängigkeiten oder Supply-Chain-Risiken übernommen werden.
Schritt 3: Verzeichnisumfang begrenzen. Beschränken Sie den Agent-Workspace auf einen konkreten Feature-Ordner oder einen eigenen Git-Worktree.

4. Berechtigungen in einem Test-Workspace validieren

Bevor Claude Code Zugriff auf wichtige Repositories erhält, prüfen Sie die Sicherheitsgrenzen in einer Sandbox:

Legen Sie einen temporären Test-Branch an: git checkout -b test/permission-check.
Fügen Sie eine Dummy-Datei .env mit einem erfundenen Testgeheimnis hinzu.
Bitten Sie den Agenten, das Authentifizierungsmodul zu refaktorieren.
Prüfen Sie anschließend:
- Der Agent hat die Dummy-Datei .env bei der Erkundung nicht gelesen;
- Keine Geheimnisse sind in Fehlerprotokolle, Kommentare oder git diff gelangt;
- Unit-Tests laufen ohne Zugriff auf nicht freigegebene Dateien.
Entfernen Sie den Test-Branch, sobald die Grenzen bestätigt sind.

Diese klaren Berechtigungsgrenzen schützen Zugangsdaten und lassen trotzdem zügiges, autonomes Arbeiten zu.

Bereit, Ihren LLM-Workflow zu optimieren?

Verbinden Sie Modelle über eine API, verwalten Sie Schlüssel und behalten Sie KI-Kosten im Blick.