Claude Code 2.1.268: Was bei deny-Regeln und MCP behoben wurde

Claude Code Version 2.1.268 wurde am 10. September 2026 veröffentlicht, am nächsten Tag folgte 2.1.269. Sie sollten sofort aktualisieren: In zwei Fällen waren Ablehnungsregeln, mit denen Sie den Zugriff des Agenten auf .env- und Dienstordner blockieren, stillschweigend wirkungslos. Außerdem konnte der Befehl /mcp Geheimnisse aus Ihren Konfigurationen im Terminal ausgeben.

Alles Folgende basiert auf dem offiziellen Changelog und der Dokumentation von Anthropic in ihrem Stand vom 17. September 2026, dem Datum des Ausgangsmaterials. Die neueste Version an diesem Tag war 2.1.274. Wir beschreiben anhand dieser Einträge, wie die Fehler funktionierten; die Umgehungen wurden auf der anfälligen Version nicht reproduziert.

Weitere Anleitungen zur Arbeit mit Ailoot finden Sie in der Dokumentation.

Was wurde in Claude Code 2.1.268 und 2.1.269 behoben?#

Vier Korrekturen betreffen Berechtigungsregeln:

1. Ablehnungen bei Symlinks funktionierten nicht. Regeln für deny und ask für Verzeichnisse mit Symlinks (/etc, /tmp, /var unter macOS, /bin unter Linux) wurden nicht ausgelöst, wenn ein Pfad über seinen tatsächlichen Speicherort angegeben wurde. Bash-Befehle ignorierten ebenfalls Ablehnungsregeln für einen Pfad über einen Symlink.
2. Die Ablehnung beim Lesen und Bearbeiten versagte zusammen mit env -C oder eval. Wenn dieselbe Befehlszeile einen Ausdruck enthielt, den die Berechtigungsprüfung nicht analysieren konnte, wurde deny für Read oder Edit möglicherweise nicht ausgelöst.
3. Eine Regel mit „!“ galt weiter als beabsichtigt. Eine deny- oder ask-Regel, die mit ! begann, galt über die Einstellungsdatei hinaus, in der sie geschrieben war. Jetzt gilt sie nur noch innerhalb ihrer eigenen Quelle, und ein alleinstehendes Negationszeichen ! wird ignoriert.
4. tee umging die Ablehnungen beim Schreiben. Regeln für deny bei Edit() und die Schreibpfadprüfung wurden nicht auf eine Datei angewendet, die der Bash-Befehl tee erstellte. Die Berechtigung Bash(tee:*) gilt nicht mehr für Schreibvorgänge außerhalb von Arbeitsverzeichnissen.

Diese Versionen behoben auch zwei Probleme mit der Offenlegung von Geheimnissen. WebFetch wartet nicht mehr unbegrenzt auf eine Antwort von einem Server, der die Verbindung offen hält: Die Anfrage schlägt nun nach 300 Sekunden fehl, und das Timeout lässt sich mit der Variable CLAUDE_CODE_WEBFETCH_DEADLINE_MS konfigurieren. Außerdem wurde die anhaltend hohe CPU-Auslastung in langen Leerlaufsitzungen behoben.

Wie funktionieren Ablehnungen in Claude Code?#

Claude Code hat drei Regellisten: deny (immer verboten), ask (vor der Aktion nachfragen) und allow (ohne Bestätigung erlaubt). Wenn der Agent etwas tun will, werden die Regeln genau in dieser Reihenfolge geprüft. Ein passendes deny hebt jedes allow für dieselbe Aktion auf: Eine erlaubende Regel kann keine Ausnahme von einer Ablehnung machen.

Regeln werden an drei Stellen gespeichert: Benutzerregeln in ~/.claude/settings.json, Projektregeln in .claude/settings.json im Repository und lokale Regeln in .claude/settings.local.json. Hier ein Beispiel für Einstellungen, die das Lesen einer Datei mit Schlüsseln ablehnen:

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)",
      "Bash(rm *)"
    ]
  }
}

