SpyBara
Go Premium

server-managed-settings.md 2026-10-21 23:02 UTC to 2026-10-22 22:58 UTC

This page contains 128 additions and 119 deletions.

2026
Thu 1 23:59 Sun 4 23:58 Wed 7 23:59 Thu 8 22:58 Fri 9 23:02 Mon 19 23:58 Tue 20 23:00 Wed 21 23:02 Thu 22 22:58 Fri 23 22:59 Mon 26 22:57 Tue 27 22:59 Wed 28 23:57

Serververwaltete Einstellungen konfigurieren

Konfigurieren Sie Claude Code zentral für Ihre Organisation durch serververwaltete Einstellungen, ohne dass eine Geräteverwaltungsinfrastruktur erforderlich ist.

Serververwaltete Einstellungen ermöglichen es Organisationsinhabern, Claude Code zentral über Organisationseinstellungen > Claude Code > Verwaltete Einstellungen in der claude.ai-Konsole zu konfigurieren. Claude Code-Clients rufen diese Einstellungen automatisch ab, wenn sich Benutzer mit geeigneten Anmeldedaten auf einer Plattform authentifizieren, auf der die serververwaltete Bereitstellung unterstützt wird. Siehe Plattformverfügbarkeit für die Anmeldedaten und Plattformen, die sich qualifizieren.

[!NOTE]

Serververwaltete Einstellungen sind für Claude for Teams und Claude for Enterprise Kunden verfügbar.

Anforderungen

Um serververwaltete Einstellungen zu verwenden, benötigen Sie:

  • Claude for Teams oder Claude for Enterprise Plan
  • Die Rolle „Owner“ oder „Primary Owner“ in Ihrer Claude-Organisation, um die Konfiguration anzuzeigen und zu bearbeiten
  • Netzwerkzugriff auf api.anthropic.com

Wählen Sie zwischen serververwalteten und endpunktverwalteten Einstellungen

Claude Code unterstützt zwei Ansätze für zentralisierte Konfiguration. Serververwaltete Einstellungen liefern Konfiguration von Anthropics Servern. Endpunktverwaltete Einstellungen werden direkt auf Geräten über native Betriebssystemrichtlinien (macOS verwaltete Einstellungen, Windows-Registrierung) oder verwaltete Einstellungsdateien bereitgestellt.

Ansatz Am besten geeignet für Sicherheitsmodell
Serververwaltete Einstellungen Organisationen ohne MDM oder Benutzer auf nicht verwalteten Geräten Einstellungen, die Claude Code beim Start von Anthropics Servern abruft und während der Sitzung stündlich aktualisiert
Endpunktverwaltete Einstellungen Organisationen mit MDM oder Endpunktverwaltung Einstellungen, die auf Geräten über MDM-Konfigurationsprofile, Registrierungsrichtlinien oder verwaltete Einstellungsdateien bereitgestellt werden

Wenn Ihre Geräte in einer MDM- oder Endpunktverwaltungslösung registriert sind, bieten endpunktverwaltete Einstellungen stärkere Sicherheitsgarantien, da die Einstellungsdatei auf Betriebssystemebene vor Benutzermodifikationen geschützt werden kann. Endpunktverwaltete Einstellungen erreichen Cloud-Sitzungen in von Anthropic gehosteten Umgebungen nicht, daher sollten Organisationen, deren Entwickler Cloud-Sitzungen ausführen, auch serververwaltete Einstellungen konfigurieren. Sitzungen in einer selbstgehosteten Umgebung lesen auch die verwaltete Einstellungsdatei im Runner-Image. Die Einstellungspriorität unten gibt an, wann diese Datei gilt.

Serververwaltete Einstellungen konfigurieren

1. Öffnen Sie die Admin-Konsole

Navigieren Sie in der claude.ai-Konsole zu Organization settings > Claude Code > Managed settings.

Wenn die Seite in einer Team- oder Enterprise-Organisation anzeigt, dass Sie keinen Zugriff haben, bitten Sie einen Owner oder Primary Owner, die Änderung vorzunehmen.

2. Definieren Sie Ihre Einstellungen

Fügen Sie Ihre Konfiguration als JSON hinzu. Alle in settings.json verfügbaren Einstellungen werden unterstützt, mit Ausnahme derjenigen, die auf die Bereitstellung auf OS-Ebene beschränkt sind. Siehe Aktuelle Einschränkungen für diese kurze Liste. Dies umfasst Hooks, Umgebungsvariablen und nur verwaltete Einstellungen wie allowManagedPermissionRulesOnly.

Dieses Beispiel erzwingt eine Berechtigungsverweigerungsliste, verhindert, dass Benutzer Berechtigungen umgehen, und beschränkt Berechtigungsregeln auf diejenigen, die in verwalteten Einstellungen definiert sind. Die Regel Bash(curl *) entspricht curl wie Claude sie schreibt, nicht /usr/bin/curl oder sh -c 'curl …'. Für die Netzwerkerzwingung, die nicht vom Befehlstext abhängt, fügen Sie einen sandbox-Block mit allowManagedDomainsOnly hinzu.

{
  "permissions": {
    "deny": [
      "Bash(curl *)",
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ],
    "disableBypassPermissionsMode": "disable"
  },
  "allowManagedPermissionRulesOnly": true
}

Hooks verwenden das gleiche Format wie in settings.json.

Dieses Beispiel führt ein Audit-Skript nach jeder Dateibearbeitung in der gesamten Organisation aus:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          { "type": "command", "command": "/usr/local/bin/audit-edit.sh" }
        ]
      }
    ]
  }
}

Da Hooks Shell-Befehle ausführen, sehen Benutzer in interaktiven Sitzungen einen Sicherheitsgenehmigungsdialog, bevor Claude Code sie anwendet.

Um den Auto-Modus-Klassifikator zu konfigurieren, damit er weiß, welchen Repos, Buckets und Domains Ihre Organisation vertraut, stellen Sie einen autoMode-Block auf die gleiche Weise bereit. Siehe Auto-Modus konfigurieren, um zu erfahren, wie die autoMode-Einträge beeinflussen, was der Klassifikator blockiert, und wichtige Warnungen zu den Feldern environment, allow, soft_deny und hard_deny.

3. Speichern und bereitstellen

Speichern Sie Ihre Änderungen. Claude Code-Clients erhalten die aktualisierten Einstellungen beim nächsten Start oder während des stündlichen Abrufzyklus.

Der Editor prüft Ihr JSON anhand des veröffentlichten JSON-Schemas für Claude Code-Einstellungen. Findet er ein Problem in JSON, das sich parsen lässt, zeigt er eine Warnung an und ändert die Beschriftung der Speichern-Schaltfläche. Die Beschriftung lautet Update with errors, wenn bereits Einstellungen gespeichert sind, und Add with errors, wenn noch keine Einstellungen gespeichert sind. Diese Schaltfläche speichert trotzdem, da eine Schemawarnung das Speichern nicht blockiert.

