Claude Code Berechtigungen absichern: Schreibzugriffe außerhalb des Repos blockieren, ablehnen statt nachfragen, settings.local.json prüfen

Name

Soren Atelier

Aktualisiert am 8.11.2026

Die Kurzfassung: Legen Sie das Folgende in .claude/settings.json im Wurzelverzeichnis des Repositorys ab, committen Sie die Datei und starten Sie Claude Code neu. Benötigt wird Claude Code 2.1.319 oder neuer (claude --version, dann claude update).

{
  "permissions": {
    "blockWritesOutsideWorkingDirectories": true,
    "denyInsteadOfPrompting": true,
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Bash(curl *)",
      "Bash(wget *)"
    ]
  }
}

Was Ihnen jede Zeile bringt:

Ich habe die Schreibsperre, die Deny-Regeln und das Verhalten bei unbeaufsichtigten Läufen am 8. November 2026 unter macOS mit Claude Code 2.1.319 getestet, als claude -p --output-format json-Läufe mit dem pro Test gesetzten Berechtigungsmodus. Die exakten Ablehnungsmeldungen sind unten zitiert. Der Changelog (opens in a new tab) beschreibt denyInsteadOfPrompting für Terminal-Sitzungen, Subagenten und Teammates, was ein -p-Lauf ohnehin schon ablehnt, daher stammt seine Beschreibung aus dem Changelog und nicht aus einem Test. Der Rest dieses Leitfadens erklärt, warum diese Einstellungen gerade jetzt wichtig sind, was jede einzelne abdeckt und was nicht, und welche drei Prüfungen Sie einmalig durchführen sollten.

Warum jetzt: drei Vorfälle in neun Tagen

Claude Code hat zwischen dem 26. Oktober und dem 6. November 2026 sieben Releases ausgeliefert, und im selben Zeitraum kamen drei Sicherheitsmeldungen ans Licht. Jede davon lässt sich auf eine konkrete Prüfung zurückführen.

Keiner dieser Punkte wird durch einen Berechtigungsmodus behoben. Es braucht eine Einstellungsdatei, ein Audit und eine Versionsprüfung.

Schritt 1: Dateischreibzugriffe außerhalb des Repositorys blockieren

permissions.blockWritesOutsideWorkingDirectories bringt die drei Dateibearbeitungs-Tools dazu, jeden Pfad abzulehnen, der nicht innerhalb eines Arbeitsverzeichnisses liegt. Die Arbeitsverzeichnisse sind der Ordner, in dem Sie Claude Code gestartet haben, plus alles, was Sie mit /add-dir, --add-dir oder permissions.additionalDirectories in Ihren User- oder Managed-Einstellungen hinzugefügt haben. Ein additionalDirectories-Eintrag in der .claude/settings.json des Repositorys selbst hebt die Sperre nicht auf. Die Sperre gilt in jedem Berechtigungsmodus, einschließlich bypassPermissions, und ein true in einer beliebigen Einstellungsdatei setzt sich gegen ein false an anderer Stelle durch. Ein Repository kann die Sperre also für alle einschalten, die es klonen.

Ich habe den Schlüssel in einem Wegwerfprojekt gesetzt und Claude Code im Modus acceptEdits gebeten, mit dem Write-Tool eine Datei in meinem Home-Verzeichnis anzulegen. Der Aufruf wurde mit dieser Meldung abgelehnt:

/Users/me/kanaries-block-test.txt is outside /path/to/proj; the
permissions.blockWritesOutsideWorkingDirectories setting blocks writes
outside the working directories. Ask the user to add the directory with
/add-dir, or to remove that setting.

Die Datei wurde nicht angelegt, und das JSON-Ergebnis führte den Aufruf unter permission_denials mit tool_name: "Write" auf.

Vier Grenzen, die Sie kennen sollten, bevor Sie sich darauf verlassen:

• Die Sperre beschränkt keine Shell-Befehle, MCP-Tools oder Hook-Programme. echo x > ~/file aus dem Bash-Tool ist kein Write-Aufruf. Um Schreibzugriffe aus der Shell einzuzäunen, schalten Sie die Sandbox ein (siehe den optionalen Abschnitt am Ende).
• Einige von Claude Codes eigenen Dateien bleiben beschreibbar: Plan-Dateien, das Scratchpad der Sitzung, das tmp-Verzeichnis einer Hintergrundsitzung und die Auto-Memory-.md-Dateien des Projekts. Das ist so gewollt.
• Claude kann keine Claude-Code-Einstellungsdatei mehr bearbeiten, auch nicht innerhalb des Repositorys, weil eine Einstellungsdatei die Sperre aufheben könnte. Bearbeiten Sie .claude/settings.json selbst.
• Die Worktree-Tools verschwinden. Ist der Schlüssel gesetzt, entfernt Claude Code EnterWorktree und ExitWorktree oder lehnt Aufrufe davon ab. Wenn Subagenten Worktrees brauchen, fügen Sie .claude/worktrees im Wurzelverzeichnis des Repositorys als Arbeitsverzeichnis hinzu.

Das Gegenstück permissions.blockReadsOutsideWorkingDirectories (ab 2.1.257) tut dasselbe für Read, Grep, Glob und LSP-Aufrufe. Schalten Sie es ein, wenn das Repository den Rest Ihrer Festplatte nicht sehen soll.

Schritt 2: Secrets mit Deny-Regeln unlesbar halten

Eine Read(path)-Deny-Regel blockiert die eingebauten Datei-Tools und, laut Dokumentation, die Dateibefehle, die Claude Code in Bash erkennt (cat, head, tail, sed, tee), plus Shell-Umleitungen, die die Datei benennen. Sie blockiert außerdem Edit und Write auf demselben Pfad, sodass Claude Ihre .env auch nicht überschreiben kann.

Getestet: Mit "deny": ["Read(./.env)"] lieferte die Bitte, .env mit dem Read-Tool zu lesen, Folgendes zurück:

File is in a directory that is denied by your permission settings.

Die Regel reicht auch in die Shell hinein. In einem acceptEdits-Lauf habe ich cat README.md und danach cat .env angefordert: Der erste Befehl gab die Datei aus, der zweite wurde mit Permission to use Bash with command cat .env has been denied. abgelehnt. Ein separater claude -p-Lauf im Standardmodus lehnte curl -sI https://example.com wegen der Regel Bash(curl *) ab. Jede Ablehnung wurde in permission_denials festgehalten, und jeder Lauf lief zu Ende, statt hängen zu bleiben.

Drei Fallen in der Regelsyntax aus der Permissions-Referenz (opens in a new tab):