Mit /permissions in einer Sitzung sehen Sie alle aktiven Regeln und aus welcher Datei jede davon stammt. Wenn eine Regel das Lesen blockiert, nennt die Ablehnung diese Regel; das hilft bei der folgenden Prüfung.

Welche Fehler betrafen Ablehnungen und den Geltungsbereich von Regeln?#

Die Fehler betrafen Pfad- und Befehlsprüfungen sowie den Geltungsbereich von Regeln aus verschiedenen Einstellungsdateien.

Erster Fall: Symlinks. Unter macOS sind /etc, /tmp und /var Symlinks auf tatsächliche Ordner unter /private; unter Linux ist /bin häufig ein ähnlicher Symlink. Wenn Sie eine Ablehnungsregel für eine Schreibweise eines Pfads festgelegt hatten, der Agent aber mit einer anderen darauf zugriff (zum Beispiel über den tatsächlichen Speicherort statt den Symlink), wurde die Regel nicht ausgelöst. Bash-Befehle ignorierten ebenfalls eine Ablehnung für einen Pfad über einen Symlink. In 2.1.268 wurden beide Fälle behoben: Die Regel gilt nun unabhängig davon, welche Schreibweise des Pfads verwendet wurde.

Zweiter Fall: env -C und eval in derselben Zeile. Die Berechtigungsprüfung analysiert einen Befehl, um festzustellen, auf welche Dateien er zugreift. Ausdrücke wie env -C oder eval kann sie nicht analysieren. Der Fehler bestand darin, dass deny für Read oder Edit möglicherweise nicht angewendet wurde, wenn ein solcher Ausdruck in der Zeile vorkam. Dadurch konnte der Befehl die Ablehnung beim Lesen oder Bearbeiten einer geschützten Datei umgehen.

Dritter Fall: Eine Regel mit „!“ galt über ihre Grenzen hinaus. Eine Regel, die mit ! beginnt, sollte nur innerhalb der Einstellungsdatei gelten, in der sie geschrieben ist. Vor 2.1.269 galt sie auch für andere Einstellungsquellen. Jetzt ist ihr Geltungsbereich auf die eigene Datei beschränkt, und eine Regel, die nur aus ! besteht, wird ignoriert.

Vierter Fall: Schreiben mit tee. Der Bash-Befehl tee kann in eine Datei schreiben. Die Schreibpfadprüfung und deny-Regeln für Edit() wurden auf diese Datei nicht angewendet. Gleichzeitig erlaubte die Berechtigung Bash(tee:*) Schreibvorgänge außerhalb von Arbeitsverzeichnissen. In 2.1.269 wurden diese Prüfungen auf Schreibvorgänge mit tee angewendet: Eine Ablehnung für die Datei greift, und Bash(tee:*) gilt nur für Arbeitsverzeichnisse.

Wenn Sie gezielte Ablehnungen verwenden, um .env, einige Dienstordner oder gefährliche Befehle zu blockieren, sollten Sie auch diese prüfen. Die Schritte folgen weiter unten.

Warum konnte /mcp Ihre Schlüssel anzeigen?#

MCP-Serverkonfigurationen speichern Schlüssel häufig in Umgebungsvariablen und verweisen über ${VAR} darauf, damit die Datei in einem Repository gespeichert werden kann, ohne die Geheimnisse selbst darin abzulegen. Das Problem war, dass Anzeige-Befehle (/mcp, /plugin, claude mcp list, claude mcp get) und MCP-Anmeldefehlermeldungen die Konfiguration mit bereits eingesetzten Werten anzeigten. Der Schlüssel selbst war auf dem Bildschirm zu sehen.

Eine weitere Korrektur betrifft Plugin- und Marketplace-Fehler: Sie konnten ein Token oder Passwort aus der Quell-Git-URL anzeigen.