Das Schema kann hinter den neuesten Releases zurückliegen, sodass der Editor möglicherweise einen Schlüssel oder Wert kennzeichnet, den die Einstellungsreferenz dokumentiert. Claude Code erhält die von Ihnen gespeicherten Schlüssel und Werte und führt beim Laden eine eigene Validierung durch.

Einstellungsbereitstellung überprüfen

Um zu bestätigen, dass Einstellungen angewendet werden, bitten Sie einen Benutzer, Claude Code neu zu starten. Wenn die Konfiguration Einstellungen enthält, die den Sicherheitsgenehmigungsdialog auslösen, sieht der Benutzer beim nächsten Abruf der Einstellungen durch Claude Code eine Eingabeaufforderung, die die verwalteten Einstellungen beschreibt: beim nächsten Start oder innerhalb einer Stunde in einer laufenden interaktiven Sitzung. Sie können auch überprüfen, dass verwaltete Berechtigungsregeln aktiv sind, indem Sie einen Benutzer /permissions ausführen lassen, um seine geltenden Berechtigungsregeln anzuzeigen.

Um das Abrufergebnis auf einem bestimmten Computer zu überprüfen, lassen Sie den Benutzer claude doctor ausführen und lesen Sie die Zeile Managed settings (remote). Erfordert Claude Code v2.1.248 oder später. Die Zeile meldet eines von vier Ergebnissen:

  • Die bereitgestellten Einstellungen wurden geladen
  • Ihre Organisation hat keine serververwalteten Einstellungen konfiguriert
  • Der Abruf ist fehlgeschlagen, mit der Ursache und ob eine zwischengespeicherte Richtlinie noch gilt
  • Claude Code hat den Abruf übersprungen, mit dem Grund. Siehe Plattformverfügbarkeit für die Anbieter und Konfigurationen, die ihn überspringen

Während der Abruf noch läuft, meldet die Zeile das stattdessen.

In einer laufenden Sitzung zeigt /status die gleiche Zeile nach einem fehlgeschlagenen Abruf an, und für einige übersprungene Abrufe, wie z. B. eine Variable eines Drittanbieter-Anbieters oder eine benutzerdefinierte ANTHROPIC_BASE_URL, die in der Shell des Benutzers exportiert wird.

Zugriffskontrolle

Die folgenden Rollen können serververwaltete Einstellungen verwalten:

  • Primärer Eigentümer
  • Eigentümer

Beschränken Sie den Zugriff auf vertrauenswürdiges Personal, da Einstellungsänderungen für alle Benutzer in der Organisation gelten.

Nur verwaltete Einstellungen

Die meisten Einstellungsschlüssel funktionieren in jedem Bereich. Eine Handvoll Schlüssel werden nur aus verwalteten Einstellungen gelesen und haben keine Auswirkung, wenn sie in Benutzer- oder Projekteinstellungsdateien platziert werden. Siehe nur verwaltete Einstellungen für die Berechtigung und Plugin-Steuerelemente, oder lesen Sie die Spalte „Bereich“ des Alle Einstellungen Index für den vollständigen Satz.

Aktuelle Einschränkungen

Serververwaltete Einstellungen haben die folgenden Einschränkungen:

  • Einstellungen gelten einheitlich für alle Benutzer in der Organisation. Konfigurationen pro Gruppe werden noch nicht unterstützt.

  • Eine managed-mcp.json Datei kann nicht über serververwaltete Einstellungen verteilt werden. Stellen Sie stattdessen die Richtlinienschlüssel allowedMcpServers und deniedMcpServers dort bereit. Ab Claude Code v2.1.259 können Sie auch Remote-Server mit managedMcpServers bereitstellen, das nur http- und sse-Server akzeptiert und nicht die exklusive Kontrolle übernimmt, wie die Datei es tut.

    Claude Code liest eine managed-mcp.json, die in seinem Systempfad bereitgestellt wird, separat von der Ebene der verwalteten Einstellungen, sodass die Datei weiterhin gilt, wenn serververwaltete Einstellungen in Kraft sind.

  • Einstellungen, die auf OS-Ebene-Richtlinienquellen beschränkt sind, wie policyHelper und wslInheritsWindowsSettings, werden nicht berücksichtigt. Stellen Sie sie stattdessen über MDM oder eine System-Datei managed-settings.json bereit. Ein policyHelper, der auf diese Weise bereitgestellt wird, wird nur ausgeführt, wenn seine Quelle die unter Vorrang innerhalb der verwalteten Ebene ausgewählte ist.

Bereitstellung der Einstellungen

Vorrang der Einstellungen

Servergesteuerte Einstellungen und endpunktgesteuerte Einstellungen belegen beide die höchste Ebene in der Einstellungshierarchie von Claude Code. Ein Schlüssel, den Sie hier festlegen, hat Vorrang vor demselben Schlüssel in den eigenen Einstellungsdateien eines Benutzers oder in einem --settings-Wert, abgesehen von den Ausnahmen vom Vorrang verwalteter Einstellungen.

Innerhalb der verwalteten Ebene verwendet Claude Code standardmäßig die erste Quelle, die mindestens einen Richtlinienschlüssel liefert. Dabei prüft Claude Code zuerst die servergesteuerten Einstellungen und dann die endpunktgesteuerten Einstellungen, abgesehen von den im Folgenden behandelten Ausnahmeschlüsseln. Wie Claude Code verwaltete Quellen kombiniert enthält die vollständige Rangfolge, die Sonderregel für die Steuerungsschlüssel und die Opt-in-Option, mit der alle Quellen angewendet werden.

Wenn die ausgewählte Quelle eine MDM-Richtlinie oder eine Datei mit verwalteten Einstellungen ist, deren policyHelper verwaltete Einstellungen liefert, ersetzt die Ausgabe des Helpers diese Quelle als einzige verwaltete Konfiguration für den Lauf. Claude Code berücksichtigt keinen in MDM- oder dateibasierten Einstellungen konfigurierten policyHelper, solange servergesteuerte Einstellungen einen Richtlinienschlüssel liefern.

Stellt ein späterer Abruf fest, dass die servergesteuerten Einstellungen entfernt wurden, führt Claude Code diesen Helper sofort aus statt erst beim nächsten Start. Der Eintrag policyHelper beschreibt, was passiert, wenn dieser Lauf fehlschlägt.

Wenn Sie Ihre servergesteuerte Konfiguration in der Admin-Konsole löschen, um auf eine endpunktgesteuerte plist- oder Registry-Richtlinie zurückzufallen, beachten Sie, dass zwischengespeicherte Einstellungen auf den Client-Rechnern bis zum nächsten erfolgreichen Abruf erhalten bleiben und dass die Schlüssel, die erst beim nächsten Start wirksam werden, etwa model, so lange gelten, bis jeder Client neu gestartet wird. Führen Sie /status aus, um zu sehen, welche verwaltete Quelle aktiv ist.

Ausnahmen pro Schlüssel über verwaltete Quellen hinweg

