gateway.yaml. Die Datei definiert alles, was das Gateway tut: wo es lauscht, wie sich Entwickler anmelden, wohin Inferenz geht und welche Richtlinien und Telemetrie gelten. Diese Seite ist die Referenz für jede Option in dieser Datei.
Um Ihre erste zu schreiben, beginnen Sie mit dem Schnellstart, der eine minimale funktionierende Konfiguration erstellt und ausführt. Sobald Sie eine Konfiguration haben, mit der Sie zufrieden sind, behandelt der Bereitstellungsleitfaden die Containerisierung und das Hosting auf Kubernetes, Cloud Run oder Ihrer eigenen Plattform.
Das Gateway liest die Datei einmal beim Start mit claude gateway --config /path/to/gateway.yaml. Jede Option wird beim Start gegen ein Schema validiert, sodass eine fehlerhafte Konfiguration beim Start mit einem Fehler auf Feldebene fehlschlägt, anstatt bei der ersten Verwendung.
Das vollständige Beispiel am Ende dieser Seite behandelt jeden Abschnitt.
Dateistruktur
Fünf Abschnitte sind erforderlich. Jeder andere Abschnitt ist optional, und ein fehlender Abschnitt nimmt seine Standardwerte an. Unbekannte Schlüssel führen zum Fehlschlag beim Start, sodass ein Tippfehler als benannter Fehler anstelle einer stillschweigend ignorierten Einstellung auftaucht. Erforderliche Abschnitte:listen: Bindungsadresse, öffentliche URL, TLS-Beendigungoidc: Ihr Identitätsanbieter (IdP), einschließlich Aussteller, Client, Anspruchszuordnung und wer sich anmelden darfsession: die Bearer-Token, die das Gateway ausstellt, mit Geheimnis und Lebensdauerstore: PostgreSQL, für Gerätezuschüsse und Rate-Limit-Zählerupstreams: wohin Inferenz geht, ob Anthropic, Amazon Bedrock, Claude Platform auf AWS, Agent Platform von Google Cloud oder Microsoft Foundry
admin: Admin-API-Authentifizierung und Aufbewahrung für Ausgabenlimitsenforcement: Ausgabenlimit-Verhalten bei Fehler-offen oder Fehler-geschlossenmodelsundauto_include_builtin_models: von Admin kuratierte Modellliste und Pro-Upstream-IDsmanaged: verwaltete Einstellungsrichtlinien nach IdP-Gruppetelemetry: OTLP-Weiterleitung an Ihren Observability-Stackaccess_control,limits,timeouts,rate_limits: IP-Zulassung/Ablehnung, Anfragegrößenbeschränkungen, Upstream-Zeit-bis-erstes-Byte und Pro-IP-Anmeldungslimits
Geheimniserweiterung
Schreiben Sie Geheimnisse wieclient_secret, jwt_secret oder postgres_url nicht direkt in gateway.yaml. Referenzieren Sie sie mit einem der folgenden Formulare, und das Gateway löst den Wert beim Start aus einer Umgebungsvariablen oder einer Datei auf:
Erforderliche Abschnitte
listen
Der listen-Block steuert, wo das Gateway bereitgestellt wird: die Bindungsadresse und der Port, der extern sichtbare Ursprung und optionale TLS-Beendigung.
oidc
Der oidc-Block verbindet das Gateway mit Ihrem Identitätsanbieter und entscheidet, wer sich anmelden kann. Er benennt den Aussteller und OAuth-Client, ordnet die Ansprüche zu, die E-Mail und Gruppen enthalten, und beschränkt die Anmeldung nach E-Mail-Domäne oder Gruppe.
OpenID Connect (OIDC) ist das SSO-Protokoll, das das Gateway mit Ihrem Identitätsanbieter verwendet; siehe Identitätsanbieter-Setup für das, was Sie auf der IdP-Seite registrieren müssen.
session
Der session-Block formt die Bearer-Token, die das Gateway nach der Anmeldung ausstellt: das Geheimnis, das sie signiert, und wie lange sie leben.
store
Der store-Block zeigt das Gateway auf seine PostgreSQL-Datenbank, die Gerätezuschüsse und Rate-Limit-Zähler enthält.
Für die lokale Entwicklung zeigen Sie
postgres_url auf einen Wegwerf-Postgres-Container, zum Beispiel docker run --rm -p 5432:5432 -e POSTGRES_HOST_AUTH_METHOD=trust postgres.
upstreams
upstreams ist eine geordnete Liste. Das Gateway leitet Inferenz an den ersten Upstream weiter, der das angeforderte Modell auflöst. Bei 5xx, 429, 401, 403, 404 oder Timeout schlägt es zum nächsten fehl; andere 4xx nicht, da diese Fehler der Anfrage statt dem Upstream zuzuordnen sind. Ein 401 oder 403 bedeutet, dass die eigenen Berechtigungsnachweise des Gateways gegen diesen Upstream fehlgeschlagen sind, und ein 404 bedeutet, dass dieser Upstream das angeforderte Modell nicht bedient, sodass ein späterer Upstream in der Liste es immer noch kann.
Failover bei 404 erfordert Gateway v2.1.198 oder später. Frühere Releases gaben den ersten 404 an den Client zurück, auch wenn ein späterer Upstream in der Liste das Modell bediente.
Mehrere Upstreams desselben Anbieters müssen einen unterschiedlichen name: setzen.
Bedrock-, Claude Platform on AWS-, Agent Platform- und Foundry-Clients werden einmal beim Start erstellt, und ihre SDKs aktualisieren Berechtigungsnachweise intern, sodass das Rotieren von Cloud-Berechtigungsnachweisen keinen Neustart erfordert. Statische Anthropic-API-Schlüssel und Bearer werden beim Start gelesen; siehe Anthropic API.
Anthropic API
Der minimale Anthropic-Upstream ist ein API-Schlüssel aus der Claude Console:api_key: sendetx-api-key. Rotieren Sie ihn in der Claude Console und aktualisieren Sie die Env-Variable.oauth_token: sendetAuthorization: Bearer. Verwenden Sie das Bearer-Formular, wenn Ihre Organisation kurzlebige Token statt langlebiger API-Schlüssel ausgibt. Der Bearer wird einmal beim Start gelesen, also aktualisieren Sie durch Remounten des Geheimnisses und Neustart.
Amazon Bedrock
Für die Client-seitige Bedrock-Bereitstellung, die das Gateway ersetzt oder frontet, siehe Claude Code on Amazon Bedrock. Der Gateway-seitige Upstream:auth-Block verwendet die Standard-Berechtigungskette des AWS SDK: Env-Variablen, ~/.aws/credentials, ECS-Task-Rolle, EC2-Instanzmetadaten oder IRSA auf EKS. In der Produktion geben Sie dem Gateway-Pod eine IAM-Rolle statt statische Schlüssel in ein Container-Image einzubetten.
Explizite Berechtigungsnachweise müssen vollständig sein: Das Gateway schlägt beim Start fehl, wenn aws_access_key_id und aws_secret_access_key nicht zusammen gesetzt sind, oder wenn aws_session_token ohne sie gesetzt ist. Vor v2.1.207 bestand ein partieller auth:-Block die Validierung.
Claude Platform on AWS
Claude Platform on AWS bedient die First-Party-Anthropic-API auf AWS-Infrastruktur unteraws-external-anthropic.<region>.api.aws. Sie verwendet First-Party-Modell-IDs, berücksichtigt anthropic-beta-Header wie gesendet und bedient count_tokens, sodass keine der Bedrock-spezifischen Übersetzung gilt. Der anthropicAws-Provider erfordert Claude Code v2.1.198 oder später; frühere Gateway-Releases lehnen ihn beim Start ab.
Für die Client-seitige Bereitstellung derselben Plattform siehe Claude Code on Claude Platform on AWS. Der Gateway-seitige Upstream:
aws-external-anthropic, sodass eine Bedrock-scoped IAM-Rolle es nicht autorisiert. Ein API-Schlüssel in auth.api_key hat Vorrang, wenn SigV4-Berechtigungsnachweise auch gesetzt sind. Ein leerer auth-Block verwendet die Standard-Berechtigungskette des AWS SDK, dieselbe Kette, die der Amazon Bedrock-Upstream verwendet.
Da die Plattform First-Party-Modell-IDs auflöst, leitet der integrierte Katalog zu ihr ohne
models:-Block weiter. Wenn Sie eine models:-Liste kuratieren, schlüsseln Sie den Eintrag anthropicAws: mit der First-Party-ID.
Google Cloud Agent Platform
Für das äquivalente Client-seitige Setup siehe Claude Code on Google Cloud. Der Gateway-seitige Upstream:auth-Block verwendet Application Default Credentials: GOOGLE_APPLICATION_CREDENTIALS, GCE-Metadaten oder GKE Workload Identity. Service-Account-JSON-Schlüsseldateien werden unterstützt, aber nicht empfohlen; verwenden Sie Workload Identity oder hängen Sie ein Service-Account an die GCE- oder Cloud Run-Instanz an.
Setzen Sie region: global, um Agent Platforms globalen Endpunkt statt eines regionalen zu verwenden. Google leitet dann jede Anfrage an eine verfügbare Region weiter, sodass Sie die Pro-Region-Modellverfügbarkeit nicht verfolgen. Das Setzen einer bestimmten Region heftet jede Anfrage daran.
Microsoft Foundry
Für die Client-seitige Foundry-Bereitstellung siehe Claude Code on Microsoft Foundry. Der Gateway-seitige Upstream:use_azure_ad: true wird durch DefaultAzureCredential aufgelöst: Managed Identity auf AKS, ACI oder App Service; die Azure CLI; oder Umgebungsberechtigungsnachweise. API-Schlüssel funktionieren, sind aber projektumfassend und rotieren nicht automatisch. Der Foundry-Endpunkt wird von resource: abgeleitet; setzen Sie das optionale base_url, um es für souveräne Clouds wie Azure Government zu überschreiben.
Mehrere Upstreams
Derselbe Anbieter kann mehr als einmal mit einem unterschiedlichenname: erscheinen. Dies deckt verschiedene Regionen, verschiedene Konten über verschiedene Berechtigungsketten, bereitgestellter Durchsatz versus On-Demand und Cross-Provider-Fallback ab.
Das Gateway versucht Upstreams in Reihenfolge. 5xx, 429, 401, 403, 404, Timeouts und fehlender Endpunkt (501) schlagen fehl; andere 4xx nicht.
429 ist Pro-Upstream-Kapazität, sodass bereitgestellter Durchsatz (PT)-Erschöpfung zu On-Demand fehlschlägt. 404 ist Pro-Upstream-Modellverfügbarkeit, sodass ein Upstream, der ein Modell nicht aktiviert hat, einen späteren Upstream, der es bedient, nicht blockiert. Ein Upstream, der das angeforderte Modell nicht auflösen kann, wird ohne Netzwerk-Rundfahrt übersprungen.
Dieses Beispiel leitet eine bereitgestellte Durchsatz-Bedrock-Zuteilung zuerst weiter, überläuft zu On-Demand und einem zweiten Konto und fällt zuletzt auf die Anthropic API zurück:
Das Failover zwischen Cloud-Anbietern oder zur direkten Anthropic API ändert, welche Vereinbarung, Geographie und andere Bedingungen die Anfrage regeln.
Die CLI wendet dasselbe Feature-Gating auf Gateways an, unabhängig davon, welcher Upstream eine bestimmte Anfrage bedient, sodass Failover kein Body-Feld sendet, das ein Upstream ablehnen würde.
Optionale Abschnitte
admin
Optional. Aktiviert /v1/organizations/spend_limits, das Anthropics öffentliche Admin API spiegelt, und Pro-Entwickler-Ausgabendurchsetzung auf /v1/messages. Siehe Ausgabenlimits für wie Caps gesetzt und durchgesetzt werden; dieser Abschnitt behandelt die gateway.yaml-Schlüssel, die die Funktion aktivieren und sie abstimmen.
enforcement
Der enforcement-Block steuert, wie Ausgabenlimit-Prüfungen sich verhalten, wenn der Store nicht verfügbar ist.
models
Der models-Block ist eine optionale von Admin kuratierte Modellliste, die unter /v1/models bereitgestellt wird und zum Übersetzen von Modell-IDs pro Upstream verwendet wird. Es ist erforderlich für Nicht-US-Amazon Bedrock-Regionen, Amazon Bedrock-bereitgestellte Durchsatz-ARNs und Microsoft Foundry-Bereitstellungsnamen.
managed
Der managed-Block definiert rollenbasierte Zugriffrichtlinien, die auf IdP-Gruppen oder E-Mail-Domäne geschlüsselt sind. Richtlinien werden in Reihenfolge ausgewertet; die erste Übereinstimmung wird ausgewählt, dann auf die match: {}-Catch-All-Basis zusammengeführt, die unten beschrieben wird. Sie werden pro Benutzer unter GET /managed/settings mit ETag/304-Caching bereitgestellt.
match: {}-Catch-All, üblicherweise zuletzt aufgelistet, wird als Basisschicht behandelt. Jede andere Richtlinie erbt jeden Schlüssel, den sie nicht von der Catch-All setzt, sodass Pro-Rollen-Einträge nur auflisten müssen, was sich vom Org-Standard unterscheidet. Die Zusammenführungsregeln hängen vom Schlüsseltyp ab:
- Zulassungslisten:
availableModelsundpermissions.allow. Die Liste einer spezifischen Richtlinie ersetzt die Basis vollständig. - Ablehnungslisten und Hook-Arrays:
permissions.deny,permissions.ask,disabledMcpjsonServers,deniedMcpServers,blockedMarketplacesund jedeshooks-Event-Typ-Array. Diese nehmen die Vereinigung von Basis und Richtlinie, sodass ein Org-weiter Ablehnungs- oder Audit-Hook nicht versehentlich durch eine Pro-Rollen-Überschreibung gelöscht werden kann. - Record-typisierte Schlüssel:
env,modelOverridesundskillOverrides. Diese flach-zusammenführen, sodass ein Pro-Rollen-env-Block Schlüssel überschreibt, die er setzt, und den Rest von der Basis erbt.
availableModels wird auch Server-seitig unter /v1/messages durchgesetzt, sodass ein abgelehntes Modell 400 zurückgibt, unabhängig davon, was der Client sendet.
Ein authentifizierter Benutzer, der keine Richtlinie passt, erhält die Gateway-Standardwerte, was bedeutet, jedes Modell im Katalog und keine verwalteten Einstellungen. Fügen Sie einen
match: {}-Catch-All zuletzt hinzu, wenn Sie eine garantierte Standard-Richtlinie möchten.
Das Gateway führt kein eigenes Benutzerverzeichnis. Es autorisiert jede Anfrage vom IdP-Token des Benutzers, liest die Gruppenmitgliedschaft vom
groups-Anspruch des Tokens und wertet Richtlinien dagegen aus. Es gibt kein Roster zum Aufzählen und keine Konten zum Vorerstellen, und daher keinen SCIM-Endpunkt, da es nichts gibt, das SCIM hinein synchronisieren könnte.Führen Sie Benutzer- und Gruppen-Lebenszyklusverwaltung an der Quelle der Wahrheit durch, die der native SCIM-Bereitstellung Ihres IdP oder eine dedizierte Identitäts-Governance-Plattform ist. Mitgliedschaft und Bereitstellung, die dort regiert werden, fließen automatisch durch den Token in das Gateway. Wenn Sie SCIM-Bereitstellung von Claude-Konten selbst möchten, das ist eine Claude for Enterprise-Fähigkeit.Zwei Ausbreitungsuhren gelten:- Richtlinieninhalt: Das Bearbeiten einer Richtlinie und das erneute Bereitstellen erreichen verbundene Clients bei ihrer nächsten verwalteten Einstellungsabfrage, innerhalb einer Stunde
- Gruppenmitgliedschaft: Das Ändern der Gruppenmitgliedschaft eines Benutzers ändert, welche Richtlinie ihn passt. Dies tritt bei der nächsten Session-Neuerstellung in Kraft, was die nächste stille Aktualisierung bedeutet, begrenzt durch
session.ttl_hours.
Was geht in cli
Jeder cli-Wert ist ein vollständiges Claude Code managed-settings.json-Dokument, das gleiche Schema, das Sie über MDM oder /etc/claude-code/managed-settings.json bereitstellen würden, hier als YAML ausgedrückt. Die CLI wendet das bereitgestellte Dokument auf der verwalteten Ebene an, über Benutzer- und Projekteinstellungen.
Das Gateway validiert jedes Dokument beim Start gegen das Einstellungsschema der CLI, sodass ein nicht erkannter Top-Level-Schlüssel oder ein erkannter Schlüssel mit einem fehlgeformten Wert beim Start mit einem Fehler fehlschlägt, der jeden fehlerhaften Schlüssel benennt. Absichtlich offene Teile des Schemas akzeptieren immer noch beliebige Werte, da neuere Clients Einträge erkennen können, die das Gateway-Schema nicht erkennt. Diese offenen Schlüssel sind env, pluginConfigs und Schlüssel, die unter permissions verschachtelt sind.
Da die Validierung das Schema verwendet, das mit der installierten Version des Gateways gebündelt ist, erfordert das Einfügen eines Top-Level-Einstellungsschlüssels, der von einer neueren Claude Code-Version eingeführt wurde, in verwaltete Konfiguration, das Gateway zuerst zu aktualisieren. Rauchtesten Sie eine neue Richtlinie auf einem Client, bevor Sie sie ausrollen.
Die vollständige Schlüsselreferenz ist in Claude Code-Einstellungen. Die Schlüssel, die Operatoren zuerst erreichen:
Da diese Einstellungen über das Netzwerk ankommen, zeigt die CLI jedem Entwickler einen einmaligen Sicherheitsgenehmigungsdialog, bevor etwas angewendet wird, das einen Shell-Befehl ausführen oder ändern kann, wohin Traffic geht. Der Dialog behandelt:
hooksenv-Variablen, die nicht auf der sicheren Liste der CLI sind- Shell-Ausführungseinstellungen wie
apiKeyHelperundstatusLine - verwalteter CLAUDE.md-Inhalt
env-Variablen ohne Genehmigung gelten:
- Auf der sicheren Liste: Auto-Update und Modellnamen-Variablen
- Nicht auf der sicheren Liste: Proxy-Variablen, Base-URL-Variablen und
OTEL_EXPORTER_OTLP_ENDPOINT
OTEL_EXPORTER_OTLP_ENDPOINT, sodass das Setzen von telemetry.forward_to den Dialog bei jedem interaktiven Client auslöst. Ein nicht-interaktiver Lauf mit dem -p-Flag kann den Dialog nicht anzeigen. Er wendet die gepushten Einstellungen nur für diesen Lauf an und speichert sie nicht als genehmigt, sodass die nächste interaktive Session des Entwicklers immer noch den Dialog anzeigt. Vor v2.1.207 speicherte ein nicht-interaktiver Lauf die Einstellungen als genehmigt und keine spätere interaktive Session zeigte den Dialog dafür.
Wenn ein Entwickler ablehnt, beendet Claude Code statt die Richtlinie anzuwenden. Das Pushen eines neuen Hooks oder einer nicht-sicheren Env-Variable zu einer breiten Richtlinie bedeutet daher eine Genehmigungsaufforderung bei jedem passenden Entwickler beim nächsten Start.
Der cli-Schlüssel wurde in früheren Releases settings genannt. Diese Schreibweise wird immer noch als Alias akzeptiert, aber neue Bereitstellungen sollten cli verwenden.
Vorrang mit anderen verwalteten Quellen
Wenn ein Gerät auch eine lokalemanaged-settings.json oder MDM-bereitgestellte Richtlinie hat, werden die verwalteten Quellen nicht zusammengeführt. Die höchste Prioritätsquelle stellt alle Richtlinieneinstellungen bereit, in dieser Reihenfolge mit höchster Priorität zuerst:
- Der Richtlinien-Helper
- Gateway-bereitgestellte Einstellungen
- MDM, über die HKLM-Registrierung unter Windows oder eine plist unter macOS
- Die
managed-settings.json-Datei - Die HKCU-Registrierung, nur unter Windows
managedSettings-Option bereitstellen. Sie wird standardmäßig ignoriert und gilt nur, wenn eine verwaltete Quelle sich mit parentSettingsBehavior: "merge" anmeldet, gefiltert, sodass sie Richtlinie straffen, aber nicht lockern kann.
Die einzige Ausnahme ist die folgende Menge von Schlüsseln, die geehrt werden, wenn eine Admin-Quelle über der Benutzer-schreibbaren HKCU-Ebene sie setzt, unabhängig davon, welche Quelle den Rest der Richtlinie bereitstellt:
sandbox.network.allowManagedDomainsOnlyundsandbox.filesystem.allowManagedReadPathsOnly: wenn gesperrt, werden die entsprechenden Zulassungslisten über Quellen vereinigtallowAllClaudeAiMcps: Zulassung-nur-Überschreibung für die claude.ai MCP-Server-Zulassungslistesandbox.bwrapPathundsandbox.socatPath: Dateisystempfade zu den Sandbox-Helper-BinärdateienforceRemoteSettingsRefresh: blockiert den Start, bis Remote-verwaltete Einstellungen frisch abgerufen werden, sodass eine MDM- oder Datei-Richtlinie, die sie setzt, geehrt wird, auch wenn ein gecachter Remote-Payload, dem der Schlüssel fehlt, die höchste Prioritätsquelle ist
allowManagedPermissionRulesOnly und disableBypassPermissionsMode, kommt nur von der höchsten Prioritätsquelle. Siehe Einstellungs-Vorrang für die gleiche Regel auf der Einstellungsseite.
Gateway-Richtlinien gelten für jeden Claude Code-Aufruf auf der Maschine, einschließlich nicht-interaktiver claude -p-Läufe und Sessions, die vom Agent SDK erzeugt werden. Wenn das Gateway beim Start nicht erreichbar ist, beenden sich angemeldete Sessions mit einem Fehler, anstatt ohne ihre Richtlinie zu laufen.
telemetry
Die CLI sendet OpenTelemetry Protocol (OTLP) über HTTP-Metriken, Logs und, wenn aktiviert, Traces an das Gateway, das sie wörtlich an jedes konfigurierte Ziel weiterleitet. Siehe Überwachung der Nutzung für die Metriken und Ereignisse, die die CLI ausgibt.
Die CLI stempelt jeden Export mit der Identität des authentifizierten Benutzers, gelesen aus dem Gateway-ausgegebenen JWT: die user.id-, user.email- und user.groups-Attribute. Pro-Entwickler-Kosten- und Nutzungszuordnung funktioniert daher ohne Entwickler-seitige Konfiguration.
telemetry.forward_to zusammen mit listen.public_url schaltet es ein. Das Gateway pusht fünf Env-Variablen an jeden verbundenen Client durch /managed/settings:
CLAUDE_CODE_ENABLE_TELEMETRY=1OTEL_METRICS_EXPORTER=otlpOTEL_LOGS_EXPORTER=otlpOTEL_TRACES_EXPORTER=otlpOTEL_EXPORTER_OTLP_ENDPOINT=<public_url>
OTEL_*-Variablen, die ein Entwickler lokal setzt.
Traces erfordern zusätzlich CLAUDE_CODE_ENHANCED_TELEMETRY_BETA=1 auf jedem Client. Das Gateway pusht diese Variable nicht, also setzen Sie sie durch einen verwalteten Richtlinien-env-Block. Sie ist nicht auf der sicheren Liste der CLI, sodass die Bereitstellung durch eine Richtlinie durch den gleichen Sicherheitsgenehmigungsdialog abgedeckt ist, den der gepushte OTLP-Endpunkt bereits auslöst.
Sowohl Protobuf- als auch JSON-OTLP-Codierungen werden weitergeleitet, und jedes OpenTelemetry-kompatible Backend funktioniert als Ziel.
HTTP-Abstimmung
Vier optionale Top-Level-Blöcke,access_control, limits, timeouts und rate_limits, stimmen die HTTP-Oberfläche ab. Die Standardwerte passen zu den meisten Bereitstellungen.
Vollständiges Beispiel
Diese vollständige Referenzkonfiguration behandelt jeden Kernabschnitt; die HTTP-Abstimmungsblöcke behalten ihre Standardwerte. Kopieren Sie sie, löschen Sie, was Sie nicht brauchen, und füllen Sie Ihre Werte aus. Die Konfiguration im Schnellstart ist eine minimale Version davon.gateway.yaml
Client-seitige verwaltete Einstellungen
Alles oben konfiguriert den Gateway-Server. Das Zeigen von Entwicklermaschinen darauf wird separat auf jedem Gerät durch Claude Code’s verwaltete Einstellungen konfiguriert. Das Gateway kann diese Schlüssel nicht selbst pushen, da sie dem Client sagen, wo das Gateway ist. Für die CLI setzen Sie beide Schlüssel in die Pro-OSmanaged-settings.json:
forceLoginGatewayUrl und der "gateway"-Wert von forceLoginMethod werden nur von der Admin-kontrollierten verwalteten Ebene geehrt. Ein Entwickler, der sie in seinen eigenen ~/.claude/settings.json setzt, hat keine Auswirkung.
Verwandt
- Claude Apps Gateway-Übersicht: Schnellstart und Entwickler-Verbindung
- Bereitstellungsleitfaden: IdP-Setup, Container-Image, Kubernetes und Cloud Run sowie Operationen
- Ausgabenlimits: Pro-Entwickler-Caps und die Admin API