Wenn die Ausgabe von /mcp oder claude mcp list in einer älteren Version in einem Stream, einem Screenshot, einer Nachricht an einen Kollegen oder einem Protokoll auftauchte, das Ihren Rechner verlassen hat – auch automatisch –, gehen Sie davon aus, dass die Schlüssel aus Ihren MCP-Konfigurationen offengelegt wurden, und wechseln Sie sie. Wenn die Ausgabe Ihren Rechner nie verlassen hat, reicht ein Update. Eine separate Anleitung zu MCP-Servern und vorgefertigten Setups finden Sie hier: Claude Code MCP-Server.

Weitere Änderungen in diesen Versionen#

WebFetch und Artefakte. Zuvor galt eine WebFetch-Regel ohne Details in deny oder ask auch für das Lesen und Ändern veröffentlichter Artefakte. Ab 2.1.268 gilt sie dafür nicht mehr. Um Artefakte zu blockieren, benötigen Sie eine separate Artifact-Regel oder eine Regel für die Domain, zum Beispiel WebFetch(domain:claude.ai). Wenn Sie sich auf eine allgemeine WebFetch-Ablehnung gestützt haben, um vor dem Lesen von Artefakten zu schützen, prüfen Sie Ihre Einstellungen erneut: Die bisherige Regel blockiert diese Aktionen nicht mehr.

WebFetch hat jetzt ein Timeout. Eine Anfrage an einen Server, der die Verbindung offen hält und seine Antwort nicht beendet, schlägt jetzt nach 300 Sekunden fehl. Zuvor konnte eine solche Anfrage unbegrenzt hängen. Das Verhalten lässt sich mit der Variable CLAUDE_CODE_WEBFETCH_DEADLINE_MS konfigurieren; wenn Sie sie auf 0 setzen, wird das Timeout deaktiviert.

Anhaltend hohe CPU-Auslastung in Leerlaufsitzungen wurde behoben. In langen Leerlaufsitzungen konnte eine Leerlaufschleife in Claude Code eine anhaltend hohe CPU-Auslastung verursachen. Dieser Fehler wurde in 2.1.268 behoben. Betroffen sein konnten auch Personen, die Sitzungen den ganzen Tag geöffnet lassen.

Installieren Sie die neueste Version. In 2.1.269 trat ein neuer Fehler auf: Nachdem eine Sitzung lange gelaufen war, fragten Bash-Git-Befehle, die nur Daten lasen, nach einer Berechtigung. Dieser Fehler wurde in 2.1.270 behoben. Aktualisieren Sie daher auf die neueste Version (Stand 17. September 2026 war das 2.1.274); bleiben Sie nicht bei 2.1.268 oder 2.1.269.

Wie aktualisieren Sie und prüfen, ob Ablehnungen funktionieren?#