Diese Schlüssel sind Ausnahmen von der Regel, dass nicht zusammengeführt wird:

  • Quellenübergreifende Sperrschlüssel: eine kleine Gruppe von Schlüsseln, etwa die Sperren für die Sandbox-Allowlist, die auf der Seite zu verwalteten Einstellungen aufgeführt sind. Claude Code berücksichtigt sie, wenn eine beliebige von Admins gesteuerte verwaltete Quelle sie festlegt; die vom Benutzer beschreibbare HKCU-Registry-Ebene ist ausgenommen.

    Wenn ein policyHelper verwaltete Einstellungen liefert, ist seine Ausgabe die einzige Quelle, die diese Prüfungen lesen, abgesehen von forceRemoteSettingsRefresh, das Claude Code beim Start direkt aus den Admin-Quellen liest.

  • Der env-Block: Abgesehen von der Telemetrie-Einheit und den mit einem Anmeldedaten-Schlüssel gekoppelten Routing-Variablen, die beide unten behandelt werden, wird er pro Schlüssel über die von Admins gesteuerten Quellen zusammengeführt. Für jede Umgebungsvariable gilt die Quelle mit der höchsten Priorität, die sie definiert, und niedrigere Admin-Quellen ergänzen Variablen, die die höheren Quellen nicht setzen. Ein endpunktgesteuerter env-Eintrag gilt daher immer dann, wenn die servergesteuerte Konfiguration diese Variable nicht setzt oder solange ein zwischengespeicherter Serverwert dafür bis zur Bestätigung durch den Server zurückgehalten wird. Erfordert Claude Code v2.1.223 oder höher. Vor v2.1.223 wendet Claude Code nur den gesamten env-Block der ausgewählten Quelle an.

    • Telemetrie-Einheit: Die OTEL_EXPORTER_OTLP_*-Exporter-Schlüssel, die OTEL_LOG_*-Schalter zur Inhaltserfassung, OTEL_LOGS_EXPORTER sowie die Beta-Tracing-Variablen ENABLE_BETA_TRACING_DETAILED und BETA_TRACING_ENDPOINT folgen als Einheit der höchsten Quelle, die eine von ihnen setzt. Eine Quelle, die den Anmeldedaten-Schlüssel otelHeadersHelper liefert, beansprucht die Einheit ebenfalls, setzt diese Variablen aber nur, wenn sie die ausgewählte Quelle ist: Eine nicht ausgewählte Quelle, die den Schlüssel liefert, trägt keine davon bei und hindert dennoch niedrigere Quellen daran, sie zu ergänzen. In jedem Fall kann ein Exporter-Endpunkt aus einer Quelle nie mit Anmeldedaten aus einer anderen kombiniert werden.
    • An Anmeldedaten gekoppeltes Routing: Eine Quelle, die Routing-Variablen mit einem Anmeldedaten-Schlüssel koppelt, der nur aus der ausgewählten Quelle gilt, etwa apiKeyHelper oder otelHeadersHelper, trägt diese Routing-Variablen nur bei, wenn sie den Platz gewinnt.

  • allowedProviders: Eine auf dem Rechner festgelegte Liste und eine servergesteuerte Liste werden so kombiniert, wie es der Hinweis zum Geltungsbereich in ihrem Eintrag angibt. Erfordert Claude Code v2.1.285 oder höher

  • Schlüssel für die Gateway-Anmeldung: Claude Code liest forceLoginGatewayUrl, gatewayInternalNetworks oder den Wert "gateway" von forceLoginMethod nie aus servergesteuerten Einstellungen, sodass ein dort gesetzter Wert weder gilt noch einen in einer MDM-Richtlinie oder Datei mit verwalteten Einstellungen gesetzten Wert verdeckt. Der Eintrag managedSourcesBehavior gibt an, welche Admin-Quelle auf dem Rechner sie liefert.

Abruf- und Caching-Verhalten

Claude Code ruft Einstellungen beim Start von den Servern von Anthropic ab und fragt während aktiver Sitzungen stündlich nach Aktualisierungen.

Ein Client, der über ein Claude apps gateway angemeldet ist, ruft seine Einstellungen vom Gateway ab und wartet auf diesen Abruf, bevor die Sitzung beginnt. Der Abruf in den folgenden Listen gilt für ihn daher nicht. Fail-Closed-Start erzwingen beschreibt, was passiert, wenn dieser Abruf fehlschlägt.

Erster Start ohne zwischengespeicherte Einstellungen:

  • Wenn sich ein Entwickler beim Start anmeldet, etwa beim ersten Lauf oder nach /logout, wartet Claude Code bis zu fünf Sekunden auf den Abruf, bevor es die Sitzung öffnet. Trifft die Richtlinie rechtzeitig ein, setzt Claude Code sie ab dem ersten Bildschirm durch und zeigt dort Ihre companyAnnouncements an. Benötigt die Payload eine Sicherheitsgenehmigung, beendet Claude Code das Warten und wendet die Payload an, sobald der Entwickler sie genehmigt
  • Bei jedem anderen Start und wenn diese fünfsekündige Wartezeit abläuft, öffnet Claude Code die Sitzung, während der Abruf weiterläuft. Es vergeht also ein kurzer Zeitraum, bevor die Einstellungen geladen werden und die Einschränkungen wirksam werden
  • Schlägt der Abruf fehl, fährt Claude Code ohne servergesteuerte Einstellungen fort und warnt in interaktiven Sitzungen, dass keine Remote-Richtlinie gilt; endpunktgesteuerte Einstellungen gelten weiterhin. Wenn eine verwaltete Quelle forceRemoteSettingsRefresh setzt, beendet sich Claude Code stattdessen

Spätere Starts mit zwischengespeicherten Einstellungen:

  • Zwischengespeicherte Einstellungen gelten sofort beim Start, mit Ausnahme der zwischengespeicherten Werte modelPricing und managedMcpServers sowie der Umgebungsvariablen, die Claude Code zurückhält, bis der Server die Payload bestätigt
  • Ein zwischengespeichertes modelPricing gilt erst, wenn der Abruf der Sitzung die Payload bestätigt. Bis dahin basieren die Kostenangaben, die Entwickler in /usage und in der Statuszeile sehen, auf Listenpreisen
  • Ein zwischengespeicherter managedMcpServers-Block gilt erst, wenn der Abruf der Sitzung die Payload bestätigt. Claude Code wartet bis zu 30 Sekunden auf diesen Abruf, bevor es MCP-Server verbindet. Schlägt der Abruf fehl oder tritt eine Zeitüberschreitung auf, startet die Sitzung ohne die Server der Organisation, /status weist darauf hin, und die Server werden verbunden, sobald ein späterer Abruf sie bestätigt. Unter Wann bereitgestellte Server verbunden werden finden Sie das vollständige Verhalten, einschließlich des ersten Starts. Erfordert Claude Code v2.1.259 oder höher
  • Claude Code ruft im Hintergrund aktuelle Einstellungen ab
  • Zwischengespeicherte Einstellungen bleiben bei Netzwerkausfällen erhalten. Schlägt der Abruf beim Start fehl, warnt Claude Code in interaktiven Sitzungen, dass die zwischengespeicherte Richtlinie gilt
  • Bis ein Abruf erfolgreich ist, bleiben die beim Start zurückgehaltenen Werte zurückgehalten

