Documentation 2026-10-06 23:59 UTC to 2026-10-07 03:02 UTC

75| - | - |75| - | - |

76| Claude Code v2.1.195 oder später | Der `claude gateway`-Unterbefehl und der Gateway-Anmeldungsfluss werden in v2.1.195 ausgeliefert. Frühere öffentliche Builds enthalten sie nicht. Sowohl die Maschine, auf der der Gateway-Server läuft, als auch die Maschine jedes Entwicklers müssen v2.1.195 oder später sein; führen Sie `claude update` aus, um die neueste Version zu erhalten. Die [Claude Platform auf AWS Upstream](/docs/de/claude-apps-gateway-config#claude-platform-on-aws) erfordert Claude Code v2.1.198 oder später auf dem Gateway-Server. |76| Claude Code v2.1.195 oder später | Der `claude gateway`-Unterbefehl und der Gateway-Anmeldungsfluss werden in v2.1.195 ausgeliefert. Frühere öffentliche Builds enthalten sie nicht. Sowohl die Maschine, auf der der Gateway-Server läuft, als auch die Maschine jedes Entwicklers müssen v2.1.195 oder später sein; führen Sie `claude update` aus, um die neueste Version zu erhalten. Die [Claude Platform auf AWS Upstream](/docs/de/claude-apps-gateway-config#claude-platform-on-aws) erfordert Claude Code v2.1.198 oder später auf dem Gateway-Server. |

77| OpenID Connect (OIDC)-Identitätsanbieter | Okta, Microsoft Entra ID, Google Workspace, Keycloak oder Dex, oder ein anderer OIDC-konformer IdP wie PingFederate. Das Gateway führt Standard-OIDC-Erkennung und den Authorization-Code-Flow dagegen aus. SAML und LDAP werden nicht unterstützt. |77| OpenID Connect (OIDC)-Identitätsanbieter | Okta, Microsoft Entra ID, Google Workspace, Keycloak oder Dex, oder ein anderer OIDC-konformer IdP wie PingFederate. Das Gateway führt Standard-OIDC-Erkennung und den Authorization-Code-Flow dagegen aus. SAML und LDAP werden nicht unterstützt. |

78| PostgreSQL 14 oder später | Unterstützt den Geräte-Anmeldungsfluss, bei dem der Browser-Callback schreibt und die Polling-CLI liest, sowie Rate-Limit-Zähler. Jedes verwaltete Postgres funktioniert, einschließlich der kleinsten Stufe. Ohne konfigurierte Ausgabenlimits speichert das Gateway einige KB kurzlebigen Auth-Status; mit [Ausgabenlimits](/docs/de/claude-apps-gateway-spend-limits) enthält es auch dauerhafte Ausgaben-, Audit- und Identitätstabellen, die gesichert werden sollten. TLS über `?sslmode=require` wird empfohlen. |78| PostgreSQL 11 oder später | Unterstützt den Geräte-Anmeldungsfluss und Rate-Limit-Zähler. Ein verwalteter PostgreSQL-Dienst funktioniert, einschließlich der kleinsten Stufe; siehe [welche Datenbanken unterstützt werden](/docs/de/claude-apps-gateway-deploy#postgres). Mit [Ausgabenlimits](/docs/de/claude-apps-gateway-spend-limits) enthält es auch dauerhafte Ausgaben-, Audit- und Identitätstabellen, die gesichert werden sollten. TLS über `?sslmode=require` wird empfohlen. PostgreSQL 11, 12 und 13 erfordern Claude Code v2.1.290 oder später auf dem Gateway-Server. Das PostgreSQL-Projekt pflegt diese Versionen nicht mehr, verwenden Sie daher nach Möglichkeit eine neuere. |

79| Modell-Upstream | Amazon-Bedrock-Anmeldedaten, Claude Platform auf AWS Anmeldedaten, Google-Cloud-Anmeldedaten, eine Microsoft-Foundry-Ressource oder einen Anthropic-API-Schlüssel. Mehrere Upstreams werden mit Failover unterstützt. |79| Modell-Upstream | Amazon-Bedrock-Anmeldedaten, Claude Platform auf AWS Anmeldedaten, Google-Cloud-Anmeldedaten, eine Microsoft-Foundry-Ressource oder einen Anthropic-API-Schlüssel. Mehrere Upstreams werden mit Failover unterstützt. |

80| HTTPS | Das Gateway muss über `https://` von Entwickler-Laptops und von jedem Browser, der für die Anmeldung verwendet wird, erreichbar sein; das Gateway bedient die Geräteüberprüfungsseite auf dem gleichen Listener. Stellen Sie entweder ein TLS-Zertifikat über `listen.tls` bereit, oder führen Sie hinter einem TLS-terminierenden Ingress aus und setzen Sie `listen.public_url` auf den externen Ursprung in beiden Fällen. Bei `/login` akzeptiert Claude Code einen einfachen `http://`-Ursprung nur, wenn der Gateway-Host Loopback ist: `localhost`, `127.0.0.1` oder `::1`. |80| HTTPS | Das Gateway muss über `https://` von Entwickler-Laptops und von jedem Browser, der für die Anmeldung verwendet wird, erreichbar sein; das Gateway bedient die Geräteüberprüfungsseite auf dem gleichen Listener. Stellen Sie entweder ein TLS-Zertifikat über `listen.tls` bereit, oder führen Sie hinter einem TLS-terminierenden Ingress aus und setzen Sie `listen.public_url` auf den externen Ursprung in beiden Fällen. Bei `/login` akzeptiert Claude Code einen einfachen `http://`-Ursprung nur, wenn der Gateway-Host Loopback ist: `localhost`, `127.0.0.1` oder `::1`. |

81| Private-Netzwerk-Adresse | Bei `/login` erfordert Claude Code, dass der Hostname oder die IP-Adresse des Gateways nur zu privaten Adressen aufgelöst wird: RFC 1918, Link-lokal, CGNAT `100.64.0.0/10`, IPv6 ULA `fc00::/7` oder Loopback. Für ein von Ihnen gehostetes Gateway wird jede öffentliche Adresse außerhalb eines Blocks, den Sie deklarieren, abgelehnt; siehe das [Bedrohungsmodell](/docs/de/claude-apps-gateway-deploy#threat-model-summary) im Bereitstellungsleitfaden. Wenn Entwicklermaschinen HTTPS über einen Unternehmens-Proxy leiten, erfordert die Anmeldung auch, dass der Proxy-Host zu privaten Adressen aufgelöst wird; wenn nicht, fügen Sie den Gateway-Host zu `NO_PROXY` hinzu, damit die CLI direkt verbunden wird. Wenn Ihr internes Netzwerk aus öffentlichem IPv4-Adressraum nummeriert ist, den Ihre Organisation besitzt, [deklarieren Sie diese Blöcke](#allow-a-gateway-on-public-address-space-you-own), damit `/login` ein Gateway dort akzeptiert. |81| Private-Netzwerk-Adresse | Bei `/login` erfordert Claude Code, dass der Hostname oder die IP-Adresse des Gateways nur zu privaten Adressen aufgelöst wird: RFC 1918, Link-lokal, CGNAT `100.64.0.0/10`, IPv6 ULA `fc00::/7` oder Loopback. Für ein von Ihnen gehostetes Gateway wird jede öffentliche Adresse außerhalb eines Blocks, den Sie deklarieren, abgelehnt; siehe das [Bedrohungsmodell](/docs/de/claude-apps-gateway-deploy#threat-model-summary) im Bereitstellungsleitfaden. Wenn Entwicklermaschinen HTTPS über einen Unternehmens-Proxy leiten, erfordert die Anmeldung auch, dass der Proxy-Host zu privaten Adressen aufgelöst wird; wenn nicht, fügen Sie den Gateway-Host zu `NO_PROXY` hinzu, damit die CLI direkt verbunden wird. Wenn Ihr internes Netzwerk aus öffentlichem IPv4-Adressraum nummeriert ist, den Ihre Organisation besitzt, [deklarieren Sie diese Blöcke](#allow-a-gateway-on-public-address-space-you-own), damit `/login` ein Gateway dort akzeptiert. |

91 </Step>91 </Step>

92 92 

93 <Step title="Stellen Sie eine PostgreSQL-Datenbank bereit">93 <Step title="Stellen Sie eine PostgreSQL-Datenbank bereit">

94 Jedes Postgres 14 oder später funktioniert, einschließlich der kleinsten verwalteten Stufe. Das Gateway führt seine eigenen Schema-Migrationen beim Start aus, daher benötigt die Datenbankrolle Rechte zum Erstellen und Ändern von Tabellen; siehe [`store`](/docs/de/claude-apps-gateway-config#store).94 Verwenden Sie PostgreSQL 11 oder später. Die kleinste verwaltete Stufe reicht aus. Das Gateway führt seine eigenen Schema-Migrationen beim Start aus, daher benötigt die Datenbankrolle Rechte zum Erstellen und Ändern von Tabellen; siehe [`store`](/docs/de/claude-apps-gateway-config#store).

95 </Step>95 </Step>

96 96 

97 <Step title="Schreiben Sie gateway.yaml">97 <Step title="Schreiben Sie gateway.yaml">

132 auto_include_builtin_models: true132 auto_include_builtin_models: true

133 ```133 ```

134 134 

135 Diese Konfiguration reicht für eine funktionierende Anmeldeschleife mit dem Standard-Bedrock-Modellkatalog aus. Sobald es läuft, fügen Sie Pro-Gruppen-RBAC und verwaltete Einstellungen über [`managed.policies`](/docs/de/claude-apps-gateway-config#managed) hinzu, Telemetrie-Verteilung über [`telemetry`](/docs/de/claude-apps-gateway-config#telemetry) und Multi-Upstream-Failover, bereitgestellte Durchsatz-ARNs oder Nicht-US-Regionen über [`models`](/docs/de/claude-apps-gateway-config#models).135 Diese Konfiguration reicht für eine funktionierende Anmeldeschleife mit dem Standard-Modellkatalog von Amazon Bedrock aus. Sobald es läuft, fügen Sie Pro-Gruppen-RBAC und verwaltete Einstellungen über [`managed.policies`](/docs/de/claude-apps-gateway-config#managed) hinzu, Telemetrie-Verteilung über [`telemetry`](/docs/de/claude-apps-gateway-config#telemetry) und Multi-Upstream-Failover, bereitgestellte Durchsatz-ARNs oder Nicht-US-Regionen über [`models`](/docs/de/claude-apps-gateway-config#models).

136 136 

137 <Note>137 <Note>

138 Der Amazon-Bedrock-Upstream benötigt einen AWS-Principal mit `bedrock:InvokeModel` und `bedrock:InvokeModelWithResponseStream` auf beiden `inference-profile/us.anthropic.*`-ARNs und den zugrunde liegenden `foundation-model/anthropic.*`-ARNs. Er benötigt auch Anthropics einmalige Anwendungsform, die für das Konto aus der Bedrock-Konsole des Modellkatalogs eingereicht werden muss. Stellen Sie die Anmeldedaten mit IRSA auf EKS, einer ECS-Task-Rolle oder einem EC2-Instance-Profil bereit, anstatt statische Schlüssel zu verwenden. Die [`upstreams`-Referenz](/docs/de/claude-apps-gateway-config#upstreams) hat die vollständigen IAM-Details, die Cloud-übergreifende Anmeldedaten-Matrix und die `auth`-Blöcke für die anderen Anbieter.138 Der Amazon-Bedrock-Upstream benötigt einen AWS-Principal mit `bedrock:InvokeModel` und `bedrock:InvokeModelWithResponseStream` auf beiden `inference-profile/us.anthropic.*`-ARNs und den zugrunde liegenden `foundation-model/anthropic.*`-ARNs. Er benötigt auch Anthropics einmaliges Anwendungsfall-Formular, das für das Konto über den Modellkatalog der Bedrock-Konsole eingereicht werden muss.

139 

140 Stellen Sie die Anmeldedaten mit IRSA auf EKS, einer ECS-Task-Rolle oder einem EC2-Instance-Profil bereit, anstatt statische Schlüssel zu verwenden. Die [`upstreams`-Referenz](/docs/de/claude-apps-gateway-config#upstreams) hat die vollständigen IAM-Details, die Cloud-übergreifende Anmeldedaten-Matrix und die `auth`-Blöcke für die anderen Anbieter.

139 </Note>141 </Note>

140 </Step>142 </Step>

141 143 

170 volumes: { pgdata: }172 volumes: { pgdata: }

171 ```173 ```

172 174 

173 Das Gateway ist eine einzelne Linux-Binärdatei, die die Konfiguration liest, sich mit Postgres verbindet und seine Schema-Migrationen anwendet, OIDC-Erkennung gegen Ihren IdP ausführt, Upstream-Clients erstellt und mit dem Abhören beginnt. Der Start ist fail-closed für die Konfiguration, die Postgres-Verbindung, OIDC-Erkennung und Upstream-Client-Konstruktion. Wenn einer dieser Punkte unerreichbar oder falsch konfiguriert ist, beendet sich das Gateway mit einem Fehler, anstatt Datenverkehr in einem degradierten Zustand zu bedienen.175 Das Gateway ist eine einzelne Linux-Binärdatei, die die Konfiguration liest, sich mit Postgres verbindet und seine Schema-Migrationen anwendet, OIDC-Erkennung gegen Ihren IdP ausführt, Upstream-Clients erstellt und mit dem Abhören beginnt.

176 

177 Der Start ist fail-closed für die Konfiguration, die Postgres-Verbindung, OIDC-Erkennung und Upstream-Client-Konstruktion. Wenn einer dieser Punkte unerreichbar oder falsch konfiguriert ist, beendet sich das Gateway mit einem Fehler, anstatt Datenverkehr in einem degradierten Zustand zu bedienen.

174 178 

175 Ein erfolgreicher Start validiert nicht den Inferenzpfad, da Amazon Bedrock und Google Clouds Agent Platform Instance-Anmeldedaten bei der ersten Anfrage aufgelöst werden, nicht beim Start.179 Ein erfolgreicher Start validiert nicht den Inferenzpfad, da Amazon Bedrock und Google Clouds Agent Platform Instance-Anmeldedaten bei der ersten Anfrage aufgelöst werden, nicht beim Start.

176 180 

247 * **Erste Überprüfung schlägt fehl**: Der Start wurde nicht abgeschlossen; überprüfen Sie stderr251 * **Erste Überprüfung schlägt fehl**: Der Start wurde nicht abgeschlossen; überprüfen Sie stderr

248 * **Zweite Überprüfung schlägt fehl**: Postgres ist vom Gateway nicht erreichbar oder die Rolle kann nicht schreiben; überprüfen Sie die Verbindungszeichenfolge und Berechtigungen252 * **Zweite Überprüfung schlägt fehl**: Postgres ist vom Gateway nicht erreichbar oder die Rolle kann nicht schreiben; überprüfen Sie die Verbindungszeichenfolge und Berechtigungen

249 * **Dritte Überprüfung erreicht den IdP nicht**: Überprüfen Sie, dass der Redirect-URI des IdP genau `https://<gateway>/oauth/callback` entspricht253 * **Dritte Überprüfung erreicht den IdP nicht**: Überprüfen Sie, dass der Redirect-URI des IdP genau `https://<gateway>/oauth/callback` entspricht

250 * **Dritte Überprüfung erreicht den IdP, springt aber mit einem Fehler zurück**: Lesen Sie das Audit-Protokoll des Gateways, das jede Auth-Ablehnung mit dem Grund aufzeichnet, z. B. `email domain not allowed`254 * **Dritte Überprüfung erreicht den IdP, springt aber mit einem Fehler zurück**: Lesen Sie das Audit-Log des Gateways, das jede Auth-Ablehnung mit dem Grund aufzeichnet, z. B. `email domain not allowed`

251 </Step>255 </Step>

252 256 

253 <Step title="Melden Sie einen Entwickler an">257 <Step title="Melden Sie einen Entwickler an">

295 299 

296Der Entwickler drückt Enter, um sich zu verbinden. Die [Fingerabdruck-Abfrage beim ersten Verbinden](#connect-developers) wird immer noch angezeigt. Sobald die Datei auf einer Maschine vorhanden ist, sieht ein Entwickler, der die Gateway-Anmeldung nicht abgeschlossen hat, eine der unter [Administratorrichtlinie erfordert eine Cloud-Gateway-Anmeldung](/docs/de/errors#administrator-policy-requires-a-cloud-gateway-sign-in) beschriebenen Meldungen. Entwickler, die einen Cloud-Anbieter über eine Umgebungsvariable wie `CLAUDE_CODE_USE_BEDROCK` auswählen, benötigen die Gateway-Anmeldung nicht.300Der Entwickler drückt Enter, um sich zu verbinden. Die [Fingerabdruck-Abfrage beim ersten Verbinden](#connect-developers) wird immer noch angezeigt. Sobald die Datei auf einer Maschine vorhanden ist, sieht ein Entwickler, der die Gateway-Anmeldung nicht abgeschlossen hat, eine der unter [Administratorrichtlinie erfordert eine Cloud-Gateway-Anmeldung](/docs/de/errors#administrator-policy-requires-a-cloud-gateway-sign-in) beschriebenen Meldungen. Entwickler, die einen Cloud-Anbieter über eine Umgebungsvariable wie `CLAUDE_CODE_USE_BEDROCK` auswählen, benötigen die Gateway-Anmeldung nicht.

297 301 

298Ein Entwickler kann dies nicht manuell einrichten. Die Anmeldungsauswahl hat keine Gateway-Option, und `forceLoginGatewayUrl` wird in den eigenen Einstellungsdateien eines Entwicklers ignoriert. `forceLoginMethod` allein, ohne URL, lässt den Entwickler bei einer „Kontaktieren Sie Ihren IT-Administrator"-Nachricht. Die Anmeldeschlüssel gehören in die Datei, die Sie auf Maschinen pushen, nicht in den `managed.policies[].cli`-Block des Gateways, der nur bereits verbundene Clients erreicht.302Ein Entwickler kann dies nicht manuell einrichten. Die Anmeldungsauswahl hat keine Gateway-Option, und `forceLoginGatewayUrl` wird in den eigenen Einstellungsdateien eines Entwicklers ignoriert. `forceLoginMethod` allein, ohne URL, lässt den Entwickler bei einer „Kontaktieren Sie Ihren IT-Administrator“-Nachricht. Die Anmeldeschlüssel gehören in die Datei, die Sie auf Maschinen pushen, nicht in den `managed.policies[].cli`-Block des Gateways, der nur bereits verbundene Clients erreicht.

299 303 

300<h3 id="allow-a-gateway-on-public-address-space-you-own">304<h3 id="allow-a-gateway-on-public-address-space-you-own">

301 Ein Gateway auf öffentlichem Adressraum zulassen, den Sie besitzen305 Ein Gateway auf öffentlichem Adressraum zulassen, den Sie besitzen

460* **`blockedMarketplaces`**: eine übergeordnete Marketplace-Blockliste passiert und ergänzt jede Blockliste, die eine verwaltete Quelle setzt, da eine Blockliste nur weiter einschränken kann. Erfordert Claude Code v2.1.282 oder später.464* **`blockedMarketplaces`**: eine übergeordnete Marketplace-Blockliste passiert und ergänzt jede Blockliste, die eine verwaltete Quelle setzt, da eine Blockliste nur weiter einschränken kann. Erfordert Claude Code v2.1.282 oder später.

461* **`strictPluginOnlyCustomization`**: dieser Schlüssel passiert den Filter unabhängig von jeder Sperre, und er lässt Claude Code die eigene Anpassung des Entwicklers ignorieren, einschließlich schützender Hooks. Keine Sperre blockiert ihn.465* **`strictPluginOnlyCustomization`**: dieser Schlüssel passiert den Filter unabhängig von jeder Sperre, und er lässt Claude Code die eigene Anpassung des Entwicklers ignorieren, einschließlich schützender Hooks. Keine Sperre blockiert ihn.

462 466 

463Unter der Standardeinstellung „first wins" blockiert ein Admin-Wert den übergeordneten nur, wenn er sich in der Admin-Quelle mit der höchsten Priorität befindet, außer bei `allowedMcpServers`, solange die [MCP-Server-Sperre](#lock-behavior-across-sources) aktiv ist. Unter dem Merge-Opt-in `managedSourcesBehavior` legt [wie Claude Code verwaltete Quellen kombiniert](/docs/de/managed-settings#how-claude-code-combines-managed-sources) fest, welcher Quellenwert stattdessen gilt.467Unter der Standardeinstellung „first wins“ blockiert ein Admin-Wert den übergeordneten nur, wenn er sich in der Admin-Quelle mit der höchsten Priorität befindet, außer bei `allowedMcpServers`, solange die [MCP-Server-Sperre](#lock-behavior-across-sources) aktiv ist. Unter dem Merge-Opt-in `managedSourcesBehavior` legt [wie Claude Code verwaltete Quellen kombiniert](/docs/de/managed-settings#how-claude-code-combines-managed-sources) fest, welcher Quellenwert stattdessen gilt.

464 468 

465<h3 id="connect-claude-desktop">469<h3 id="connect-claude-desktop">

466 Claude Desktop verbinden470 Claude Desktop verbinden

91| `extra_auth_params` | Nein | Zusätzliche Abfrageparameter, die wörtlich an die IdP-Autorisierungsanfrage angehängt werden. Dies ist der Überschreibungsmechanismus für IdP-spezifisches Verhalten, wie `access_type: offline` für Google-Aktualisierungstoken, `domain_hint` für einige Entra-Mandanten oder `acr_values` für Step-up-Flows. Kann die vom Gateway verwalteten Protokollparameter nicht überschreiben: `state`, `nonce`, `redirect_uri`, PKCE, `scope`, `response_type`, `response_mode` und `client_id`. |91| `extra_auth_params` | Nein | Zusätzliche Abfrageparameter, die wörtlich an die IdP-Autorisierungsanfrage angehängt werden. Dies ist der Überschreibungsmechanismus für IdP-spezifisches Verhalten, wie `access_type: offline` für Google-Aktualisierungstoken, `domain_hint` für einige Entra-Mandanten oder `acr_values` für Step-up-Flows. Kann die vom Gateway verwalteten Protokollparameter nicht überschreiben: `state`, `nonce`, `redirect_uri`, PKCE, `scope`, `response_type`, `response_mode` und `client_id`. |

92| `userinfo_fallback` | Nein | Wenn das id\_token E-Mail oder Gruppen auslässt, rufen Sie diese von `/userinfo` ab. Erforderlich für Keycloak-Lightweight-Zugriffstokens, den Okta-Org-Server und ADFS-Minimal-Tokens. Das id\_token bleibt maßgeblich; userinfo füllt nur Lücken. Standard `false`. |92| `userinfo_fallback` | Nein | Wenn das id\_token E-Mail oder Gruppen auslässt, rufen Sie diese von `/userinfo` ab. Erforderlich für Keycloak-Lightweight-Zugriffstokens, den Okta-Org-Server und ADFS-Minimal-Tokens. Das id\_token bleibt maßgeblich; userinfo füllt nur Lücken. Standard `false`. |

93| `use_pkce` | Nein | Senden Sie eine PKCE-Herausforderung (S256) in der Autorisierungsanfrage. Standard `true`. Setzen Sie `false` nur, wenn Ihr IdP PKCE für diesen vertraulichen Client ablehnt. |93| `use_pkce` | Nein | Senden Sie eine PKCE-Herausforderung (S256) in der Autorisierungsanfrage. Standard `true`. Setzen Sie `false` nur, wenn Ihr IdP PKCE für diesen vertraulichen Client ablehnt. |

94| `clock_skew_seconds` | Nein | Tolerieren Sie Uhrenabweichungen beim Validieren von id\_token-Zeitansprüchen. Standard `0`, was streng ist. Erhöhen Sie, wenn Sie unmittelbar nach der Anmeldung aufgrund von Host-/IdP-Uhrenabweichung Fehler „Token abgelaufen / noch nicht gültig" sehen. |94| `clock_skew_seconds` | Nein | Tolerieren Sie Uhrenabweichungen beim Validieren von id\_token-Zeitansprüchen. Standard `0`, was streng ist. Erhöhen Sie, wenn Sie unmittelbar nach der Anmeldung aufgrund von Host-/IdP-Uhrenabweichung Fehler „Token abgelaufen / noch nicht gültig“ sehen. |

95| `token_endpoint_auth_method` | Nein | Wie sich das Gateway beim Token-Endpunkt des IdP authentifiziert: `client_secret_basic`, `client_secret_post` oder `private_key_jwt` für [zertifikatbasierte Client-Authentifizierung](#certificate-client-authentication). Standardmäßig wählt das Gateway eine der beiden `client_secret`-Methoden anhand dessen, was der IdP ankündigt. |95| `token_endpoint_auth_method` | Nein | Wie sich das Gateway beim Token-Endpunkt des IdP authentifiziert: `client_secret_basic`, `client_secret_post` oder `private_key_jwt` für [zertifikatbasierte Client-Authentifizierung](#certificate-client-authentication). Standardmäßig wählt das Gateway eine der beiden `client_secret`-Methoden anhand dessen, was der IdP ankündigt. |

96| `client_assertion` | Mit `private_key_jwt` | Ein Block mit `private_key_pem` und `certificate_pem`: der private Schlüssel und das Zertifikat für [zertifikatbasierte Client-Authentifizierung](#certificate-client-authentication). Erfordert v2.1.284 oder später. |96| `client_assertion` | Mit `private_key_jwt` | Ein Block mit `private_key_pem` und `certificate_pem`: der private Schlüssel und das Zertifikat für [zertifikatbasierte Client-Authentifizierung](#certificate-client-authentication). Erfordert v2.1.284 oder später. |

97| `id_token_signed_response_alg` | Nein | Erwarteter id\_token-Signaturalgorithmus. Standard `RS256`. Setzen Sie für IdPs, die mit ES256, PS256 oder EdDSA signieren. |97| `id_token_signed_response_alg` | Nein | Erwarteter id\_token-Signaturalgorithmus. Standard `RS256`. Setzen Sie für IdPs, die mit ES256, PS256 oder EdDSA signieren. |

158Das Gateway liest Schlüssel und Zertifikat einmal beim Start, eine geänderte Datei wird also erst nach einem Neustart wirksam. Rotieren Sie in dieser Reihenfolge, damit keine Token-Anfrage ein Zertifikat vorlegt, das dem IdP nicht vorliegt:158Das Gateway liest Schlüssel und Zertifikat einmal beim Start, eine geänderte Datei wird also erst nach einem Neustart wirksam. Rotieren Sie in dieser Reihenfolge, damit keine Token-Anfrage ein Zertifikat vorlegt, das dem IdP nicht vorliegt:

159 159 

1601. Laden Sie das neue Zertifikat zusätzlich zum alten beim IdP hoch.1601. Laden Sie das neue Zertifikat zusätzlich zum alten beim IdP hoch.

1612. Ersetzen Sie die Schlüssel- und Zertifikatsdateien, die `gateway.yaml` lädt, und starten Sie dann das Gateway neu.1612. Ersetzen Sie die Schlüssel- und Zertifikatsdateien, die `gateway.yaml` lädt, und starten Sie dann das Gateway neu. Wenn Sie mehrere Replikate betreiben, funktioniert ein [Rolling Restart](/docs/de/claude-apps-gateway-deploy#upgrades), da der IdP beide Zertifikate hat, bis Sie das alte entfernen.

1623. Entfernen Sie das alte Zertifikat beim IdP.1623. Nachdem jedes Replikat neu gestartet wurde, entfernen Sie das alte Zertifikat beim IdP.

163 163 

164<h4 id="idp-requests-through-a-forward-proxy">164<h4 id="idp-requests-through-a-forward-proxy">

165 IdP-Anfragen durch einen Forward-Proxy165 IdP-Anfragen durch einen Forward-Proxy

227 227 

228| Feld | Erforderlich | Beschreibung |228| Feld | Erforderlich | Beschreibung |

229| - | - | - |229| - | - | - |

230| `postgres_url` | Ja | `postgres://` oder `postgresql://` URL. Erforderlich: das Device-Grant-Rendezvous, wo der Browser-Callback schreibt und die Polling-CLI liest, benötigt Zustand über Replikate hinweg. Das Gateway führt seine eigenen Schema-Migrationen beim Start und bei Upgrades aus, daher benötigt die Rolle Rechte zum Erstellen und Ändern von Tabellen im Zielschema. Siehe [Upgrades](/docs/de/claude-apps-gateway-deploy#upgrades) und [Postgres](/docs/de/claude-apps-gateway-deploy#postgres). |230| `postgres_url` | Ja | `postgres://`- oder `postgresql://`-URL mit einem einzigen Host, keine kommagetrennte Liste. Das Gateway führt seine eigenen Schema-Migrationen beim Start und bei Upgrades aus, daher benötigt die Rolle Rechte zum Erstellen und Ändern von Tabellen im Zielschema. Siehe [Upgrades](/docs/de/claude-apps-gateway-deploy#upgrades) und [Postgres](/docs/de/claude-apps-gateway-deploy#postgres). |

231| `username` | Nein | Überschreibt den Benutzer in `postgres_url` |231| `username` | Nein | Überschreibt den Benutzer in `postgres_url` |

232| `password` | Nein | Datenbank-Anmeldedaten. Setzen Sie sie hier anstelle von `postgres_url`, damit die Anmeldedaten nicht in der URL stehen. Akzeptiert beliebige Zeichen und hat Vorrang vor Anmeldedaten in der URL. |232| `password` | Nein | Datenbank-Anmeldedaten. Setzen Sie sie hier anstelle von `postgres_url`, damit die Anmeldedaten nicht in der URL stehen. Akzeptiert beliebige Zeichen und hat Vorrang vor Anmeldedaten in der URL. |

233| `max_connections` | Nein | Postgres-Verbindungspool-Größe pro Replikat. Standard `5`, was konservativ und schonend für gemeinsam genutzte Datenbanken ist. Mit aktivierten [Ausgabenlimits](#admin) führt der Hot-Path einige Operationen pro Inference-Anfrage durch, daher erhöhen Sie den Wert für eine dedizierte Datenbank unter Last, und halten Sie Replikate × diesen Wert unter dem `max_connections` der Datenbank. |233| `max_connections` | Nein | Postgres-Verbindungspool-Größe pro Replikat. Standard `5`, was konservativ und schonend für gemeinsam genutzte Datenbanken ist. Mit aktivierten [Ausgabenlimits](#admin) führt der Hot-Path einige Operationen pro Inference-Anfrage durch, daher erhöhen Sie den Wert für eine dedizierte Datenbank unter Last, und halten Sie Replikate × diesen Wert unter dem `max_connections` der Datenbank. |

249 Postgres249 Postgres

250</h3>250</h3>

251 251 

252Das Gateway speichert seinen Zustand in einer PostgreSQL-Datenbank:

253 

254* **Datenbank**: PostgreSQL selbst, selbst gehostet oder verwaltet, in der [Mindestversion](/docs/de/claude-apps-gateway#prerequisites) oder später. Datenbanken, die nur das Postgres-Protokoll implementieren, wie etwa verteilte SQL-Datenbanken, werden nicht unterstützt.

255* **Adresse**: `store.postgres_url` akzeptiert einen Host. Wenn die Datenbank mehrere Knoten hat, verwenden Sie die Adresse, die ihnen vorgelagert ist, etwa den Endpunkt Ihres verwalteten Dienstes, einen Load Balancer oder eine virtuelle IP. Setzen Sie eine [Readiness-Grace-Periode](#readiness-grace-period), die länger ist, als ein Failover dauert.

256 

252Das Gateway hält fünf Datentabellen plus eine `_migrations`-Tabelle, alle erstellt durch seine Boot-Zeit-Migrationen:257Das Gateway hält fünf Datentabellen plus eine `_migrations`-Tabelle, alle erstellt durch seine Boot-Zeit-Migrationen:

253 258 

254| Tabelle | Inhalt | Aufbewahrung |259| Tabelle | Inhalt | Aufbewahrung |

396| CLI `/login`: `Could not resolve the configured HTTP proxy` | Der Hostname in `HTTPS_PROXY` oder `HTTP_PROXY` wird von der Entwicklermaschine nicht aufgelöst, typischerweise weil sie nicht mit dem Unternehmens-Netzwerk verbunden ist | Lassen Sie den Entwickler sich mit Ihrem Netzwerk oder VPN verbinden und versuchen Sie erneut, oder beheben Sie die Proxy-URL |401| CLI `/login`: `Could not resolve the configured HTTP proxy` | Der Hostname in `HTTPS_PROXY` oder `HTTP_PROXY` wird von der Entwicklermaschine nicht aufgelöst, typischerweise weil sie nicht mit dem Unternehmens-Netzwerk verbunden ist | Lassen Sie den Entwickler sich mit Ihrem Netzwerk oder VPN verbinden und versuchen Sie erneut, oder beheben Sie die Proxy-URL |

397| CLI `/login`: `Could not resolve gateway host <host>` | Die Maschine kann den internen DNS-Namen des Gateways nicht auflösen, typischerweise weil sie nicht im Unternehmens-Netzwerk ist | Lassen Sie den Entwickler sich mit Ihrem Netzwerk oder VPN verbinden und versuchen Sie dann `/login` erneut |402| CLI `/login`: `Could not resolve gateway host <host>` | Die Maschine kann den internen DNS-Namen des Gateways nicht auflösen, typischerweise weil sie nicht im Unternehmens-Netzwerk ist | Lassen Sie den Entwickler sich mit Ihrem Netzwerk oder VPN verbinden und versuchen Sie dann `/login` erneut |

398| Boot beendet mit einem Konfigurationsvalidierungsfehler, der `store.postgres_url` benennt | Kein Postgres konfiguriert; das Gateway erfordert Postgres | Setzen Sie `store.postgres_url`. Für lokale Entwicklung verwenden Sie einen Wegwerf-Container: `docker run --rm -p 5432:5432 -e POSTGRES_HOST_AUTH_METHOD=trust postgres`. |403| Boot beendet mit einem Konfigurationsvalidierungsfehler, der `store.postgres_url` benennt | Kein Postgres konfiguriert; das Gateway erfordert Postgres | Setzen Sie `store.postgres_url`. Für lokale Entwicklung verwenden Sie einen Wegwerf-Container: `docker run --rm -p 5432:5432 -e POSTGRES_HOST_AUTH_METHOD=trust postgres`. |

404| Boot beendet: `store.postgres_url in <path> is not a URL the gateway can read`, oder vor v2.1.290 ein bloßes `Invalid URL` oder `URI error` | Die URL kann nicht geparst werden, zum Beispiel weil sie mehr als einen Host auflistet oder ihr Passwort ein nicht kodiertes `/`, `?`, `#` oder `%` enthält | Geben Sie [einen Host](#postgres) an, und verschieben Sie das Passwort in [`store.password`](/docs/de/claude-apps-gateway-config#store) |

399| Boot beendet: `requires the native binary` | Läuft unter Node statt der nativen Binärdatei | Installieren Sie Claude Code mit einer der [Standalone-Installationsmethoden](/docs/de/setup) |405| Boot beendet: `requires the native binary` | Läuft unter Node statt der nativen Binärdatei | Installieren Sie Claude Code mit einer der [Standalone-Installationsmethoden](/docs/de/setup) |

400| Boot beendet mit einem OIDC-Discovery-Fehler nach `config.load` | `oidc.issuer` nicht erreichbar oder TLS-Kette nicht vertraut | Überprüfen Sie, dass der Aussteller vom Pod erreichbar ist und `/.well-known/openid-configuration` bedient. Setzen Sie `ca_cert_pem` für private PKI. Wenn der Pod den IdP nur über einen Forward-Proxy erreicht, setzen Sie [`oidc.use_proxy: true`](/docs/de/claude-apps-gateway-config#idp-requests-through-a-forward-proxy); bei Versionen vor v2.1.227 geben Sie dem Pod stattdessen eine direkte Route zu jedem der IdP-Endpunkte. Wenn der Pod auch den Hostnamen des IdP nicht auflösen kann, oder der Proxy verweigert `CONNECT` zu einer IP-Adresse, siehe [Nur-Proxy-Ausgang](/docs/de/claude-apps-gateway-config#proxy-only-egress), das v2.1.277 oder später erfordert. |406| Boot beendet mit einem OIDC-Discovery-Fehler nach `config.load` | `oidc.issuer` nicht erreichbar oder TLS-Kette nicht vertraut | Überprüfen Sie, dass der Aussteller vom Pod erreichbar ist und `/.well-known/openid-configuration` bedient. Setzen Sie `ca_cert_pem` für private PKI. Wenn der Pod den IdP nur über einen Forward-Proxy erreicht, setzen Sie [`oidc.use_proxy: true`](/docs/de/claude-apps-gateway-config#idp-requests-through-a-forward-proxy); bei Versionen vor v2.1.227 geben Sie dem Pod stattdessen eine direkte Route zu jedem der IdP-Endpunkte. Wenn der Pod auch den Hostnamen des IdP nicht auflösen kann, oder der Proxy verweigert `CONNECT` zu einer IP-Adresse, siehe [Nur-Proxy-Ausgang](/docs/de/claude-apps-gateway-config#proxy-only-egress), das v2.1.277 oder später erfordert. |

401| Boot beendet mit einem Postgres-Berechtigungsfehler | Die Datenbankrolle fehlen DDL-Rechte auf ihrem Schema | Gewähren Sie der Rolle `CREATE` auf dem Gateway-Schema, damit sie seine Tabellen beim Boot erstellen und ändern kann |407| Boot beendet mit einem Postgres-Berechtigungsfehler | Die Datenbankrolle fehlen DDL-Rechte auf ihrem Schema | Gewähren Sie der Rolle `CREATE` auf dem Gateway-Schema, damit sie seine Tabellen beim Boot erstellen und ändern kann |

402| Protokoll: `could not connect to Postgres at boot, attempt 1 of 3` | Die Datenbank war nicht erreichbar, als das Gateway gestartet wurde, zum Beispiel auf einer kalten Instanz, deren Netzwerk noch aufgebaut wird | Wenn das Gateway dann das Booten beendet, ist keine Aktion erforderlich. Wenn die Datenbank nicht erreichbar ist, versucht das Gateway die Verbindung dreimal, zwei Sekunden auseinander, bevor es beendet wird. Wenn es mit `could not connect to Postgres` beendet wird, überprüfen Sie `store.postgres_url` und den Netzwerkpfad zur Datenbank. Wenn die Versuche Timeout statt Ablehnung sind, erhöhen Sie [`store.connect_timeout_seconds`](/docs/de/claude-apps-gateway-config#store), um jedem länger zu geben. |408| Protokoll: `could not connect to Postgres at boot, attempt 1 of 3` | Die Datenbank war nicht erreichbar, als das Gateway gestartet wurde, zum Beispiel auf einer kalten Instanz, deren Netzwerk noch aufgebaut wird | Wenn das Gateway dann das Booten beendet, ist keine Aktion erforderlich. Wenn die Datenbank nicht erreichbar ist, versucht das Gateway die Verbindung dreimal, zwei Sekunden auseinander, bevor es beendet wird. Wenn es mit `could not connect to Postgres` beendet wird, überprüfen Sie `store.postgres_url`, einschließlich dessen, dass sie genau einen Host benennt, sowie den Netzwerkpfad zur Datenbank. Wenn die Versuche Timeout statt Ablehnung sind, erhöhen Sie [`store.connect_timeout_seconds`](/docs/de/claude-apps-gateway-config#store), um jedem länger zu geben. |

403| `/oauth/callback` zeigt "Sign-in could not be completed" | E-Mail-Domain abgelehnt, id\_token-Validierung fehlgeschlagen, oder `email_verified` ist explizit `false`, was das Gateway immer ohne Überschreibung ablehnt | Überprüfen Sie `allowed_email_domains` und dass der IdP einen verifizierten `email`-Claim zurückgibt. Für `email_verified: false` beheben Sie die IdP-seitige Verifikation. Wenn Ihr IdP E-Mail unter einem anderen Claim-Namen ausgibt, setzen Sie `oidc.email_claim`. |409| `/oauth/callback` zeigt "Sign-in could not be completed" | E-Mail-Domain abgelehnt, id\_token-Validierung fehlgeschlagen, oder `email_verified` ist explizit `false`, was das Gateway immer ohne Überschreibung ablehnt | Überprüfen Sie `allowed_email_domains` und dass der IdP einen verifizierten `email`-Claim zurückgibt. Für `email_verified: false` beheben Sie die IdP-seitige Verifikation. Wenn Ihr IdP E-Mail unter einem anderen Claim-Namen ausgibt, setzen Sie `oidc.email_claim`. |

404| Protokoll: `token exchange failed request_id=<id>: id_token missing email claim` | Der IdP enthält `email` nicht standardmäßig im id\_token. Diese Ablehnung wird nur ausgelöst, wenn `allowed_email_domains` gesetzt ist; ohne sie prägt ein fehlende E-Mail eine Sitzung ohne E-Mail | Konfigurieren Sie den IdP, um `email` im id\_token auszugeben. Okta: Fügen Sie `email` zu den ID-Token-Claims eines benutzerdefinierten Autorisierungsservers hinzu. Entra: Fügen Sie `email` als optionalen Claim bei der App-Registrierung hinzu. PingFederate: Aktivieren Sie eine OpenID-Connect-Richtlinie, die `email` ausgibt. Wenn der IdP `email` vom Userinfo-Endpoint bedient, aber nicht im id\_token einbeziehen wird, wie der Okta-Org-Autorisierungsserver, setzen Sie `oidc.userinfo_fallback: true`. |410| Protokoll: `token exchange failed request_id=<id>: id_token missing email claim` | Der IdP enthält `email` nicht standardmäßig im id\_token. Diese Ablehnung wird nur ausgelöst, wenn `allowed_email_domains` gesetzt ist; ohne sie prägt ein fehlende E-Mail eine Sitzung ohne E-Mail | Konfigurieren Sie den IdP, um `email` im id\_token auszugeben. Okta: Fügen Sie `email` zu den ID-Token-Claims eines benutzerdefinierten Autorisierungsservers hinzu. Entra: Fügen Sie `email` als optionalen Claim bei der App-Registrierung hinzu. PingFederate: Aktivieren Sie eine OpenID-Connect-Richtlinie, die `email` ausgibt. Wenn der IdP `email` vom Userinfo-Endpoint bedient, aber nicht im id\_token einbeziehen wird, wie der Okta-Org-Autorisierungsserver, setzen Sie `oidc.userinfo_fallback: true`. |

405| Protokoll: `refresh failed request_id=<id>: invalid_token (…) (at userinfo_no_id_token, …)`, und Entwickler sehen `Cloud gateway session expired` alle `session.ttl_hours` | Der IdP akzeptierte den Refresh-Token, gab aber keinen id\_token damit zurück, daher fragte das Gateway den Userinfo-Endpoint des IdP nach den Claims des Benutzers. Der IdP lehnte den erneuerten Access-Token dort ab. Das Gateway antwortet `temporarily_unavailable`, daher behält Claude Code den Refresh-Token, kann aber die Sitzung nicht erneuern. Gateway-Versionen vor v2.1.260 protokollieren dieselbe Zeile ohne das `(at …)`-Detail. | Setzen Sie [`oidc.scope_on_refresh: true`](/docs/de/claude-apps-gateway-config#oidc), verfügbar in Gateway v2.1.260 oder später, damit die Refresh-Anfrage erneut nach `openid` fragt. Einige IdPs, wie Okta, geben einen id\_token bei Refresh nur zurück, wenn gefragt. Auf PingFederate aktivieren Sie stattdessen **Return ID Token On Refresh Grant** unter **Applications > OAuth > OpenID Connect Policy Management**. Der Schlüssel ändert das Verhalten von PingFederate nicht. Für andere IdPs, die ihn immer noch weglassen, überprüfen Sie, ob der Userinfo-Endpoint Access-Token akzeptiert, die von einem Refresh ausgestellt wurden. Als Übergangslösung erhöhen Sie [`session.ttl_hours`](/docs/de/claude-apps-gateway-config#session). Siehe [Identity-Provider-Setup](#identity-provider-setup) für den Deprovisioning-Tradeoff. |411| Protokoll: `refresh failed request_id=<id>: invalid_token (…) (at userinfo_no_id_token, …)`, und Entwickler sehen `Cloud gateway session expired` alle `session.ttl_hours` | Der IdP akzeptierte den Refresh-Token, gab aber keinen id\_token damit zurück, daher fragte das Gateway den Userinfo-Endpoint des IdP nach den Claims des Benutzers. Der IdP lehnte den erneuerten Access-Token dort ab. Das Gateway antwortet `temporarily_unavailable`, daher behält Claude Code den Refresh-Token, kann aber die Sitzung nicht erneuern. Gateway-Versionen vor v2.1.260 protokollieren dieselbe Zeile ohne das `(at …)`-Detail. | Setzen Sie [`oidc.scope_on_refresh: true`](/docs/de/claude-apps-gateway-config#oidc), verfügbar in Gateway v2.1.260 oder später, damit die Refresh-Anfrage erneut nach `openid` fragt. Einige IdPs, wie Okta, geben einen id\_token bei Refresh nur zurück, wenn gefragt. Auf PingFederate aktivieren Sie stattdessen **Return ID Token On Refresh Grant** unter **Applications > OAuth > OpenID Connect Policy Management**. Der Schlüssel ändert das Verhalten von PingFederate nicht. Für andere IdPs, die ihn immer noch weglassen, überprüfen Sie, ob der Userinfo-Endpoint Access-Token akzeptiert, die von einem Refresh ausgestellt wurden. Als Übergangslösung erhöhen Sie [`session.ttl_hours`](/docs/de/claude-apps-gateway-config#session). Siehe [Identity-Provider-Setup](#identity-provider-setup) für den Deprovisioning-Tradeoff. |

169 </Step>169 </Step>

170 170 

171 <Step title="Stellen Sie Amazon RDS für PostgreSQL bereit">171 <Step title="Stellen Sie Amazon RDS für PostgreSQL bereit">

172 Die Instanz läuft in den privaten Subnetzen ohne öffentliche Adresse und mit aktivierter Speicherverschlüsselung. Die Engine-Version ist auf Postgres 16 festgelegt, was den unterstützten Boden des Gateways von PostgreSQL 14 erfüllt und garantiert, dass die Parametergruppe unten mit der Instanz übereinstimmt.172 Die Instanz läuft mit Postgres 16 in den privaten Subnetzen, ohne öffentliche Adresse und mit aktivierter Speicherverschlüsselung.

173 173 

174 Erstellen Sie zunächst die Subnet-Gruppe, die die Datenbank in den privaten Subnetzen platziert, und eine Parametergruppe mit `rds.force_ssl=1`, damit der Server Klartextverbindungen ablehnt. Die Engine-Version ist einmal festgelegt, da die Parametergruppen-Familie mit der Engine-Hauptversion übereinstimmen muss, die die Instanz ausführt:174 Erstellen Sie zunächst die Subnet-Gruppe, die die Datenbank in den privaten Subnetzen platziert, und eine Parametergruppe mit `rds.force_ssl=1`, damit der Server Klartextverbindungen ablehnt. Die Engine-Version ist einmal festgelegt, da die Parametergruppen-Familie mit der Engine-Hauptversion übereinstimmen muss, die die Instanz ausführt:

175 175 

201 --no-publicly-accessible --storage-encrypted201 --no-publicly-accessible --storage-encrypted

202 ```202 ```

203 203 

204 Das Literal `--master-user-password` Argument ist in der Prozesstabelle und in Audit-/EDR-Protokollen sichtbar, während der Befehl ausgeführt wird, die gleiche Exposition, die der Geheimnisse-Schritt behandelt. Auf einem gemeinsamen oder überwachten Host übergeben Sie das Passwort stattdessen über `--cli-input-json` aus einer `0600` Datei, wie es das `setup.sh` des Bundles tut.204 Das Literal `--master-user-password` Argument ist in der Prozesstabelle und in Audit-/EDR-Logs sichtbar, während der Befehl ausgeführt wird, die gleiche Exposition, die der Geheimnisse-Schritt behandelt. Auf einem gemeinsamen oder überwachten Host übergeben Sie das Passwort stattdessen über `--cli-input-json` aus einer `0600` Datei, wie es das `setup.sh` des Bundles tut.

205 205 

206 Warten Sie, bis die Instanz hochfährt, was mehrere Minuten dauern kann, lesen Sie dann ihren privaten Endpunkt und stellen Sie die Verbindungszeichenfolge zusammen, die das Gateway verwendet:206 Warten Sie, bis die Instanz hochfährt, was mehrere Minuten dauern kann, lesen Sie dann ihren privaten Endpunkt und stellen Sie die Verbindungszeichenfolge zusammen, die das Gateway verwendet:

207 207 

223 Zwei `listen` Felder beschreiben, was das Gateway frontet:223 Zwei `listen` Felder beschreiben, was das Gateway frontet:

224 224 

225 * `public_url`: die externe `https://` Herkunft, erforderlich für jeden nicht-Loopback-Bind; siehe die [`listen` Referenz](/docs/de/claude-apps-gateway-config#listen). Das Gateway erstellt den IdP `redirect_uri` und sein Discovery-Dokument nur aus diesem Wert, niemals aus `X-Forwarded-*` Headern.225 * `public_url`: die externe `https://` Herkunft, erforderlich für jeden nicht-Loopback-Bind; siehe die [`listen` Referenz](/docs/de/claude-apps-gateway-config#listen). Das Gateway erstellt den IdP `redirect_uri` und sein Discovery-Dokument nur aus diesem Wert, niemals aus `X-Forwarded-*` Headern.

226 * `trusted_proxies`: die Quellbereiche des Front-End. Das Gateway berücksichtigt `X-Forwarded-For` nur, wenn der TCP-Peer in dieser Liste ist, geht dann die Kette über vertrauenswürdige Hops, sodass Anmelderate-Limits pro IP und Audit-Events Entwickler-IPs statt der Load-Balancer-IP aufzeichnen.226 * `trusted_proxies`: die Quellbereiche des Front-End. Das Gateway berücksichtigt `X-Forwarded-For` nur, wenn der TCP-Peer in dieser Liste ist, geht dann die Kette über vertrauenswürdige Hops, sodass Anmelde-Rate-Limits pro IP und Audit-Events Entwickler-IPs statt der Load-Balancer-IP aufzeichnen.

227 227 

228 Auf beiden Pfaden ist das Front-End ein interner ALB, ob direkt erstellt oder vom AWS Load Balancer Controller, und ALB-Knoten nehmen Adressen aus den Subnetzen, an die sie angehängt sind, daher setzen Sie `trusted_proxies` auf die CIDRs dieser Subnetze. Dies vertraut jedem Host in diesen Subnetzen als Proxy. Halten Sie die Ingress-Quelle des ALB, Ihre Unternehmens-CIDR, davon ab, sich zu überlappen, und teilen Sie die Subnetze nicht mit nicht vertrauenswürdigen Workloads, die Client-IPs über `X-Forwarded-For` fälschen könnten.228 Auf beiden Pfaden ist das Front-End ein interner ALB, ob direkt erstellt oder vom AWS Load Balancer Controller, und ALB-Knoten nehmen Adressen aus den Subnetzen, an die sie angehängt sind, daher setzen Sie `trusted_proxies` auf die CIDRs dieser Subnetze. Dies vertraut jedem Host in diesen Subnetzen als Proxy. Halten Sie die Ingress-Quelle des ALB, Ihre Unternehmens-CIDR, davon ab, sich zu überlappen, und teilen Sie die Subnetze nicht mit nicht vertrauenswürdigen Workloads, die Client-IPs über `X-Forwarded-For` fälschen könnten.

229 229 

286 Beachten Sie die ARN, die jeder Aufruf ausgibt; die ECS-Task-Definition referenziert Geheimnisse nach ARN.286 Beachten Sie die ARN, die jeder Aufruf ausgibt; die ECS-Task-Definition referenziert Geheimnisse nach ARN.

287 287 

288 <Note>288 <Note>

289 Literal `--secret-string` Argumente sind in der Prozesstabelle und in Audit-/EDR-Protokollen sichtbar, während jeder Befehl ausgeführt wird. Auf einem gemeinsamen oder überwachten Host legen Sie den Wert in eine `0600` Datei und übergeben Sie stattdessen `--secret-string file://<path>`. Das `setup.sh` des Bundles hält Geheimniswerte auf die gleiche Weise aus dem Prozess-argv, indem es `0600` temporäre Dateien an `--cli-input-json` übergibt.289 Literal `--secret-string` Argumente sind in der Prozesstabelle und in Audit-/EDR-Logs sichtbar, während jeder Befehl ausgeführt wird. Auf einem gemeinsamen oder überwachten Host legen Sie den Wert in eine `0600` Datei und übergeben Sie stattdessen `--secret-string file://<path>`. Das `setup.sh` des Bundles hält Geheimniswerte auf die gleiche Weise aus dem Prozess-argv, indem es `0600` temporäre Dateien an `--cli-input-json` übergibt.

290 </Note>290 </Note>

291 291 

292 Im Gegensatz zu den Geheimnissen enthält `gateway.yaml` selbst keine Geheimniswerte, da jede Anmeldedaten beim Start über [`${VAR}` oder `${file:...}` Erweiterung](/docs/de/claude-apps-gateway-config#secret-expansion) aufgelöst wird. Wie alles den Container erreicht, unterscheidet sich je nach Pfad:292 Im Gegensatz zu den Geheimnissen enthält `gateway.yaml` selbst keine Geheimniswerte, da alle Anmeldedaten beim Start über [`${VAR}` oder `${file:...}` Erweiterung](/docs/de/claude-apps-gateway-config#secret-expansion) aufgelöst werden. Wie alles den Container erreicht, unterscheidet sich je nach Pfad:

293 293 

294 * Auf ECS kopiert der Build des nächsten Schritts `gateway.yaml` in das Image bei `/etc/claude/gateway.yaml`, und die Task-Definition injiziert die drei Geheimnisse als Umgebungsvariablen über sein `secrets` Feld, daher referenziert die YAML `${GATEWAY_JWT_SECRET}`, `${OIDC_CLIENT_SECRET}` und `${GATEWAY_POSTGRES_URL}`.294 * Auf ECS kopiert der Build des nächsten Schritts `gateway.yaml` in das Image bei `/etc/claude/gateway.yaml`, und die Task-Definition injiziert die drei Geheimnisse als Umgebungsvariablen über ihr `secrets` Feld, daher referenziert die YAML `${GATEWAY_JWT_SECRET}`, `${OIDC_CLIENT_SECRET}` und `${GATEWAY_POSTGRES_URL}`.

295 * Auf EKS mounten Sie `gateway.yaml` aus einer ConfigMap und die Geheimnisse als Dateien bei `/secrets`, referenziert als `${file:/secrets/...}`. Beziehen Sie die Kubernetes Secrets aus Secrets Manager mit dem External Secrets Operator oder dem AWS-Provider des Secrets Store CSI-Treibers, oder erstellen Sie sie direkt mit `kubectl`.295 * Auf EKS mounten Sie `gateway.yaml` aus einer ConfigMap und die Geheimnisse als Dateien bei `/secrets`, referenziert als `${file:/secrets/...}`. Beziehen Sie die Kubernetes Secrets aus Secrets Manager mit dem External Secrets Operator oder dem AWS-Provider des Secrets Store CSI-Treibers, oder erstellen Sie sie direkt mit `kubectl`.

296 </Step>296 </Step>

297 297 

335 <Step title="Bereitstellen">335 <Step title="Bereitstellen">

336 <Tabs>336 <Tabs>

337 <Tab title="ECS Fargate">337 <Tab title="ECS Fargate">

338 Erstellen Sie den Cluster und eine Log-Gruppe für die stderr des Gateways, die sowohl seine Audit-Events als auch Betriebsprotokolle trägt. Die Aufbewahrung ist ein separater Aufruf, und ohne eine CloudWatch behält die Protokolle für immer; richten Sie die 90 Tage auf Ihre Audit-Aufbewahrungsrichtlinie aus:338 Erstellen Sie den Cluster und eine Log-Gruppe für die stderr des Gateways, die sowohl seine Audit-Events als auch Betriebslogs trägt. Die Aufbewahrung ist ein separater Aufruf, und ohne einen behält CloudWatch die Logs für immer; richten Sie die 90 Tage auf Ihre Audit-Aufbewahrungsrichtlinie aus:

339 339 

340 ```bash theme={null}340 ```bash theme={null}

341 aws ecs create-cluster --cluster-name claude-gateway341 aws ecs create-cluster --cluster-name claude-gateway

401 401 

402 Fügen Sie den HTTPS-Listener hinzu. `--ssl-policy` pinnt einen modernen TLS-Boden, da das Weglassen auf die Legacy-Standard-Richtlinie `ELBSecurityPolicy-2016-08` zurückfällt, die immer noch TLS 1.0/1.1 akzeptiert.402 Fügen Sie den HTTPS-Listener hinzu. `--ssl-policy` pinnt einen modernen TLS-Boden, da das Weglassen auf die Legacy-Standard-Richtlinie `ELBSecurityPolicy-2016-08` zurückfällt, die immer noch TLS 1.0/1.1 akzeptiert.

403 403 

404 Der ALB schließt eine Verbindung nach 60 Sekunden ohne Daten standardmäßig. Die Keepalive-Pings des Gateways halten Streams innerhalb dieses Standards, daher erhöht das Erhöhen des Timeouts die Marge über der Ping-Kadenz; die [Troubleshooting](#troubleshooting) Zeile auf abgebrochenen Streams behandelt den Mechanismus und ältere Gateways. Die folgenden Befehle fügen den Listener hinzu und erhöhen das Timeout:404 Der ALB schließt eine Verbindung nach 60 Sekunden ohne Daten standardmäßig. Die Keepalive-Pings des Gateways halten Streams innerhalb dieses Standards, daher erhöht das Erhöhen des Timeouts die Marge über der Ping-Kadenz; die Zeile zu abgebrochenen Streams in der [Fehlerbehebung](#troubleshooting) behandelt den Mechanismus und ältere Gateways. Die folgenden Befehle fügen den Listener hinzu und erhöhen den Timeout:

405 405 

406 ```bash theme={null}406 ```bash theme={null}

407 aws elbv2 create-listener --load-balancer-arn "$ALB_ARN" \407 aws elbv2 create-listener --load-balancer-arn "$ALB_ARN" \

425 --load-balancers "targetGroupArn=$TG_ARN,containerName=gateway,containerPort=8080"425 --load-balancers "targetGroupArn=$TG_ARN,containerName=gateway,containerPort=8080"

426 ```426 ```

427 427 

428 Die 60-Sekunden-Gnadenfrist gibt einer kalten Task Zeit, das Image zu ziehen, sich mit dem Store zu verbinden und seinen ersten Health-Check zu beantworten, bevor ECS beginnt, Fehler gegen die Bereitstellung zu zählen. Der Health-Check der Zielgruppe auf `GET /readyz` überprüft, ob der Store erreichbar ist, daher kommt eine Task, die Postgres nicht erreichen kann, nie in Rotation. Um Tasks durch einen kurzen Datenbankausfall wie ein RDS-Failover hindurch den Health-Check bestehen zu lassen, setzen Sie `store.readiness_grace_seconds` wie in [Ausfallverhalten](/docs/de/claude-apps-gateway-deploy#outage-behavior) beschrieben, das auch die `/healthz` Alternative abdeckt.428 Die 60-Sekunden-Gnadenfrist gibt einer kalten Task Zeit, das Image zu ziehen, sich mit dem Store zu verbinden und seinen ersten Health-Check zu beantworten, bevor ECS beginnt, Fehler gegen die Bereitstellung zu zählen.

429 

430 Der Health-Check der Zielgruppe auf `GET /readyz` überprüft, ob der Store erreichbar ist, daher kommt eine Task, die Postgres nicht erreichen kann, nie in Rotation. Um Tasks durch einen kurzen Datenbankausfall wie ein RDS-Failover hindurch den Health-Check bestehen zu lassen, setzen Sie `store.readiness_grace_seconds` wie in [Ausfallverhalten](/docs/de/claude-apps-gateway-deploy#outage-behavior) beschrieben, das auch die `/healthz` Alternative abdeckt.

429 431 

430 Die Tasks laufen in privaten Subnetzen ohne öffentliche IP, daher geht der gesamte Egress (zu Bedrock, Ihrem IdP, Secrets Manager, ECR und CloudWatch Logs) durch das NAT-Gateway. Um Bedrock-Verkehr vom öffentlichen Pfad zu halten, erstellen Sie einen `bedrock-runtime` Interface VPC-Endpunkt und zeigen Sie die `base_url` des Upstream darauf, wie in der [Bedrock Upstream-Referenz](/docs/de/claude-apps-gateway-config#amazon-bedrock) gezeigt; der IdP benötigt immer noch Internet-Egress.432 Die Tasks laufen in privaten Subnetzen ohne öffentliche IP, daher geht der gesamte Egress (zu Bedrock, Ihrem IdP, Secrets Manager, ECR und CloudWatch Logs) durch das NAT-Gateway. Um Bedrock-Verkehr vom öffentlichen Pfad zu halten, erstellen Sie einen `bedrock-runtime` Interface VPC-Endpunkt und zeigen Sie die `base_url` des Upstream darauf, wie in der [Bedrock Upstream-Referenz](/docs/de/claude-apps-gateway-config#amazon-bedrock) gezeigt; der IdP benötigt immer noch Internet-Egress.

431 433 

432 Beenden Sie, indem Sie Entwicklern einen privat auflösbaren Hostnamen geben: In einer Route 53 privaten gehosteten Zone, alias den internen DNS-Namen des Gateways zum ALB, und setzen Sie `listen.public_url` auf diesen Hostnamen. Der eigene `*.elb.amazonaws.com` Name des ALB wird zu privaten Adressen auf einem internen ALB aufgelöst, kann aber Ihr ACM-Zertifikat nicht tragen, daher verwenden Sie Ihren eigenen Namen.434 Beenden Sie, indem Sie Entwicklern einen privat auflösbaren Hostnamen geben: In einer Route 53 privaten gehosteten Zone, alias den internen DNS-Namen des Gateways zum ALB, und setzen Sie `listen.public_url` auf diesen Hostnamen. Der eigene `*.elb.amazonaws.com` Name des ALB wird zu privaten Adressen auf einem internen ALB aufgelöst, kann aber Ihr ACM-Zertifikat nicht tragen, daher verwenden Sie Ihren eigenen Namen.

433 435 

434 Aktualisieren Sie die autorisierte Redirect-URI des OAuth-Clients auf `<public_url>/oauth/callback`, bevor die erste Anmeldung. Nach dem Ändern von `public_url` erstellen Sie das Image unter einem neuen Tag neu, registrieren Sie eine neue Task-Definition-Revision und stellen Sie erneut bereit. Auf ECS lebt die Einstellung in der eingebetteten `gateway.yaml` des Images, und das Gateway erstellt seinen öffentlichen Ursprung nur aus dieser Einstellung, ignoriert `X-Forwarded-Host` und `X-Forwarded-Proto`. `X-Forwarded-For` wird nur berücksichtigt, wenn `listen.trusted_proxies` gesetzt ist.436 Aktualisieren Sie die autorisierte Redirect-URI des OAuth-Clients auf `<public_url>/oauth/callback` vor der ersten Anmeldung. Nach dem Ändern von `public_url` erstellen Sie das Image unter einem neuen Tag neu, registrieren Sie eine neue Task-Definition-Revision und stellen Sie erneut bereit. Auf ECS lebt die Einstellung in der eingebetteten `gateway.yaml` des Images, und das Gateway erstellt seinen öffentlichen Ursprung nur aus dieser Einstellung, ignoriert `X-Forwarded-Host` und `X-Forwarded-Proto`. `X-Forwarded-For` wird für Client-IPs nur berücksichtigt, wenn `listen.trusted_proxies` gesetzt ist.

435 </Tab>437 </Tab>

436 438 

437 <Tab title="EKS">439 <Tab title="EKS">

438 Dieser Pfad benötigt `kubectl` und `eksctl` lokal installiert, und einen bestehenden EKS-Cluster mit einem IAM OIDC-Provider und dem AWS Load Balancer Controller installiert. Der Cluster muss auf `$VPC_ID` sein, damit Pods den RDS-Privatendpunkt erreichen können, und die `claude-gateway-db` Sicherheitsgruppe muss die Sicherheitsgruppe des Clusters oder des Pods des Clusters anstelle von `$GW_SG` zulassen.440 Dieser Pfad benötigt `kubectl` und `eksctl` lokal installiert, und einen bestehenden EKS-Cluster mit einem IAM OIDC-Provider und dem AWS Load Balancer Controller installiert. Der Cluster muss auf `$VPC_ID` sein, damit Pods den RDS-Privatendpunkt erreichen können, und die `claude-gateway-db` Sicherheitsgruppe muss die Pod- oder Node-Sicherheitsgruppe des Clusters anstelle von `$GW_SG` zulassen.

439 441 

440 Auf EKS erhält das Gateway seine Bedrock-Anmeldedaten über IRSA statt der ECS-Rollen. Die `ecs-tasks.amazonaws.com` Vertrauensrichtlinie aus dem IAM-Schritt gilt hier nicht; IRSA benötigt eine Rolle, deren Vertrauensrichtlinie auf dem OIDC-Provider des Clusters föderiert ist, begrenzt auf `system:serviceaccount:claude-gateway:gateway`. `eksctl create iamserviceaccount` erstellt diese Rolle, hängt die Richtlinien an und kommentiert das Kubernetes-Dienstkonto mit der Rollen-ARN in einem Schritt. Verwandeln Sie die zwei Richtliniendokumente aus dem IAM-Schritt in verwaltete Richtlinien, die es anhängen kann:442 Auf EKS erhält das Gateway seine Bedrock-Anmeldedaten über IRSA statt der ECS-Rollen. Die `ecs-tasks.amazonaws.com` Vertrauensrichtlinie aus dem IAM-Schritt gilt hier nicht; IRSA benötigt eine Rolle, deren Vertrauensrichtlinie auf dem OIDC-Provider des Clusters föderiert ist, begrenzt auf `system:serviceaccount:claude-gateway:gateway`. `eksctl create iamserviceaccount` erstellt diese Rolle, hängt die Richtlinien an und kommentiert das Kubernetes-Dienstkonto mit der Rollen-ARN in einem Schritt. Verwandeln Sie die zwei Richtliniendokumente aus dem IAM-Schritt in verwaltete Richtlinien, die es anhängen kann:

441 443 

453 --approve455 --approve

454 ```456 ```

455 457 

456 Die Geheimnisse-Richtlinie wird nur benötigt, wenn die Pods Secrets Manager selbst lesen, wie es der AWS-Provider des Secrets Store CSI-Treibers mit dem Dienstkonto des Mounting-Pods tut; lassen Sie sie weg, wenn Sie die Kubernetes Secrets auf andere Weise erstellen. Der Provider benötigt beide Aktionen der Richtlinie: Er ruft `DescribeSecret` auf, wenn er rotierte Geheimnisse abstimmt, daher gewährt ein `GetSecretValue`-only Grant Mounts beim ersten Deploy, stoppt aber das Abholen von Rotationen.458 Die Geheimnisse-Richtlinie wird nur benötigt, wenn die Pods Secrets Manager selbst lesen, wie es der AWS-Provider des Secrets Store CSI-Treibers mit dem Dienstkonto des Mounting-Pods tut; lassen Sie sie weg, wenn Sie die Kubernetes Secrets auf andere Weise erstellen. Der Provider benötigt beide Aktionen der Richtlinie: Er ruft `DescribeSecret` auf, wenn er rotierte Geheimnisse abstimmt, daher funktioniert ein Grant nur mit `GetSecretValue` beim ersten Deploy, übernimmt aber keine Rotationen mehr.

457 459 

458 Stellen Sie das Gateway als Standard-Deployment plus Service und Ingress bereit, wie in [Kubernetes-Bereitstellung](/docs/de/claude-apps-gateway-deploy#kubernetes) beschrieben, mit:460 Stellen Sie das Gateway als Standard-Deployment plus Service und Ingress bereit, wie in [Kubernetes-Bereitstellung](/docs/de/claude-apps-gateway-deploy#kubernetes) beschrieben, mit:

459 461 

460 * `serviceAccountName: gateway`462 * `serviceAccountName: gateway`

461 * `gateway.yaml` gemountet aus einer ConfigMap und die Geheimnisse als Dateien bei `/secrets` gemountet463 * `gateway.yaml` gemountet aus einer ConfigMap und die Geheimnisse bei `/secrets` gemountet

462 * die Readiness-Probe auf `GET /readyz` gerichtet464 * die Readiness-Probe auf `GET /readyz` gerichtet

463 465 

464 Für das Front-End, ein Ingress, das vom AWS Load Balancer Controller verwaltet wird, stellt den internen ALB bereit. Kommentieren Sie es mit:466 Für das Front-End stellt ein Ingress, das vom AWS Load Balancer Controller verwaltet wird, den internen ALB bereit. Annotieren Sie es mit:

465 467 

466 * `alb.ingress.kubernetes.io/scheme: internal` und `alb.ingress.kubernetes.io/target-type: ip`468 * `alb.ingress.kubernetes.io/scheme: internal` und `alb.ingress.kubernetes.io/target-type: ip`

467 * `alb.ingress.kubernetes.io/ip-address-type: ipv4`, daher werden keine öffentlichen AAAA-Datensätze für die `/login` [private-Netzwerk-Prüfung](/docs/de/claude-apps-gateway#prerequisites) veröffentlicht, die sie ablehnt469 * `alb.ingress.kubernetes.io/ip-address-type: ipv4`, daher werden keine öffentlichen AAAA-Datensätze veröffentlicht, die die `/login` [private-Netzwerk-Prüfung](/docs/de/claude-apps-gateway#prerequisites) ablehnen würde

468 * `alb.ingress.kubernetes.io/inbound-cidrs: <your-corporate-cidr>`, daher lässt die Controller-verwaltete Frontend-Sicherheitsgruppe nur Ihr Unternehmensnetzwerk anstelle des `0.0.0.0/0` Standards zu470 * `alb.ingress.kubernetes.io/inbound-cidrs: <your-corporate-cidr>`, daher lässt die Controller-verwaltete Frontend-Sicherheitsgruppe nur Ihr Unternehmensnetzwerk anstelle des `0.0.0.0/0` Standards zu

469 * `alb.ingress.kubernetes.io/certificate-arn` mit dem ACM-Zertifikat471 * `alb.ingress.kubernetes.io/certificate-arn` mit dem ACM-Zertifikat

470 * `alb.ingress.kubernetes.io/ssl-policy: ELBSecurityPolicy-TLS13-1-2-2021-06`, daher fällt der Listener nicht auf die Legacy-Standard-Richtlinie zurück, die TLS 1.0 und 1.1 akzeptiert472 * `alb.ingress.kubernetes.io/ssl-policy: ELBSecurityPolicy-TLS13-1-2-2021-06`, daher fällt der Listener nicht auf die Legacy-Standard-Richtlinie zurück, die TLS 1.0 und 1.1 akzeptiert

471 * `alb.ingress.kubernetes.io/load-balancer-attributes: idle_timeout.timeout_seconds=3600`, eine Marge über dem Streaming-Keepalive des Gateways; siehe [Troubleshooting](#troubleshooting)473 * `alb.ingress.kubernetes.io/load-balancer-attributes: idle_timeout.timeout_seconds=3600`, eine Marge über dem Streaming-Keepalive des Gateways; siehe [Fehlerbehebung](#troubleshooting)

472 474 

473 Mit IRSA liest das AWS SDK ein projiziertes Service-Account-Token und tauscht es mit AWS STS aus, daher benötigt der Pod niemals den EC2-Instanz-Metadaten-Service; eine Egress-NetworkPolicy kann `169.254.169.254` für Gateway-Pods blockieren. Das Node-Hop-Limit-Problem in [Troubleshooting](#troubleshooting) unten gilt nur für Cluster, die IRSA überspringen und sich auf Node-Instanzrollen verlassen.475 Mit IRSA liest das AWS SDK ein projiziertes Service-Account-Token und tauscht es mit AWS STS aus, daher benötigt der Pod niemals den EC2-Instanz-Metadaten-Service; eine Egress-NetworkPolicy kann `169.254.169.254` für Gateway-Pods blockieren. Das Node-Hop-Limit-Problem in der [Fehlerbehebung](#troubleshooting) unten gilt nur für Cluster, die IRSA überspringen und sich auf Node-Instanzrollen verlassen.

474 </Tab>476 </Tab>

475 </Tabs>477 </Tabs>

476 </Step>478 </Step>

477 479 

478 <Step title="Pushen Sie die Gateway-URL zu Entwicklermaschinen">480 <Step title="Pushen Sie die Gateway-URL zu Entwicklermaschinen">

479 Das Gateway läuft jetzt, aber Entwickler können es von `/login` nicht erreichen, bis die Gateway-URL auf ihren Maschinen ist. Setzen Sie `forceLoginMethod` und `forceLoginGatewayUrl` in der [verwalteten Einstellungsdatei](/docs/de/claude-apps-gateway#set-the-gateway-url), die Sie über MDM auf jedes Gerät bereitstellen. Es gibt keine Gateway-Option im Login-Picker für einen Entwickler, um manuell auszuwählen.481 Das Gateway läuft jetzt, aber Entwickler können es von `/login` nicht erreichen, bis die Gateway-URL auf ihren Maschinen ist. Setzen Sie `forceLoginMethod` und `forceLoginGatewayUrl` in der [verwalteten Einstellungsdatei](/docs/de/claude-apps-gateway#set-the-gateway-url), die Sie über MDM auf jedes Gerät bereitstellen. Es gibt keine Gateway-Option im Login-Picker, die ein Entwickler manuell auswählen könnte.

480 </Step>482 </Step>

481</Steps>483</Steps>

482 484 

83* Terminal: `claude --continue`, `claude --resume <session-id>` oder `claude --resume <name>`, wenn der Name einer Sitzung entspricht, ohne `-p`. Claude Code stellt den Berechtigungsmodus wieder her, in dem sich die Sitzung befand, außer in den Fällen in der Tabelle. Übergeben Sie `--permission-mode` oder `--dangerously-skip-permissions`, um den wiederhergestellten Modus zu überschreiben.83* Terminal: `claude --continue`, `claude --resume <session-id>` oder `claude --resume <name>`, wenn der Name einer Sitzung entspricht, ohne `-p`. Claude Code stellt den Berechtigungsmodus wieder her, in dem sich die Sitzung befand, außer in den Fällen in der Tabelle. Übergeben Sie `--permission-mode` oder `--dangerously-skip-permissions`, um den wiederhergestellten Modus zu überschreiben.

84* Nicht-interaktiv: `claude -p --resume` oder `claude -p --continue`. Claude Code startet den Lauf im Berechtigungsmodus, in dem ein neuer `claude -p` Lauf gestartet würde, außer dass eine Sitzung, die im Plan Mode endete, unter den [Bedingungen unten](#resume-in-plan-mode-with-p) im Plan Mode fortgesetzt wird.84* Nicht-interaktiv: `claude -p --resume` oder `claude -p --continue`. Claude Code startet den Lauf im Berechtigungsmodus, in dem ein neuer `claude -p` Lauf gestartet würde, außer dass eine Sitzung, die im Plan Mode endete, unter den [Bedingungen unten](#resume-in-plan-mode-with-p) im Plan Mode fortgesetzt wird.

85* VS Code: das Gesprächsfenster der Erweiterung. Die Tabelle behandelt nur ein Gespräch, das im Plan Mode endete; für den Rest siehe [frühere Gespräche fortsetzen](/docs/de/vs-code#resume-past-conversations).85* VS Code: das Gesprächsfenster der Erweiterung. Die Tabelle behandelt nur ein Gespräch, das im Plan Mode endete; für den Rest siehe [frühere Gespräche fortsetzen](/docs/de/vs-code#resume-past-conversations).

86* Sitzungsauswahl beim Start: eine Sitzung, die Sie aus der [Sitzungsauswahl](#use-the-session-picker) auswählen, ob Sie sie mit `claude --resume` allein, `claude --from-pr` oder einem Namen, der mehr als einer Sitzung entspricht, geöffnet haben. Claude Code stellt den gespeicherten Berechtigungsmodus nicht wieder her. Es startet die Sitzung im Berechtigungsmodus, in dem es eine neue Sitzung von derselben Befehlszeile aus starten würde.86* Sitzungsauswahl beim Start: eine Sitzung, die Sie aus der [Sitzungsauswahl](#use-the-session-picker) auswählen, ob Sie sie mit `claude --resume` allein, `claude --from-pr` oder einem Namen, der mehr als einer Sitzung entspricht, geöffnet haben. Claude Code startet die Sitzung in dem Berechtigungsmodus, in dem es eine neue Sitzung von derselben Befehlszeile aus starten würde, außer dass eine Sitzung, die im Plan-Modus endete, im Plan-Modus fortgesetzt wird, sofern Sie nicht `--permission-mode`, `--dangerously-skip-permissions` oder `--fork-session` übergeben. Kein anderer gespeicherter Berechtigungsmodus wird wiederhergestellt.

87* `/resume` innerhalb einer Sitzung, mit oder ohne Argument: Claude Code stellt den gespeicherten Berechtigungsmodus nicht wieder her. Das Gespräch, zu dem Sie wechseln, wird im Berechtigungsmodus Ihrer aktuellen Sitzung fortgesetzt.87* `/resume` innerhalb einer Sitzung, mit oder ohne Argument: Das Gespräch, zu dem Sie wechseln, wird im Berechtigungsmodus Ihrer aktuellen Sitzung fortgesetzt, außer dass ein Gespräch, das im Plan-Modus endete, im Plan-Modus fortgesetzt wird, selbst wenn Sie Claude Code mit `--permission-mode` oder `--dangerously-skip-permissions` gestartet haben. Wenn dieses Gespräch bereits früher in diesem Lauf von Claude Code geöffnet war, etwa das Gespräch, mit dem Sie begonnen haben, oder eines, das Sie mit `/clear` oder `/resume` verlassen haben, wird es stattdessen in Ihrem aktuellen Berechtigungsmodus fortgesetzt.

88 88 

89Das Wiederherstellen des Plan Mode auf den nicht-interaktiven und VS Code Pfaden erfordert Claude Code v2.1.246 oder später. Jede Zeile benennt den Berechtigungsmodus, in dem die Sitzung endete, welche der Terminal-, nicht-interaktiven und VS Code Pfade Sie ihn fortsetzen, und den Berechtigungsmodus, in dem Claude Code die fortgesetzte Sitzung startet.89Das Wiederherstellen des Plan Mode auf den nicht-interaktiven und VS Code Pfaden erfordert Claude Code v2.1.246 oder später. Jede Zeile benennt den Berechtigungsmodus, in dem die Sitzung endete, welche der Terminal-, nicht-interaktiven und VS Code Pfade Sie ihn fortsetzen, und den Berechtigungsmodus, in dem Claude Code die fortgesetzte Sitzung startet.

90 90 

91| Sitzung endete in | Wie Sie fortsetzen | Berechtigungsmodus nach dem Fortsetzen |91| Sitzung endete in | Wie Sie fortsetzen | Berechtigungsmodus nach dem Fortsetzen |

92| :- | :- | :- |92| :- | :- | :- |

93| `bypassPermissions` | Terminal | Der Berechtigungsmodus, in dem eine neue Sitzung gestartet würde. Um [Berechtigungen zu umgehen](/docs/de/permission-modes#skip-all-checks-with-bypasspermissions-mode), aktivieren Sie es beim Start mit einem seiner Start-Flags oder `permissions.defaultMode: "bypassPermissions"` in [Benutzer-, `--settings`- oder verwalteten Einstellungen](/docs/de/settings-reference#permissions-defaultmode) |93| `bypassPermissions` | Terminal | Der Berechtigungsmodus, in dem eine neue Sitzung gestartet würde. Um [Berechtigungen zu umgehen](/docs/de/permission-modes#skip-all-checks-with-bypasspermissions-mode), aktivieren Sie es beim Start mit einem seiner Start-Flags oder `permissions.defaultMode: "bypassPermissions"` in [Benutzer-, `--settings`- oder verwalteten Einstellungen](/docs/de/settings-reference#permissions-defaultmode) |

94| `plan` | Terminal | Der Berechtigungsmodus, in dem eine neue Sitzung gestartet würde |94| `plan` | Terminal | Plan-Modus. Mit `--fork-session` der Berechtigungsmodus, in dem eine neue Sitzung gestartet würde |

95| `auto` | Terminal | `auto`, nur wenn Ihr Konto immer noch die [Auto Mode Anforderungen](/docs/de/permission-modes#eliminate-prompts-with-auto-mode) erfüllt |95| `auto` | Terminal | `auto`, nur wenn Ihr Konto immer noch die [Auto Mode Anforderungen](/docs/de/permission-modes#eliminate-prompts-with-auto-mode) erfüllt |

96| Manual | Terminal | Manual, wenn eine neue Sitzung im Auto Mode von der [integrierten Standardeinstellung](/docs/de/permission-modes#which-mode-a-session-starts-in) gestartet würde. Wenn ein `defaultMode` aus einer Einstellungsdatei [wirksam wird](/docs/de/permission-modes#which-mode-a-session-starts-in), startet Claude Code die fortgesetzte Sitzung stattdessen in diesem Modus |96| Manual | Terminal | Manual, wenn eine neue Sitzung im Auto Mode von der [integrierten Standardeinstellung](/docs/de/permission-modes#which-mode-a-session-starts-in) gestartet würde. Wenn ein `defaultMode` aus einer Einstellungsdatei [wirksam wird](/docs/de/permission-modes#which-mode-a-session-starts-in), startet Claude Code die fortgesetzte Sitzung stattdessen in diesem Modus |

97| `plan` | Nicht-interaktiv, unter den [Bedingungen unten](#resume-in-plan-mode-with-p) | Plan Mode |97| `plan` | Nicht-interaktiv, unter den [Bedingungen unten](#resume-in-plan-mode-with-p) | Plan Mode |