1. Ermitteln Sie Ihre aktuelle Version. Führen Sie claude --version im Terminal aus. Die Korrekturen für die oben beschriebenen Probleme wurden in 2.1.268 und 2.1.269 veröffentlicht. Liegt die Versionsnummer unter 2.1.268, enthält Ihre Version diese Korrekturen noch nicht; ob jedes Problem zutrifft, hängt jedoch von den verwendeten Pfaden, Befehlen und Regeln ab.
2. Aktualisieren. Die Anleitung Claude Code auf die neueste Version aktualisieren enthält Schritt-für-Schritt-Anweisungen und Hinweise zur Fehlerbehebung. Wählen Sie die neueste Version; bleiben Sie nicht bei 2.1.268 stehen.
3. Testen Sie die Ablehnung. Testen Sie eine Regel nicht an einer echten .env: Wenn die Ablehnung fehlschlägt, sieht der Agent echte Schlüssel. Erstellen Sie eine Testdatei, zum Beispiel secret-test.txt, mit einem beliebigen Text wie „Das ist ein Test“; fügen Sie die Regel "Read(./secret-test.txt)" zur deny-Liste in der .claude/settings.json des Projekts hinzu; starten Sie die Sitzung neu und fragen Sie: „Lies die Datei secret-test.txt und sag mir, was darin steht.“ Erwartet wird eine Ablehnung, die Ihre Regel nennt. Wenn der Agent die Datei liest, hat die Ablehnung in diesem Test nicht funktioniert. Prüfen Sie zuerst die Syntax im obigen Abschnitt und öffnen Sie /permissions, um die aktiven Regeln und die Dateien zu sehen, aus denen sie geladen wurden. Das Testergebnis allein zeigt die Ursache nicht. Eine Ablehnung zeigt, dass die Regel für diese Datei funktioniert; über Ihre anderen Regeln sagt sie nichts aus. Prüfen Sie diese deshalb einzeln auf dieselbe Weise.
4. Prüfen Sie den Symlink-Fall, wenn Sie solche Pfade verwenden. Wenn Sie Ablehnungen für /tmp, /etc oder /var unter macOS oder für /bin unter Linux festgelegt haben, wiederholen Sie den Test nach dem Update für diese Pfade.
5. Prüfen Sie Regeln mit „!“. Wenn Sie solche Regeln verwendet haben, prüfen Sie, ob jede in der Datei steht, für die sie gelten soll.

Wenn die Ablehnung funktioniert, Claude Code aber weiterhin nicht auf die benötigten Dateien zugreifen kann, lesen Sie die separate Erklärung: Warum Claude Code Projektdateien nicht sehen kann.

Wenn Sie gerade nicht aktualisieren können#

Manchmal müssen Sie ein Update aufschieben: Sie können die Umgebung nicht ändern, der Rechner gehört Ihrem Unternehmen oder Sie müssen die aktuelle Aufgabe abschließen. Bis zum Update können Sie das Risiko folgendermaßen verringern:

• Schreiben Sie Ablehnungsregeln für beide Schreibweisen des Pfads – den Symlink und den tatsächlichen Speicherort (unter macOS liegen tatsächliche Pfade unter /private);
• führen Sie nicht mehrere Befehle in einer Zeile zusammen und vermeiden Sie env -C und eval in Befehlen, die Sie den Agenten ausführen lassen;
• zeigen Sie niemandem die Ausgabe von /mcp, /plugin, claude mcp list oder claude mcp get, und wechseln Sie Schlüssel aus MCP-Konfigurationen, die in die Hände anderer gelangt sein könnten;
• denken Sie daran, dass tee deny für Edit umgeht – betrachten Sie Dateien nicht als geschützt, wenn Bash erlaubt ist.

Diese Maßnahmen verringern die Wahrscheinlichkeit bestimmter Umgehungen, ersetzen die Korrektur aber nicht. Aktualisieren Sie und führen Sie den Test aus dem vorherigen Abschnitt durch, sobald Sie können.

Kurze Zusammenfassung#

Die Versionen 2.1.268 und 2.1.269 behoben vier Berechtigungsprobleme in Claude Code: Symlinks, Zeilen mit env -C und eval, Regeln mit „!“, die über ihre eigene Datei hinaus galten, und Schreibvorgänge über tee. Separat behoben sie die Offenlegung von Geheimnissen in der Ausgabe von /mcp und von Tokens in Plugin-Fehlern. Prüfen Sie Ihre Versionsnummer, aktualisieren Sie auf die neueste Version und führen Sie den Test mit einer Testdatei aus dem obigen Abschnitt durch. Eine Ablehnung, die Ihre Regel nennt, zeigt, dass die Ablehnung in diesem Test funktioniert hat. Dass die Regel in den Einstellungen steht, reicht als Nachweis nicht aus.

Um weiter mit Modellen zu arbeiten, können Sie zu Ailoot gehen.