Claude Code hält mehrere Kategorien von Variablen im zwischengespeicherten env-Block zurück, bis der Server die Payload für die Sitzung bestätigt. Dadurch wird verhindert, dass ein zwischengespeicherter Proxy-, Zertifizierungsstellen-, Endpunkt- oder Anmeldedatenwert den Einstellungsabruf, der die Payload bestätigt, umleitet, abfängt oder neu authentifiziert. Diese Absicherung gilt nur für den Cache der vom Server abgerufenen Einstellungen: Endpunktgesteuerte Einstellungen, die über MDM oder managed-settings.json bereitgestellt werden, sind nicht betroffen. Zu den zurückgehaltenen Kategorien gehören:

  • Proxy- und TLS-Konfiguration, etwa HTTPS_PROXY, NODE_EXTRA_CA_CERTS und die mTLS-Client-Zertifikatsvariablen CLAUDE_CODE_CLIENT_CERT und CLAUDE_CODE_CLIENT_KEY
  • API-Routing und Anbieterauswahl, einschließlich ANTHROPIC_BASE_URL, der Variablen zur Anbieterauswahl wie CLAUDE_CODE_USE_BEDROCK und CLAUDE_CODE_USE_VERTEX sowie der Endpunkt-URLs der Anbieter wie ANTHROPIC_BEDROCK_BASE_URL
  • Anmeldedaten für die Authentifizierung, etwa ANTHROPIC_API_KEY, ANTHROPIC_AUTH_TOKEN und CLAUDE_CODE_OAUTH_TOKEN
  • Der Selektor für das Konfigurationsverzeichnis CLAUDE_CONFIG_DIR
  • Selektoren für Anmeldedatenquelle und Konfigurationsverzeichnis, in Claude Code v2.1.223 oder höher: die Variablen für Workload Identity Federation wie ANTHROPIC_FEDERATION_RULE_ID und ANTHROPIC_IDENTITY_TOKEN, die Selektoren für Profil und Konfigurationsverzeichnis ANTHROPIC_PROFILE und ANTHROPIC_CONFIG_DIR sowie die Verzeichnisvariablen des Betriebssystems HOME, XDG_CONFIG_HOME, APPDATA und USERPROFILE

Claude Code liest die Variablen für Workload Identity Federation sowie die Selektoren ANTHROPIC_PROFILE und ANTHROPIC_CONFIG_DIR nur beim Start, sodass ein vom Server gelieferter Wert dafür die Anmeldedatenquelle der Sitzung auch nach erfolgreichem Abruf nicht wechselt. Um diese Selektoren unter Claude Code v2.1.223 oder höher bereitzustellen, verwenden Sie endpunktgesteuerte Einstellungen wie MDM oder managed-settings.json. Bei CLAUDE_CONFIG_DIR und den Verzeichnisvariablen des Betriebssystems ist das Zurückhalten selbst der Schutz: Der zwischengespeicherte Wert bleibt außerhalb der Umgebung, bis der Server die Payload bestätigt.

Alle anderen Schlüssel im zwischengespeicherten env-Block gelten beim Start. Sobald der Server die Payload bestätigt und Sie sie genehmigt haben, falls sie eine Sicherheitsgenehmigung benötigt, gelten die zurückgehaltenen Variablen für den Rest der Sitzung.

Wenn Ihre Organisation einen Proxy benötigt, um api.anthropic.com zu erreichen, betrifft das Zurückhalten nur den vom Server gelieferten env-Block selbst: Ein Proxy, der in einem endpunktgesteuerten env-Block über MDM oder managed-settings.json, in der Shell-Umgebung oder in den Benutzereinstellungen gesetzt ist, erreicht den Einstellungsabruf. Die endpunktgesteuerte Quelle erfordert Claude Code v2.1.223 oder höher: Der zwischengespeicherte servergesteuerte Proxy-Wert wird zurückgehalten, bis der Abruf ihn bestätigt, sodass der endpunktgesteuerte Wert pro Schlüssel ergänzt wird und den Abruf selbst erreicht. Verwenden Sie vor v2.1.223 die Shell-Umgebung oder die Benutzereinstellungen, damit der Proxy zusammen mit einer zwischengespeicherten Server-Payload gilt. Beim ersten Start gibt es keinen Cache, daher ist für den ersten Abruf weiterhin eine endpunktgesteuerte Quelle, die Shell-Umgebung oder die Benutzereinstellungen erforderlich.

Claude Code wendet die meisten Aktualisierungen der Einstellungen ohne Neustart auf laufende Sitzungen an. Einige Aktualisierungen gelten erst beim nächsten Start, darunter die Konfiguration des OpenTelemetry-Exporters, der Schlüssel model und das Entfernen einer Variablen aus dem env-Block.

Ungültige Einträge in gelieferten Einstellungen

Wenn ein Teil einer Payload die Schemavalidierung nicht besteht, zeigt Claude Code einen Validierungsfehler an und wendet alle übrigen gültigen Einstellungen an; Ungültige Einträge in verwalteten Einstellungen beschreibt, was verworfen wird und welche Schlüssel auf einen strengeren Wert zurückfallen. Erfordert Claude Code v2.1.169 oder höher.

Die servergesteuerte Bereitstellung ergänzt folgende Verhaltensweisen:

  • Ein Start, der auf dem Cache unter ~/.claude/remote-settings.json läuft, behandelt ungültige Einträge so wie der Abruf, der den Cache geschrieben hat:

    • Einträge, die die Validierung nicht bestanden haben, bleiben verworfen.
    • Schlüssel, die Fail-Closed behandelt werden, behalten ihre strengeren Werte.
    • Ein ungültiger Wert für cleanupPeriodDays oder desktopSessionCleanupPeriodDays bleibt in der zwischengespeicherten Kopie und wird nie angewendet.

  • Claude Code wendet nichts aus einer Payload an und lässt den Cache unverändert, wenn alle drei der folgenden Bedingungen zutreffen:

    • Jede Einstellung in der Payload besteht die Validierung nicht.
    • Keine davon fällt auf einen strengeren Wert zurück.
    • Die Payload enthält einen anderen Schlüssel als diese beiden Aufbewahrungsschlüssel.

    Der Hinweis beim Start, /status und claude doctor melden dann den fehlgeschlagenen Ladevorgang mit der Ursache no setting in the server response could be applied as written, und dieser Eintrag gibt an, mit welcher Richtlinie die Sitzung läuft. Clients, die einen Fail-Closed-Start erzwingen, beenden sich stattdessen beim Start.

  • Der Dialog zur Sicherheitsgenehmigung bewertet die bereinigte Payload, sodass ein entfernter ungültiger Eintrag nie zur Genehmigung angezeigt und nie ausgeführt wird.

