Leitplanken

Lernziele

• Du setzt im Vault Berechtigungen, die Schreiben außerhalb des Vaults und Löschen ohne Rückfrage verhindern, und kennst ihre Grenzen.
• Du sicherst jeden Lauf mit Log-Eintrag, Commit und bei großen Aufträgen einem Probelauf ab.
• Du entscheidest, was nicht in den Vault gehört.

Das ganze Kapitel ruht auf einer Regel, die du aus der Lektion Live-Daten anschließen kennst: Schlüssel vor Prompts.

Sagst du einem Agenten, er soll etwas nicht tun, ist das eine Vorliebe, die er technisch übergehen kann. Kann der Agent technisch eine Datei löschen, einen Ordner leeren oder eine Mail senden, tut er es nach unserer Einschätzung irgendwann, in einer Lage, die du nicht vorhergesehen hast.

Leg über die Berechtigungen fest, was überhaupt möglich ist. Dann ist die Anweisung in der CLAUDE.mdCLAUDE.mdDie Anweisungsdatei, die Claude Code zu Beginn jeder Session liest. Claude Code lädt sie aus dem Startordner und aus jedem Ordner darüber und hängt die Inhalte aneinander.Im Glossar eine Vorliebe, die auf einer Grenze aufsetzt. Ohne Grenze wäre sie das Einzige zwischen deinen Notizen und einem schlechten Lauf.

Schreibzugriff begrenzen

Der Agent braucht Schreibrechte für den Vault. Für dein Home-Verzeichnis braucht er keine. Eine geplante Aufgabe mit weiten Dateirechten hat einen großen Schadensradius für einen kleinen Komfort.

Claude Code fragt von sich aus, bevor seine Dateiwerkzeuge außerhalb des Startordners lesen oder schreiben. In einem Lauf ohne Oberfläche beantwortet niemand diese Frage, also wird der Zugriff abgelehnt. Ein Shell-Befehl, den du freigegeben hast, darf allerdings überall schreiben, wo dein Benutzerkonto schreiben darf. Diese Datei als .claude/settings.json im Vault macht zwei Grenzen fest:

{
  "permissions": {
    "blockWritesOutsideWorkingDirectories": true,
    "ask": ["Bash(rm *)", "Bash(git rm *)"]
  }
}

blockWritesOutsideWorkingDirectories lässt Write und Edit jedes Schreiben außerhalb des Vaults verweigern, in jedem Berechtigungsmodus. Die Einstellung gibt es ab Claude Code 2.1.314. Die Regeln unter ask verlangen vor jedem rm und git rm eine Rückfrage. In einem geplanten Lauf kann niemand zustimmen, also löscht er nichts.

Wir haben beide Grenzen in einem Test-Vault mit Claude Code 2.1.322 und claude -p geprüft. Der Versuch, eine Datei außerhalb des Vaults zu schreiben, scheiterte. Beim Löschen kam es auf die geladenen Einstellungen an. Mit --setting-sources project,local, also nur den Einstellungen des Vaults, wurde rm abgelehnt, und die Seite blieb erhalten. Im Lauf davor hatten wir zusätzlich unsere persönlichen Einstellungen und Erweiterungen aus ~/.claude geladen. Dort lief dasselbe rm ohne Rückfrage durch. Laut Dokumentation kann eine installierte Mod einen Aufruf freigeben, für den eine ask-Regel fragen würde. Gib dem geplanten Lauf deshalb nur die Einstellungen des Vaults mit.

Zwei Grenzen haben diese Regeln selbst. Eine Regel für Bash-Befehle trifft laut Dokumentation den Aufruf, den Claude üblicherweise schreibt. /bin/rm oder bash -c 'rm …' fängt sie nicht, und sie ist ausdrücklich keine Sicherheitsgrenze. Die Grenze für Shell-Befehle zieht die Sandbox von Claude Code. Sie läuft unter macOS, Linux und WSL2, ist ab Werk aus und lässt sich mit /sandbox einschalten. Dann schreiben Shell-Befehle nur noch im Arbeitsordner, in einem temporären Ordner und in Ordnern, die du hinzugefügt hast.

