Claude Code 2.1.314 schließt ein Fail-Open bei Managed Policies und fügt einen Schalter hinzu, der Schreibzugriffe außerhalb von Arbeitsverzeichnissen blockiert

Aktualisieren Sie jetzt, wenn Ihre Claude-Code-Guardrails in Managed Settings leben. Claude Code 2.1.314, datiert auf den 30. Oktober 2026 in Anthropics Changelog, behebt einen Fall, in dem eine Session ganz ohne Policy starten konnte. Es schließt außerdem drei engere Lücken in Sandbox, Hooks und Einstellungsquellen und fügt die erste Einstellung hinzu, mit der Claudes Datei-Tools Schreibzugriffe außerhalb der Arbeitsverzeichnisse in jedem Berechtigungsmodus ablehnen. Unsere Claude-Code-Bewertung bleibt Bedingt: Das ist ein Routine-Härtungsrelease, und die richtige Reaktion ist das Update, nicht ein Umdenken beim Tool.

Was passiert ist

Das Fail-Open bei der Managed Policy

Das Changelog, wörtlich: „Behoben: forceRemoteSettingsRefresh, nur in den Remote Managed Settings gesetzt, galt nach Ablauf der gespeicherten Kopie nicht mehr, sodass Sessions ohne Policy starten konnten, wenn der Server nicht erreichbar war“.

In der Praxis: Eine Organisation, die forceRemoteSettingsRefresh nur in ihren Remote Managed Settings gesetzt hatte, erwartete, dass Claude Code sich weigert, unverwaltet zu laufen. Sobald die zwischengespeicherte Kopie abgelaufen war, griff das Flag nicht mehr, sodass eine Maschine, die den Einstellungsserver nicht erreichen konnte, eine Session ohne Policy startete. Maschinen, die den Kontakt zum Server nie verloren, waren über diesen Pfad nicht betroffen.

Drei weitere Berechtigungs- und Sandbox-Fixes

Alle wörtlich aus dem 2.1.314-Eintrag:

• „Behoben: Sandbox-Schutzmaßnahmen galten nicht für einen Worktree, der mit claude -p --resume oder --continue betreten wurde“
• „Behoben: Eine mit --setting-sources ausgeschlossene Einstellungsdatei lieferte weiterhin einige Einstellungen, etwa Auto-Modus-Regeln und gespeicherte Berechtigungszustimmungen“
• „Behoben: Hooks, die auf Bash passen, liefen nicht bei Shell-Befehlen, die vom Monitor-Tool gestartet wurden; solche Hooks können diese Befehle blockieren oder nachfragen, aber nicht genehmigen oder umschreiben“

Neue Härtungsschalter

• „Neu: permissions.blockWritesOutsideWorkingDirectories: Write, Edit und NotebookEdit lehnen Pfade außerhalb der Arbeitsverzeichnisse in jedem Berechtigungsmodus ab“
• „Geändert: Claudes Datei-Tools fragen jetzt nach, bevor sie die lokale Kopie der serververwalteten Einstellungen Ihrer Organisation bearbeiten, so wie bei Ihren eigenen Einstellungsdateien“
• „Geändert: Geflaggte Anfragen versuchen es jetzt mit einem anderen Modell erneut, statt mit einer Ablehnung zu enden, wenn ANTHROPIC_DEFAULT_OPUS_MODEL, availableModels oder deniedModels nur ein älteres Opus-Modell oder gar keines übrig lassen“

Derselbe Eintrag fügt VS Code und dem Code-Tab von Claude Desktop Idle Compaction hinzu: „Eine Konversation mit über 200K Tokens, die im Leerlauf bleibt, wird zusammengefasst, und die Zusammenfassung wird bei Ihrer nächsten Nachricht verwendet, wenn der Prompt-Cache abgelaufen ist“.

Warum es wichtig ist

Das Fail-Open ist die Schlagzeile. forceRemoteSettingsRefresh existiert, damit eine verwaltete Maschine nicht ohne Policy läuft, und es versagte genau in dem Fall, für den es gedacht war: ein abgelaufener Cache plus ein unerreichbarer Server. Alle Deny-Regeln, Sandbox-Einstellungen oder Modellbeschränkungen, die über Remote Managed Settings ausgeliefert wurden, fehlten in diesen Sessions.

Die anderen drei Fixes beseitigen jeweils einen stillen Umgehungsweg:

• Fortgesetzte Headless-Jobs. Wer claude -p-Jobs in gesandboxten Worktrees fortsetzte, ließ sie ohne Sandbox-Schutz laufen.
• Ausgeschlossene Einstellungsdateien. Eine mit --setting-sources ausgeschlossene Datei konnte weiterhin Auto-Modus-Regeln und gespeicherte Berechtigungszustimmungen in eine Session tragen.
• Befehle des Monitor-Tools. Vom Monitor-Tool gestartete Shell-Befehle übersprangen Bash-Hooks, ein blockierender Hook griff bei ihnen also nicht.

Die neue Einstellung permissions.blockWritesOutsideWorkingDirectories deckt nur Claudes Datei-Tools ab (Write, Edit und NotebookEdit). Das Changelog sagt nicht, dass sie für Bash gilt, ein Shell-Befehl kann also weiterhin anderswo schreiben, es sei denn, die Sandbox oder eine Deny-Regel stoppt ihn.

Was sich für Sie ändert

• Verwaltete Flotten: Aktualisieren Sie jede Maschine auf 2.1.314, beginnend mit denen, die sich auf forceRemoteSettingsRefresh verlassen, um Sessions ohne Policy zu blockieren.
• Headless-Pipelines: Wenn Sie claude -p --resume oder --continue in gesandboxten Worktrees ausführen, aktualisieren Sie vor dem nächsten Lauf.
• Unbeaufsichtigte Läufe: Erwägen Sie, permissions.blockWritesOutsideWorkingDirectories in den Managed- oder Projekt-Einstellungen zu setzen, und kombinieren Sie es mit der Sandbox oder Bash-Deny-Regeln, da es Shell-Befehle nicht abdeckt.
• Teams, die --setting-sources nutzen: Prüfen Sie nach dem Update erneut, welche Auto-Modus-Regeln und gespeicherten Berechtigungszustimmungen noch gelten.

Was Ihnen das nicht sagt

Das Changelog nennt keine CVE und verlinkt keinen Sicherheitshinweis, es gibt also keine offizielle Schweregradeinstufung. Es gibt keinen 2.1.313-Eintrag: Das Changelog springt von 2.1.312 (27. Oktober) direkt zu 2.1.314 und nennt keinen Grund. Wir haben 2.1.314 nicht selbst getestet.