Um Probleme bei der Bereitstellung zu debuggen, führen Sie claude --debug-file <path> aus und durchsuchen Sie das Log nach Remote settings. Validieren Sie eine Änderung der Payload mit claude doctor auf einem Testrechner, bevor Sie sie in der Organisation ausrollen.

Fail-Closed-Start erzwingen

Wenn der Abruf der Remote-Einstellungen beim Start fehlschlägt, fährt die CLI standardmäßig mit den Einstellungen aus dem letzten erfolgreichen Abruf fort, mit Ausnahme der Werte, die Claude Code zurückhält, bis ein Abruf erfolgreich ist. Auf einem Rechner, der sie noch nie abgerufen hat, fährt die CLI ohne servergesteuerte Einstellungen fort und wendet weiterhin alle endpunktgesteuerten Einstellungen auf dem Gerät an.

Um zu verhindern, dass Clients mit zwischengespeicherten oder fehlenden servergesteuerten Einstellungen starten, setzen Sie forceRemoteSettingsRefresh: true in Ihren verwalteten Einstellungen.

Clients, die über ein Claude apps gateway angemeldet sind, warten auf den Abruf beim Start, unabhängig davon, ob Sie dies setzen, und behandeln einen fehlgeschlagenen Abruf wie folgt:

  • Wenn das Gateway einen betreuten interaktiven Start mit 401 beantwortet und diese Einstellung deaktiviert ist, hat das Gateway diese Anmeldung beendet. Claude Code gibt Cloud gateway session expired — run /login to reconnect. aus und öffnet die Sitzung ohne Gateway-Anmeldung, bis der Benutzer /login ausführt.
  • Wenn der Abruf auf andere Weise fehlschlägt oder bei jeder anderen Art von Start außer einem claude auth-Unterbefehl, beendet sich der Client mit einem Fehler.

Wenn diese Einstellung in einer Sitzung aktiv ist, die servergesteuerte Einstellungen abruft, blockiert die CLI beim Start, bis die Remote-Einstellungen neu abgerufen wurden. Schlägt der Abruf fehl, beendet sich die CLI, statt ohne die Richtlinie fortzufahren. Diese Einstellung erhält sich selbst: Sobald sie vom Server geliefert wurde, wird sie auch lokal zwischengespeichert, sodass spätere Starts dasselbe Verhalten erzwingen, noch bevor der erste erfolgreiche Abruf einer neuen Sitzung erfolgt. Eine Sitzung, die keine servergesteuerten Einstellungen abruft, startet ohne Wartezeit.

Um dies zu aktivieren, fügen Sie den Schlüssel zu Ihrer Konfiguration der verwalteten Einstellungen hinzu:

{
  "forceRemoteSettingsRefresh": true
}

Sie können diesen Schlüssel auch in einem endpunktgesteuerten MDM-Profil oder in einer systemweiten managed-settings.json-Datei setzen, um das Fail-Closed-Verhalten schon beim ersten Start zu erzwingen, bevor eine Server-Payload eingetroffen ist. Dieses Flag ist eine Ausnahme von der obigen Vorrangregel: Claude Code berücksichtigt es, wenn eine beliebige von Admins gesteuerte verwaltete Quelle es setzt, auch wenn zusätzlich eine zwischengespeicherte servergesteuerte Payload vorhanden ist. Ein per MDM gelieferter Wert wird also nicht ignoriert, wenn servergesteuerte Einstellungen existieren.

Wenn ein policyHelper verwaltete Einstellungen liefert, ersetzt seine Ausgabe alle anderen verwalteten Quellen für die Schlüssel, die Claude Code nach dem Start liest. Die Quellen, aus denen Claude Code diesen Schlüssel liest, finden Sie in seinem Einstellungseintrag. Der Eintrag policyHelper gibt an, aus welchen Quellen Claude Code den Helper liest und wann er ausgeführt wird.

Der Einstellungsabruf sendet außerdem einen Cache-Control: no-cache-Header, damit zwischengeschaltete HTTP-Proxys keine veraltete Antwort ausliefern.

Stellen Sie vor dem Aktivieren dieser Einstellung sicher, dass Ihre Netzwerkrichtlinien Verbindungen zu api.anthropic.com erlauben. Ist dieser Endpunkt nicht erreichbar, beendet sich die CLI beim Start, und Benutzer können Claude Code nicht starten.

Die claude auth-Unterbefehle wie claude auth login sind von dieser Prüfung und vom Beenden beim Gateway-Start ausgenommen, sodass sich Benutzer erneut authentifizieren können, wenn abgelaufene Anmeldedaten der Grund für den fehlgeschlagenen Einstellungsabruf sind.

Dialoge zur Sicherheitsgenehmigung

Bestimmte Einstellungen, die Sicherheitsrisiken darstellen könnten, erfordern eine ausdrückliche Genehmigung durch den Benutzer, bevor Claude Code sie in einer interaktiven Sitzung anwendet:

  • Einstellungen mit Shell-Befehlen: Einstellungen, die Shell-Befehle ausführen, etwa apiKeyHelper, statusLine und otelHeadersHelper
  • Einstellungen für Sandbox-Binärdateien: sandbox.bwrapPath, sandbox.socatPath und sandbox.ripgrep. Jede dieser Einstellungen verweist auf eine ausführbare Datei, und Claude Code führt diese Datei aus
  • Einstellungen für Sandbox-Netzwerk und -Isolation: Sandbox-Einstellungen, mit denen der Sandbox-Proxy Datenverkehr lesen, umleiten oder authentifizieren kann oder die die Isolation der Sandbox abschwächen: sandbox.network.tlsTerminate, sandbox.network.httpProxyPort, sandbox.network.socksProxyPort, sandbox.credentials, sandbox.allowAppleEvents, sandbox.allowNestedUserNamespaces, sandbox.enableWeakerNestedSandbox, sandbox.enableWeakerNetworkIsolation, sandbox.filesystem.disabled, sandbox.network.allowAllUnixSockets, sandbox.network.allowUnixSockets und sandbox.network.allowMachLookup. Ein sandbox.credentials-Block, der nur deny-Regeln enthält, benötigt keine Genehmigung, da er die Sandbox einschränkt, ohne dem Proxy Anmeldedaten zu geben. Vor v2.1.251 wendete Claude Code diese Einstellungen ohne Genehmigung an
  • Benutzerdefinierte Umgebungsvariablen: gelieferte env-Variablen, die die Genehmigung des Benutzers erfordern, etwa Proxy- und Base-URL-Variablen; siehe Umgebungsvariablen und der Genehmigungsdialog
  • Hook-Konfigurationen: jede Hook-Definition

Wenn diese Einstellungen vorhanden sind, sehen Benutzer einen Sicherheitsdialog, der erklärt, was konfiguriert wird. Benutzer müssen zustimmen, um fortzufahren. Lehnt ein Benutzer die Einstellungen ab, beendet sich Claude Code.

