# Claude Code 2.1.268: Was bei deny-Regeln und MCP behoben wurde > Claude Code 2.1.268–2.1.269 behob vier Berechtigungsprobleme und ein Geheimnisleck in /mcp. Wer ist betroffen, wie aktualisiert man und wie prüft man seine Regeln? Source: https://ailoot.ai/blog/de/claude-code-2-1-268-fixes/ Canonical: https://ailoot.ai/blog/de/claude-code-2-1-268-fixes/ Language: de Publisher: Ailoot (https://ailoot.ai/) Translation: guide-040 Revision: sha256-e959c33ee3a3b5548e80afa1734241e3b2ebdbe29d77245a8950c25f4ea8abc1 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](https://ailoot.ai/docs/). ## Was wurde in Claude Code 2.1.268 und 2.1.269 behoben?
Das Wichtigste Vier Berechtigungsprobleme wurden behoben. Die Regeln deny und ask funktionierten bei Pfaden über Symlinks nicht, und deny für Read oder Edit konnte bei Zeilen mit `env -C` oder `eval` versagen. Eine Regel mit „!“ galt über ihre Einstellungsdatei hinaus. Der Befehl `tee` schrieb Dateien, ohne dass deny für Edit dies blockierte. Außerdem zeigten `/mcp` und `claude mcp list` Geheimnisse aus Konfigurationen an, während Plugin-Fehler Tokens aus Git-URLs anzeigten.
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?
Das Wichtigste Regeln werden im Block `permissions` von `settings.json` geschrieben: deny blockiert, ask fordert eine Bestätigung an und allow gestattet eine Aktion ohne Bestätigung. Die Prüfungen erfolgen in dieser Reihenfolge: deny, dann ask, dann allow. Eine Regel hat das Format `Tool` oder `Tool(detail)`, zum Beispiel `Read(./.env)`.
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: ```json { "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?
Das Wichtigste Schlüssel in MCP-Konfigurationen werden oft über `${VAR}`-Variablen bereitgestellt. Die Befehle `/mcp`, `/plugin`, `claude mcp list` und `claude mcp get` sowie MCP-Anmeldefehler zeigten die ersetzten Werte an – also die Schlüssel selbst. In 2.1.268 wird die Ausgabe unkenntlich gemacht.
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](https://ailoot.ai/blog/de/mcp-servers-claude-code/). ## 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?
Das Wichtigste Prüfen Sie die Version mit `claude --version`, aktualisieren Sie auf die neueste Version und testen Sie dann mit einer sicheren Datei ohne Geheimnisse: Fügen Sie eine Ablehnungsregel dafür hinzu, bitten Sie den Agenten, die Datei zu lesen, und prüfen Sie, ob die Ablehnung auf Ihre Regel verweist.
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](https://ailoot.ai/blog/de/update-claude-code/) 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](https://ailoot.ai/blog/de/claude-code-cant-see-project-files/). ## 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.
### Quellen - Claude Code, offizielles Changelog (Einträge für 2.1.268, 2.1.269, 2.1.270): - Claude Code, Veröffentlichungsdaten auf npm: - Claude Code, Berechtigungsdokumentation (Syntax von deny/ask/allow): - Claude Code, Veröffentlichungen auf GitHub:
Um weiter mit Modellen zu arbeiten, können Sie zu [Ailoot](https://ailoot.ai/) gehen. ## Fragen und Antworten ### Wie teste ich eine deny-Regel, ohne ein echtes Geheimnis offenzulegen? Erstellen Sie eine Datei mit harmlosem Text, verweigern Sie Read-Zugriff auf diese Testdatei, starten Sie die Sitzung neu und bitten Sie den Agenten, sie zu lesen. Erwartet wird eine Ablehnung mit Verweis auf Ihre Regel. Verwenden Sie keine echte .env-Datei für einen Test, der scheitern könnte. ### Beweist eine erfolgreiche Zugriffsverweigerung, dass alle Berechtigungen sicher sind? Nein. Sie bestätigt nur die geprüfte Datei und den geprüften Zugriffsweg. Kontrollieren Sie aktive Regeln unter /permissions und testen Sie weitere benötigte Fälle und Wege, gegebenenfalls auch Pfadschreibweisen über Symlinks. ## Ailoot · Das Unternehmen und sein Projektportfolio Ailoot baut auf bewährte Betriebserfahrung, einen großen Kundenstamm, stabilen Service und kontinuierliche KPI-Kontrolle. Das Unternehmen und sein Projektportfolio: Millionen von Kunden; monatliche Umsätze in Milliardenhöhe. Ailoot nutzt diese Betriebserfahrung für den API-Zugang zu KI-Funktionen in Kundenprodukten, Agenten, Anwendungen und Automatisierungen.