• Verwenden Sie Read(...) und Edit(...). Regeln wie Write(docs/**), Grep(docs/**) und Glob(...) mit einem Pfad werden akzeptiert, aber nie gematcht.
• Bash(git diff *) mit einem Leerzeichen vor dem * matcht jeden Befehl, der mit git diff beginnt. Bash(git diff*) würde zusätzlich git diff-index matchen.
• Eine Deny-Regel fängt keinen Befehl ab, der eine Datei liest, ohne sie zu benennen, etwa grep -r pattern . aus dem Ordner heraus, der das Secret enthält. Dafür ist die Sandbox da.

Eine .claudeignore-Datei hat keine Wirkung. Übertragen Sie ihre Einträge in Read-Deny-Regeln.

Schritt 3: Nie an einer Berechtigungsabfrage hängen bleiben

Es gibt inzwischen vier Wege, einen unbeaufsichtigten Claude-Code-Lauf ablehnen statt warten zu lassen. Wählen Sie danach, wo der Lauf stattfindet.

Getestet mit --permission-mode dontAsk --permission-prompts none: python3 -c 'print(2+2)' wurde mit einer Meldung abgelehnt, die mit Permission to use Bash has been denied because Claude Code is running in don't ask mode beginnt, während git log --oneline -1 lief, weil der Befehl auf der eingebauten Liste der Nur-Lese-Befehle steht. Das Ergebnis-JSON enthielt einen Eintrag unter permission_denials.

Dinge, die kein Modus und keine Allow-Regel freigeben kann, nicht einmal bypassPermissions: explizite ask-Regeln, das Tool AskUserQuestion, MCP-Tools mit der Markierung requiresUserInteraction, und erkannte rm-Befehle auf kritische Pfade wie rm -rf ~. dontAsk lehnt sie alle direkt ab und lehnt außerdem Lesezugriffe auf Netzwerkpfade ab, selbst wenn eine Allow-Regel matcht.

Wenn ein Repository nie im Bypass-Modus laufen soll, fügen Sie "disableBypassPermissionsMode": "disable" unter permissions hinzu. Claude Code weist dann --dangerously-skip-permissions zurück und ignoriert eine Subagent-Definition, die Bypass anfordert.

Schritt 4: settings.local.json auf geleakte Allow-Regeln prüfen

Hier ist der Mechanismus hinter dem Apiiro-Bericht. Wenn Claude fragt, ob es einen Shell-Befehl ausführen darf, und Sie Yes, and don't ask again wählen, speichert Claude Code eine allow-Regel mit diesem Befehlspräfix in .claude/settings.local.json im Wurzelverzeichnis des Repositorys. War der Befehl psql postgres://app:Sup3rSecret@db/prod -c ..., steht das Passwort jetzt in der Regel.

Claude Code trägt **/.claude/settings.local.json in Ihre globale Git-Excludes-Datei ein, sobald es die Datei zum ersten Mal in einem Repository schreibt, das sie noch nicht ignoriert. Auf meinem Mac ist das die Datei ~/.config/git/ignore, und das Muster steht in Zeile 1. Deshalb scheitert git add .claude/settings.local.json hier mit „ignored by one of your .gitignore files“. Der Schutz gilt aber pro Maschine, nicht pro Repository. Eine Datei, die Sie von Hand angelegt haben, bevor Claude Code je hineingeschrieben hat, ein Repository, das als Verzeichnis statt per Klon auf eine andere Maschine kopiert wurde, oder eine Sandbox ohne Ihre globalen Excludes committen die Datei wie jede andere. Der Autor von Apiiro sagte auf HN, dass in 539 von 1.105 zurückverfolgten Repositorys ein von Claude mitverfasster Commit die Datei geändert hat.

Führen Sie das Folgende im Wurzelverzeichnis des Repositorys aus. Es findet jede .claude/settings*.json, meldet, ob Git die Datei verfolgt, und markiert Allow-Regeln, die Zugangsdaten enthalten oder ganze Tool-Familien freigeben.

cat > /tmp/claude-settings-audit.sh <<'EOF'
#!/usr/bin/env bash
set -u
root="${1:-.}"
found=0
while IFS= read -r -d '' f; do
  found=1
  echo "== $f"
  if git -C "$(dirname "$f")" ls-files --error-unmatch "$(basename "$f")" >/dev/null 2>&1; then
    echo "   TRACKED BY GIT  <- settings.local.json should never be"
  fi
  grep -nE '"(Bash|PowerShell)\([^"]*(password|passwd|token|secret|api[_-]?key|Authorization|Bearer |PGPASSWORD|AWS_SECRET|--password|://[^"/]*:[^"@]*@|[A-Z_]{3,}=[^[:space:]"]{8,})' "$f" \
    | sed 's/^/   SECRET-LIKE: /'
  grep -nE '"(Bash|PowerShell)(\(\*\))?"|"Bash\((sudo|rm|curl|wget|ssh|scp|git push|npm publish|docker)[^"]*\*\)"' "$f" \
    | sed 's/^/   BROAD: /'
done < <(find "$root" -path '*/node_modules' -prune -o -type f \
  \( -name 'settings.local.json' -o -name 'settings.json' \) -path '*/.claude/*' -print0 2>/dev/null)
[ "$found" = 0 ] && echo "No .claude/settings*.json under $root"
EOF
bash /tmp/claude-settings-audit.sh .

Auf einer synthetischen Datei mit sechs Regeln markierte es die drei, die ein Datenbankpasswort, ein Bearer-Token und eine DATABASE_URL=...-Zuweisung enthielten, plus Bash(*), Bash(rm -rf *) und die curl-Regel ein zweites Mal unter BROAD. Als die Datei in einem Test-Repository committet war, gab es außerdem die Zeile TRACKED BY GIT aus. Es ist ein grep, rechnen Sie also damit, die Treffer selbst durchzulesen.

Was bei einem Treffer zu tun ist:

1. Rotieren Sie zuerst die Zugangsdaten. Wurde die Datei je gepusht, behandeln Sie das Secret als öffentlich. Die History umzuschreiben reicht nicht mehr, sobald ein Fork oder ein Scraper sie hat.
2. Löschen Sie die Regel oder ersetzen Sie sie durch eine ohne das Secret: Geben Sie psql * frei und übergeben Sie das Passwort über PGPASSWORD aus Ihrer Shell-Umgebung, nicht innerhalb des Befehls.
3. Wenn Git die Datei verfolgt, führen Sie git rm --cached .claude/settings.local.json aus und tragen Sie .claude/settings.local.json in die .gitignore des Repositorys ein, damit der Schutz mit dem Repository mitreist, statt von den globalen Excludes jeder einzelnen Maschine abzuhängen.
4. Prüfen Sie auch .claude/settings.json. Diese Datei ist zum Committen gedacht, eine Allow-Regel mit einem Secret darin ist also ein Leak mit Ansage, kein Versehen.

Aus demselben Grund gehören in die committete Datei bevorzugt deny- und ask-Regeln, während persönliche allow-Regeln lokal bleiben. Deny- und Ask-Regeln gelten sofort; Allow-Regeln aus einem Repository gelten erst, nachdem jedes Teammitglied dem Ordner vertraut hat.

Schritt 5: IDE-Erweiterung und SSH-Schlüssel prüfen

Die mit einer Backdoor versehenen Builds waren die Versionen 2.1.312 und 2.1.313 der Erweiterung Claude Code for VS Code, verteilt über den Cursor Marketplace, gemeldet von Phorion am 30. Oktober. Cursor hat sie entfernt. Laut Phorion läuft die Payload, sobald das Erweiterungsmodul geladen wird, hängt einen Ed25519-Schlüssel mit dem Kommentar svc-telemetry an ~/.ssh/authorized_keys an, versucht Remote Login zu aktivieren und sendet Host-Informationen an einen Beacon. Unter macOS scheitert der Schritt zum Aktivieren von SSH bei einem Nutzer ohne Admin-Rechte wegen eines Fehlers im Implantat, aber Schlüssel und Persistenz werden trotzdem abgelegt.

Installierte Versionen auflisten:

cursor --list-extensions --show-versions | grep -i claude
code --list-extensions --show-versions | grep -i claude
ls ~/.cursor/extensions ~/.vscode/extensions 2>/dev/null | grep -i claude

Auf meiner Maschine lieferte das anthropic.claude-code@2.1.302, was außerhalb des betroffenen Bereichs liegt. Prüfen Sie dann den von Phorion veröffentlichten Indikator:

grep -n "svc-telemetry" ~/.ssh/authorized_keys 2>/dev/null || echo "no match"

Phorion weist darauf hin, dass der Kommentar-String vom Angreifer kontrolliert wird, ein sauberes grep ist also kein Beweis. Wenn Sie 2.1.312 oder 2.1.313 aus dem Cursor Marketplace ausgeführt haben, entfernen Sie jeden Schlüssel aus authorized_keys, den Sie nicht kennen, prüfen Sie Login Items und Launch Agents und behandeln Sie die Maschine als kompromittiert, bis eine Incident Response sie angesehen hat. Installieren Sie die Erweiterung aus dem VS Code Marketplace oder lassen Sie die claude-CLI sie per /ide installieren; seit 2.1.318 installiert oder aktualisiert Claude Code die Erweiterung nicht mehr eigenständig aus einem IDE-Terminal heraus.

Schritt 6: Der Fix für die E-Mail im User-Agent

Issue #107757 berichtet, dass Claude Code die E-Mail-Adresse des Accounts im User-Agent-Header von Web-Anfragen bei Suchen und Abrufen gesendet hat, sodass Websites und Tracker sie einsammeln konnten. Der Changelog-Eintrag zu 2.1.317 vom 3. November lautet: „Added a check that asks before a web or shell tool call sends your account email address to the network.“ Der Melder hat das Issue unter 2.1.318 eingereicht, und am 8. November war es mit fast 1.000 Reaktionen weiterhin offen. Behalten Sie es also für die endgültige Lösung im Blick.

Was Sie heute tun können: aktualisieren (claude update), und wenn Sie unbeaufsichtigt laufen lassen, wissen Sie, dass diese neue „fragt nach“-Prüfung mit denyInsteadOfPrompting oder dontAsk zu einer Ablehnung wird. Genau das Verhalten, das Sie wollen.

Was jede Schutzmaßnahme stoppt: getestet vs. dokumentiert

„Getestet“ bedeutet, dass ich es am 8. November 2026 mit 2.1.319 ausgeführt habe. Alles andere stammt aus den in diesem Leitfaden verlinkten offiziellen Docs.

Optional: auch die Shell in die Sandbox

Die Einstellungen oben zäunen Claudes eigene Datei-Tools ein. Shell-Befehle werden von der Bash-Sandbox (opens in a new tab) eingezäunt, die standardmäßig aus ist. Sie nutzt macOS Seatbelt und braucht unter Linux oder WSL2 bubblewrap und socat. Schalten Sie sie für ein Projekt mit /sandbox innerhalb einer Sitzung ein oder für alle Projekte, indem Sie Folgendes in ~/.claude/settings.json eintragen:

{
  "sandbox": {
    "enabled": true
  }
}

Um zu bestätigen, dass sie funktioniert, bitten Sie Claude, touch ~/sandbox-probe auszuführen. Innerhalb der Sandbox scheitert das mit Operation not permitted unter macOS oder Read-only file system unter Linux. Wenn Claude anbietet, den Befehl außerhalb der Sandbox erneut zu versuchen, lehnen Sie ab.

Ein kombiniertes Setup schließt die Lücke in der Matrix oben: Datei-Tools eingezäunt durch blockWritesOutsideWorkingDirectories, Shell eingezäunt durch die Sandbox, Secrets eingezäunt durch Read-Deny-Regeln und unbeaufsichtigte Läufe eingezäunt durch denyInsteadOfPrompting. Der Bypass-Modus beschleunigt dann nur noch die verbleibenden Abfragen. Wenn Sie Bypass für eine abgegrenzte Aufgabe trotzdem brauchen, behandelt der Leitfaden zu Bypass permissions den Schalter und seine Fehlermeldungen.

FAQ

Verwandte Guides

• Claude Code Desktop: Bypass permissions aktivieren
• Claude Code Mods Tutorial: Eigenen Mod erstellen und testen
• Claude Code Routines: KI-Cronjobs für Agenten
• Parallel Code Agents erklärt: Worktrees, Sandboxes und Alternativen
• OpenCode 2.0 Upgrade: v1-Konfiguration, Plugins und Sessions migrieren