Eine verwaltete CLAUDE.md, die über den Schlüssel claudeMd geliefert wird, erfordert keine Genehmigung, da es sich um Anweisungstext für Claude handelt und nicht um einen Befehl, den Claude Code ausführt. Claude Code prüft weiterhin die Berechtigungen für die Tools, die Claude beim Befolgen dieser Anweisungen verwendet. Vor v2.1.260 erforderte auch ein claudeMd-Wert eine Genehmigung.

Speicherung der Genehmigung

Claude Code speichert Ihre Genehmigung in Ihrem Konfigurationsverzeichnis, ~/.claude, sofern Sie nicht CLAUDE_CONFIG_DIR setzen. Was gespeichert wird, hängt von den Anmeldedaten ab, die der Einstellungsabruf verwendet:

  • Eine mit /login oder claude auth login gespeicherte claude.ai-Anmeldung oder die Console-Anmeldung ohne Schlüssel: eine Genehmigung pro Organisation, die dem Konto zugeordnet ist, das zuletzt genehmigt hat.

  • Eine Anmeldung über ein Claude apps gateway: eine Genehmigung pro Gateway.

    Wenn Sie sich beim selben Gateway ab- und wieder anmelden, zeigt Claude Code den Dialog nicht erneut an, solange die genehmigungspflichtigen Einstellungen unverändert sind. Claude Code zeigt ihn erneut an, wenn sich diese Einstellungen ändern, wenn Sie sich bei einem anderen Gateway anmelden und wenn Sie ein neues Zertifikat für dasselbe Gateway akzeptieren.

    Für ein Loopback-Entwicklungs-Gateway, das über einfaches HTTP erreicht wird, speichert Claude Code keine Genehmigung, sodass der Dialog nach jeder Anmeldung erneut erscheint.

  • Alle anderen Anmeldedaten, etwa ein API-Schlüssel oder CLAUDE_CODE_OAUTH_TOKEN: eine Genehmigung für die gelieferten Einstellungen, die zusammen mit der zwischengespeicherten Kopie der Einstellungen in diesem Konfigurationsverzeichnis abgelegt wird. Claude Code zeigt den Dialog erneut an, wenn sich die genehmigungspflichtigen Einstellungen ändern, und nachdem Sie /logout oder claude auth logout ausgeführt haben, da beide Befehle die zwischengespeicherte Kopie löschen.

Eine Genehmigung für sandbox.credentials oder sandbox.network.tlsTerminate deckt auch die Einträge in sandbox.network.allowedDomains in denselben gelieferten Einstellungen ab, da beide Einstellungen auf diese Allowlist wirken. Der Dialog erscheint erneut, wenn Ihr Administrator einen dieser Einträge hinzufügt oder entfernt, obwohl sandbox.network.allowedDomains für sich genommen keine Genehmigung erfordert.

Mit einer gespeicherten claude.ai-Anmeldung:

  • Wenn Sie sich ab- und wieder anmelden oder zu einer anderen Organisation wechseln und später zurückkehren, zeigt Claude Code den Dialog nicht erneut an, solange diese Einstellungen unverändert sind, es sei denn, ein anderes Konto hat sie zwischenzeitlich für diese Organisation im selben Konfigurationsverzeichnis genehmigt.
  • Wenn Sie sich mit einem anderen Konto bei derselben Organisation anmelden, zeigt Claude Code den Dialog erneut an, auch wenn die Einstellungen unverändert sind. Die Genehmigung dieses Kontos ersetzt die vorherige, sodass Claude Code den Dialog noch einmal anzeigt, wenn Sie zurückwechseln.

Claude Code kann den Dialog nicht immer anzeigen. Für jeden der folgenden Fälle ist angegeben, welche Einstellungen gelten, wenn der Dialog nicht angezeigt werden kann, und wann Sie ihn das nächste Mal sehen:

  • Eine interaktive Sitzung, die den Dialog nicht anzeigen kann: Claude Code wendet die gelieferten Einstellungen nicht an und behält die zuletzt genehmigten Einstellungen bei. Der Dialog erscheint in der nächsten Sitzung, die ihn anzeigen kann.

  • claude install oder claude update: Claude Code zeigt den Dialog während keines der beiden Befehle an. Der Befehl läuft mit den zuletzt genehmigten Einstellungen, und der Dialog erscheint in Ihrer nächsten interaktiven Sitzung. Wenn Claude Code beim Start auf den Einstellungsabruf wartet, etwa wenn forceRemoteSettingsRefresh gesetzt ist oder bei einer Bereitstellung mit Claude apps gateway, zeigt es den Dialog stattdessen während des Befehls an, und eine über eine Pipe ausgeführte Installation schlägt fehl; siehe Raw mode is not supported während der Installation. Vor v2.1.246 versuchte Claude Code, den Dialog auch während dieser Befehle anzuzeigen.

  • Ein claude plugin-Befehl, der in ein Terminal ausgibt, aber nicht von der Tastatur lesen kann: Wenn Claude Code beim Start nicht auf den Einstellungsabruf wartet, wendet der Befehl die gelieferten Einstellungen nicht an. Ohne zwischengespeicherte Einstellungen bricht ein Befehl, der Ihre Plugins oder Marketplaces ändert, mit einem Fehler ab. Mit zwischengespeicherten Einstellungen läuft er mit den zuletzt genehmigten Einstellungen. Der Dialog erscheint, wenn Sie das nächste Mal claude in einem Terminal ausführen.

    Der Befehl kann nicht von der Tastatur lesen, wenn Sie seine Eingabe per Pipe übergeben oder umleiten und er unter macOS und Linux außerdem /dev/tty nicht öffnen kann. Wenn Sie auch seine Ausgabe per Pipe weiterleiten oder umleiten, ist der Lauf stattdessen nicht interaktiv, und die gelieferten Einstellungen gelten nur für diesen Lauf.

  • Ein Fehler schließt den Dialog, bevor Sie antworten: Claude Code wendet die gelieferten Einstellungen nicht an und behält die zuletzt genehmigten Einstellungen bei. Der Dialog wird in der nächsten Sitzung, die ihn anzeigen kann, erneut angezeigt.

  • Ein nicht interaktiver Lauf, etwa claude -p, eine Agent SDK-Sitzung oder eine Sitzung im Chat-Bereich der VS Code-Erweiterung oder im Code-Tab der Desktop-App: Claude Code kann den Dialog nicht anzeigen. Wenn die gelieferten Einstellungen eine Genehmigung erfordern würden, wendet es sie daher nur für diesen Lauf an. Es speichert sie weder als genehmigt noch schreibt es sie in den lokalen Cache, und die nächste interaktive Sitzung zeigt den Dialog an. Bis ein Benutzer in einer interaktiven Sitzung zustimmt, ruft jeder nicht interaktive Lauf die Einstellungen beim Start erneut ab. Vor v2.1.207 speicherte ein nicht interaktiver Lauf die Einstellungen als genehmigt, sodass spätere interaktive Sitzungen den Dialog dafür nie anzeigten.