Dasselbe Prinzip gilt für Connectors: nur lesen, wo es die Option gibt. Ein Kalender-Connector, der nur lesen kann, sagt keinen Termin ab, egal wie eine Anweisung missverstanden wird. In Team- und Enterprise-Plänen setzen Owner unter Customize › Connectors › Tool permissions einzelne Werkzeuge eines Connectors auf Blocked.

Grenze oder Bitte?

Entscheide für jede Maßnahme, ob sie eine Grenze zieht, die der Agent nicht überschreiten kann, oder ob sie eine Bitte bleibt.

Noch offen (6)

• „Lösch niemals Seiten“ in der CLAUDE.md→ Grenze→ Bitte
• blockWritesOutsideWorkingDirectories in .claude/settings.json→ Grenze→ Bitte
• Kalender-Connector mit reinen Leserechten→ Grenze→ Bitte
• Der Prüf-Hook, der Seiten ohne Frontmatter mit Code 2 blockiert→ Grenze→ Bitte
• „Ändere nur, was zum Auftrag gehört“ im Prompt des Imports→ Grenze→ Bitte
• Die Sandbox für Shell-Befehle, eingeschaltet mit /sandbox→ Grenze→ Bitte

Grenze (0)

Bitte (0)

Prüfen

Nie löschen ohne Eintrag

Löschen ist die eine Operation, die du nicht durch das Lesen eines Diffs rückgängig machst. Der Inhalt ist weg, sichtbar bleibt nur, dass etwas fehlt.

Die Regel: Keine Seite wird gelöscht ohne eine Zeile in log.md, die sie nennt und den Grund sagt. Zusammenführungen zählen als Löschungen. Hältst du das durch, lässt sich jede verschwundene Seite zurückverfolgen. Die Frage „Wo ist die Seite hin?“ hat dann immer eine Antwort.

Git ist das eigentliche Netz

Alle Leitplanken oben wirken vorbeugend. Git rettet dich, wenn eine davon versagt.

Committe vor jedem Lauf, der in großem Umfang schreibt. Geplante Läufe committen ihre Arbeit selbst. Ein schlechter Import ist dann git checkout ., eine schlechte Zusammenführung ist ein git revert.

Lies die Diffs der geplanten Läufe ab und zu, besonders in den ersten Wochen. So lernst du, was dein Agent um 7 Uhr wirklich tut. Das weicht nach unserer Einschätzung verlässlich von dem ab, was du angenommen hast.

Probeläufe

Alles, was viele Dateien berührt, läuft einmal als Probelauf, der nur berichtet.

Do a dry run: list every page you would create, update or delete, and the links
you would add. Write nothing.

Die Ausgabe liest du in einer Minute. Sie fängt missverstandene Anweisungen ab, bevor daraus vierhundert Änderungen werden. Der Befehl /dry-run aus dem Werkzeugkasten des Kurses stellt jedem Auftrag genau diese Anweisung voran.

Ausufernde Aufträge

Agenten dehnen den Auftrag aus. Gebeten zu importieren, räumt ein Agent vielleicht auch eine fremde Seite auf, korrigiert Formatierungen oder benennt etwas einheitlich um. Jede dieser Änderungen lässt sich begründen. Zusammen führen sie dazu, dass du nicht mehr erkennst, was ein Lauf getan hat, ohne alles zu lesen.

Sag es ausdrücklich: Erledige den Auftrag, liste alles andere auf, was dir aufgefallen ist, und ändere nichts davon.

Was nicht in den Vault gehört

Zugangsdaten, API-Keys, alles, was du vertraulich behandeln musst, und private Informationen über andere Menschen.