Umgebungsvariablen und der Genehmigungsdialog

Claude Code wendet einige gelieferte env-Variablen an, ohne dem Benutzer den Genehmigungsdialog anzuzeigen, darunter:

  • Schalter für Funktionen und Befehle
  • Einstellungen für Modellauswahl und -verhalten, etwa ANTHROPIC_MODEL, DISABLE_PROMPT_CACHING und CLAUDE_CODE_EFFORT_LEVEL
  • Einstellungen für Kontextfenster und Komprimierung, etwa DISABLE_AUTO_COMPACT, aber nicht CLAUDE_CODE_DISABLE_1M_CONTEXT
  • Optionen für die Terminal-Oberfläche und Barrierefreiheit
  • Numerische Limits, Budgets und Timeouts

Andere gelieferte Variablen können die Genehmigung des Benutzers erfordern, bevor sie wirksam werden. Beispielsweise gilt dies in interaktiven Sitzungen bei jedem nicht leeren Wert immer für:

  • Eine Proxy- oder Base-URL-Variable
  • OTEL_EXPORTER_OTLP_ENDPOINT
  • CLAUDE_CODE_DISABLE_1M_CONTEXT

Wenn eine gelieferte Variable eine Genehmigung benötigt, nennt der Dialog sie, sodass der Benutzer genau sieht, was die Richtlinie setzen möchte. Vor v2.1.218 wendete Claude Code weniger Variablen ohne Rückfrage beim Benutzer an, sodass Einstellungen wie DISABLE_AUTO_COMPACT bei jedem nicht leeren Wert den Dialog auslösten.

Bei vier Datenschutzschaltern entscheidet Claude Code anhand des gelieferten Werts statt anhand des Variablennamens, ob eine Genehmigung nötig ist: CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, DISABLE_ERROR_REPORTING, DISABLE_TELEMETRY und DO_NOT_TRACK. Ein als wahr ausgewerteter Wert (truthy) wie 1 oder true schaltet nur Tracking, Fehlerberichte oder anderen nicht wesentlichen Datenverkehr aus, daher wendet Claude Code ihn ohne Rückfrage beim Benutzer an. Bei jedem anderen nicht leeren Wert zeigt Claude Code den Dialog an. Vor v2.1.218 wurden alle außer DO_NOT_TRACK bei jedem Wert ohne Genehmigung angewendet, und DO_NOT_TRACK löste bei jedem nicht leeren Wert den Dialog aus.

Auch bei API_FORCE_IDLE_TIMEOUT entscheidet Claude Code anhand des gelieferten Werts, ob eine Genehmigung nötig ist: Ein als wahr ausgewerteter Wert (truthy) schaltet nur den Body-Idle-Timeout ein, daher wendet Claude Code ihn ohne Rückfrage beim Benutzer an. Bei jedem anderen nicht leeren Wert zeigt Claude Code den Dialog an. Vor v2.1.248 löste jeder nicht leere Wert den Dialog aus.

Ob ANTHROPIC_CUSTOM_HEADERS eine Genehmigung benötigt, hängt ebenfalls vom gelieferten Wert ab. Header, die Anfragen nur kennzeichnen, etwa Accept-Language, werden ohne den Dialog angewendet. Eine Zeile, die Anmeldedaten, einen Organisations- oder Mandantenselektor, eine Routing- oder Host-Überschreibung oder einen Header für das API-Verhalten benennt, etwa Authorization, X-Api-Key, Host, anthropic-beta oder die X-Amzn-Bedrock-*-Header, erfordert eine Genehmigung. Eine Zeile erfordert außerdem eine Genehmigung, wenn ihr Name kein gültiges HTTP-Header-Token ist oder ihr Wert ein Zeichen enthält, das ein HTTP-Header nicht transportieren kann. Die Prüfung gleicht Wörter innerhalb des Header-Namens ab, daher erfordert auch X-Client-Version, das client und version enthält, eine Genehmigung. Vor v2.1.251 wurde jeder ANTHROPIC_CUSTOM_HEADERS-Wert ohne Genehmigung angewendet.

Ein als falsch ausgewerteter Wert (falsy) wie 0 oder false für ENABLE_BETA_TRACING_DETAILED oder OTEL_LOG_RAW_API_BODIES wird ohne den Dialog angewendet, da er nur detailliertes Tracing oder die Erfassung roher API-Bodys ausschaltet. Jeder andere nicht leere Wert für eine der beiden Variablen erfordert eine Genehmigung.

Plattformverfügbarkeit

Serververwaltete Einstellungen erfordern eine direkte Verbindung zu api.anthropic.com. Die Bereitstellung erfordert auch, dass sich die Sitzung mit einer dieser Anmeldedaten authentifiziert:

  • Ein Team- oder Enterprise-OAuth-Login
  • Ein OAuth-Token, das über CLAUDE_CODE_OAUTH_TOKEN bereitgestellt wird
  • Ein direkt konfigurierter API-Schlüssel
  • Ein user_oauth Anthropic-Profil, es sei denn, das Profil setzt eine base_url andere als die Anthropic API. Erfordert Claude Code v2.1.257 oder später.

Weder Schlüssel, die von einem apiKeyHelper-Skript zurückgegeben werden, noch Workload Identity Federation-Anmeldedaten lösen den Abruf der Einstellungen aus.

Eine Sitzung erhält die verwalteten Einstellungen der Organisation, der die Anmeldedaten gehören, mit denen sie sich authentifiziert. Ein API-Schlüssel aus der Claude Console gehört zu der Console-Organisation, in der er erstellt wurde; diese ist eine von Ihrer claude.ai-Team- oder Enterprise-Organisation getrennte Organisation. Einstellungen, die Sie in den claude.ai-Admin-Einstellungen konfigurieren, erreichen daher keine Sitzung, die sich mit diesem Schlüssel authentifiziert, etwa einen CI-Job, der den Console-API-Schlüssel Ihres Unternehmens verwendet. Um sie auf diesen Job anzuwenden, verwenden Sie eine dieser Optionen. Die OAuth-Token-Option gilt nicht für einen Job, der mit --bare ausgeführt wird, da der Bare-Modus CLAUDE_CODE_OAUTH_TOKEN nicht liest.

  • OAuth-Token: Generieren Sie ein Token mit claude setup-token, autorisieren Sie es für Ihre Team- oder Enterprise-Organisation und setzen Sie es als CLAUDE_CODE_OAUTH_TOKEN in der Umgebung des Jobs. Entfernen Sie aus dieser Umgebung alle Anmeldedaten, die Vorrang vor dem Token haben, etwa ANTHROPIC_API_KEY.
  • Endpunktverwaltete Einstellungen: Stellen Sie eine verwaltete Einstellungsdatei auf dem Computer bereit, auf dem der Job ausgeführt wird.