Der Grund ist die Form des Vaults. Er ist ein Dateibaum, der synchronisiert, committet, gesichert und gelegentlich geteilt wird. Jede Kopie ist ein weiterer Ort, an dem der Inhalt liegt. Mehr dazu im Kapitel Pflege.

Vor dem ersten geplanten Lauf

0 von 8 erledigt

• Die .claude/settings.json im Vault blockiert Schreiben außerhalb des Vaults und verlangt eine Rückfrage vor rm und git rm.
• Der geplante Lauf lädt nur die Einstellungen des Vaults (--setting-sources project,local).
• Jeder Connector hat nur die Rechte, die der Auftrag braucht, Leserechte, wo es geht.
• Die CLAUDE.md verlangt für jede Löschung und Zusammenführung eine Zeile in log.md mit Grund.
• Der Lauf committet seine Arbeit, und der Vault war vorher committet.
• Der Auftrag ist einmal als Probelauf gelaufen, und du hast die Liste gelesen.
• Der Prompt sagt: Auftrag erledigen, Auffälliges auflisten, nichts anderes ändern.
• Im Vault liegen keine Zugangsdaten, Keys oder vertraulichen Daten anderer.

Merksätze

• Eine Anweisung ist eine Vorliebe. Grenzen ziehen Berechtigungen, Hooks, Sandbox und Leserechte bei Connectors.
• blockWritesOutsideWorkingDirectories und ask-Regeln für rm halten einen geplanten Lauf im Vault und vom Löschen ab. Lade dafür nur die Einstellungen des Vaults.
• Bash-Regeln sind keine Sicherheitsgrenze. Für Shell-Befehle ist die Sandbox da, für alles Übrige Git.
• Jede Löschung bekommt eine Zeile im Log. Große Aufträge laufen erst als Probelauf.
• Zugangsdaten und vertrauliche Daten anderer gehören nicht in den Vault.

Prüf dich selbst

Denkfrage

In deiner CLAUDE.md steht „Lösch niemals Seiten“. Warum reicht das für einen geplanten Lauf nicht?

Antwort zeigen

Denkfrage

Ein Import hat dreihundert Seiten verändert, und das Ergebnis ist schlecht. Wie kommst du zurück?

Antwort zeigen

Prüf dich selbst

1. 1Was bewirkt "ask": ["Bash(rm *)"] in einem Lauf mit claude -p und --permission-prompts none?

   rm läuft ohne Rückfragerm wird abgelehnt, weil niemand zustimmen kannDer Lauf bricht komplett ab
   Antwort prüfen
2. 2Welche Lücke hat eine Bash-Regel wie Bash(rm *)?

   Sie greift nur in Claude DesktopSie fängt /bin/rm oder bash -c nichtSie blockiert auch git rm
   Antwort prüfen
3. 3Was zählt nach der Regel dieses Kapitels als Löschung, die eine Zeile im Log braucht?

   Nur das Löschen einer Datei mit rmLöschen und Zusammenführen von SeitenJede Änderung an einer Seite
   Antwort prüfen
4. 4Warum gehören API-Keys nicht in den Vault, auch wenn der Agent sie nie weitergibt?

   Obsidian kann keine Keys speichernDer Vault wird synchronisiert, committet, gesichert und geteilt, jede Kopie enthält den KeyKeys verschlechtern die Suche
   Antwort prüfen

Quellen

1. Configure permissions · Anthropic, Stand: Nov. 2026

   Arbeitsordner als Grenze, blockWritesOutsideWorkingDirectories ab 2.1.314, Bash-Regeln keine Sicherheitsgrenze, Vorrang von Regeln, Hooks und Mods.

2. Sandboxing · Anthropic, Stand: Nov. 2026

   macOS, Linux, WSL2, ab Werk aus, /sandbox.

3. Use connectors to extend Claude’s capabilities · Anthropic, Stand: Nov. 2026

   Tool permissions: Always allow, Needs approval, Blocked.