In einer Cowork-Sitzung in der Claude Desktop-App ruft Claude Code keine serververwalteten Einstellungen aus der claude.ai-Admin-Konsole ab, auch wenn sich der Benutzer mit einem Team- oder Enterprise-Konto anmeldet. Wo und wann eine Richtlinie gilt behandelt, welche Richtlinie Cowork-Sitzungen auf dem Computer des Benutzers und Remote-Cowork-Sitzungen erreicht. claude.ai wendet weiterhin Ihre strictKnownMarketplaces- und blockedMarketplaces-Listen selbst an, wenn ein Cowork-Benutzer einen Marketplace aus einem Git-Repository auf claude.ai oder aus Anpassen in Cowork hinzufügt. Wie Einschränkungen funktionieren beschreibt diese Überprüfung.

Wenn Sie eine CLAUDE_CODE_USE_*-Providervariable oder eine nicht standardmäßige ANTHROPIC_BASE_URL in Ihrer Shell exportieren, überspringt Claude Code den Abruf der Einstellungen für Ihre Sitzungen. claude doctor und /status melden den übersprungenen Abruf und dessen Ursache.

Sie können den Export nicht mit einem serververwalteten env-Block löschen, da der Block durch den Abruf ankommt, den der Export verhindert. Ein endpunktverwalteter Einstellungen-env-Block stellt den Abruf auch nicht wieder her: Claude Code prüft die Berechtigung, bevor es verwaltete env-Blöcke anwendet, sodass die Überschreibung die Providerauswahl der Sitzung ändert, aber der Abruf bleibt übersprungen.

Um die serververwaltete Bereitstellung wiederherzustellen, entfernen Sie den Export aus Ihrer Shell, oder setzen Sie die Variable auf "" in Ihrem Benutzereinstellungen-env-Block, der vor der Berechtigungsprüfung angewendet wird. Um eine Richtlinie durchzusetzen, ohne sich auf Benutzer zu verlassen, die ihre Shells ändern, stellen Sie die Einstellungen stattdessen über den endpunktverwalteten Kanal bereit.

Für Amazon Bedrock-, Google Cloud's Agent Platform-, Microsoft Foundry- und Claude Platform on AWS-Bereitstellungen bietet ein selbstgehostetes Claude-Apps-Gateway die entsprechende Remote-Verwaltung von Einstellungen: Mit dem Gateway angemeldete Clients rufen verwaltete Einstellungen vom Gateway statt von api.anthropic.com ab. Die Fehlerbehandlung unterscheidet sich beim Start: Ein Gateway-Client, der das Gateway nicht erreichen kann, beendet sich mit einem Fehler, anstatt auf zwischengespeicherte Einstellungen zurückzugreifen, während die stündliche Hintergrundaktualisierung auf beiden Kanälen fehleroffen ist.

Audit-Protokollierung

Audit-Log-Ereignisse für Einstellungsänderungen sind über die Compliance-API oder den Audit-Log-Export verfügbar. Kontaktieren Sie Ihr Anthropic-Kontoteam für Zugriff.

Audit-Ereignisse enthalten den Typ der durchgeführten Aktion, das Konto und das Gerät, das die Aktion durchgeführt hat, sowie Verweise auf die vorherigen und neuen Werte.

Sicherheitsüberlegungen

Serververwaltete Einstellungen bieten zentralisierte Richtliniendurchsetzung, funktionieren aber als clientseitige Kontrolle, nicht als Sicherheitsgrenze. Auf nicht verwalteten Geräten benötigt ein Benutzer keinen Admin- oder Sudo-Zugriff, um diese zu umgehen.

Szenario Verhalten
Benutzer bearbeitet die zwischengespeicherte Einstellungsdatei Manipulierte Datei wird beim Start angewendet, außer für die Werte, die Claude Code bis zur Bestätigung der Nutzlast durch den Server zurückhält. Der nächste Serverfetch stellt die korrekten Einstellungen wieder her, außer für die Schlüssel, die nur beim nächsten Start gelten, wie model oder eine Variable, die zum env-Block hinzugefügt wurde, die bis zum Neustart wirksam bleiben
Benutzer löscht die zwischengespeicherte Einstellungsdatei Verhalten beim ersten Start tritt auf
Benutzer führt eine modifizierte Claude Code-Binärdatei aus Ein Benutzer, der einen modifizierten Client ausführen kann, kann jede clientseitige Kontrolle umgehen
Benutzer führt eine ältere Claude Code-Version aus Versionen, die vor serververwalteten Einstellungen entstanden sind, rufen diese nicht ab oder wenden sie nicht an
API ist nicht verfügbar Zwischengespeicherte Einstellungen werden angewendet, falls verfügbar, außer für die Werte, die Claude Code bis zu einem erfolgreichen Fetch zurückhält. Ohne einen Cache erzwingt Claude Code keine serververwalteten Einstellungen, bis der nächste erfolgreiche Fetch erfolgt, und wendet weiterhin alle endpunktverwalteten Einstellungen auf dem Gerät an. Mit forceRemoteSettingsRefresh: true wird die CLI stattdessen beendet, außer für claude auth Unterbefehle. Clients, die sich über ein Claude Apps Gateway anmelden, werden beim Start ohne diese Einstellung beendet, mit der gleichen claude auth-Ausnahme
Benutzer authentifiziert sich mit einer anderen Organisation Einstellungen werden nicht für Konten außerhalb der verwalteten Organisation bereitgestellt, einschließlich einer Sitzung, die sich mit einem Console-API-Schlüssel authentifiziert
Benutzer konfiguriert einen Drittanbieter-Modellprovider Serververwaltete Einstellungen werden umgangen. Dies umfasst das Setzen von CLAUDE_CODE_USE_BEDROCK, CLAUDE_CODE_USE_MANTLE, CLAUDE_CODE_USE_VERTEX, CLAUDE_CODE_USE_FOUNDRY, CLAUDE_CODE_USE_ANTHROPIC_AWS oder einer nicht standardmäßigen ANTHROPIC_BASE_URL
Netzwerkverkehr wird abgefangen oder umgeleitet Deaktivierte TLS-Validierung oder abgefangener Verkehr kann die Einstellungen ändern, die der Client erhält

Um Bearbeitungen lokaler Einstellungsdateien, einschließlich managed-settings.json, zu protokollieren, verwenden Sie ConfigChange hooks. Claude Code führt diese nicht aus, wenn serververwaltete Einstellungen ankommen oder aktualisiert werden, oder wenn sich ein MDM-Profil oder eine Registrierungsrichtlinie ändert, und ein Hook kann eine policy_settings-Änderung nicht blockieren.

Um einzuschränken, auf welche Organisationen Ihre Benutzer mit den vom Client bereitgestellten Anmeldedaten zugreifen können, siehe Netzwerkzugriffskontrolle mit Tenant Restrictions durchsetzen im Claude Help Center. Für stärkere Durchsetzungsgarantien verwenden Sie endpunktverwaltete Einstellungen auf Geräten, die in einer MDM-Lösung registriert sind.

Siehe auch

Verwandte Seiten zur Verwaltung der Claude Code-Konfiguration: