SpyBara
Go Premium

claude-apps-gateway.md 2026-10-07 23:59 UTC to 2026-10-08 20:59 UTC

This page contains 100 additions and 99 deletions.

2026
Sun 4 23:58 Wed 7 23:59 Thu 8 20:59

Gateway di app Claude per Amazon Bedrock, Claude Platform su AWS, Google Cloud e Microsoft Foundry

Esegui Claude Code attraverso Amazon Bedrock, Claude Platform su AWS, Google Cloud o Microsoft Foundry dietro un gateway auto-ospitato con accesso SSO, accesso ai modelli per gruppo e telemetria OTLP.

Claude apps gateway è un servizio auto-ospitato che si posiziona tra i client Claude Code dei tuoi sviluppatori e il tuo provider di modelli. Gli sviluppatori accedono con il tuo provider di identità aziendale (IdP) invece di detenere chiavi API o credenziali cloud. Il gateway contiene la credenziale upstream, applica l'accesso ai modelli e le impostazioni gestite per gruppo IdP, e trasmette la telemetria di utilizzo al tuo stack di osservabilità.

È incluso nel binario claude, quindi lo stesso eseguibile che esegue Claude Code su un laptop esegue il server gateway con claude gateway --config gateway.yaml.

Questa pagina copre:

Le pagine complementari approfondiscono. Il riferimento di configurazione copre ogni opzione nel file YAML che la guida rapida scrive, e la guida di distribuzione copre la configurazione per IdP, la distribuzione su Kubernetes e Cloud Run, e le operazioni.

Perché Claude apps gateway

La panoramica del gateway copre cosa fa un gateway e perché ne eseguiresti uno. Claude apps gateway è il gateway di Anthropic, integrato nel binario claude e testato insieme a ogni rilascio di Claude Code, quindi inoltra le intestazioni e i campi di richiesta che Claude Code invia senza che gli operatori mantengano un elenco di autorizzazioni separato. Una volta distribuito, ti offre:

  • Credenziali: la chiave API upstream o la credenziale cloud vive solo nella tua infrastruttura. Gli sviluppatori si autenticano con SSO aziendale e ricevono token bearer di breve durata, quindi l'offboarding avviene nel tuo IdP. Deprovision un utente e il suo accesso al gateway scade entro la durata della sessione, un'ora per impostazione predefinita.
  • Controllo di accesso: i tuoi gruppi IdP si mappano agli elenchi di modelli consentiti e alle politiche di impostazioni gestite. Il gateway applica l'accesso ai modelli lato server, rifiutando le richieste per modelli non concessi, e seleziona la politica di impostazioni gestite di ogni gruppo, che il CLI applica al livello di impostazioni gestite. Diversi team ottengono diversi modelli, strumenti e autorizzazioni, e uno sviluppatore non può ignorare ciò che la sua politica blocca.
  • Consegna delle impostazioni: il gateway consegna le impostazioni gestite ai client connessi stesso, prendendo il posto delle impostazioni gestite dal server dalla console amministratore di claude.ai.
  • Telemetria: ogni destinazione configurata riceve metriche OpenTelemetry Protocol (OTLP) con conteggi di token, modello, identità dell'utente e latenza per impostazione predefinita, con log e tracce come opt-in per destinazione.
  • Instradamento upstream: i client parlano l'API Anthropic Messages al gateway, e il gateway traduce per ogni upstream, sia Bedrock, Claude Platform su AWS, Agent Platform di Google Cloud, Foundry o l'API Anthropic, con failover tra loro. Puoi cambiare regioni, provider o ordine di failover senza che gli sviluppatori se ne accorgano o riconfigurino.
Diagramma che mostra i client Claude Code e le schede Chat, Cowork e Code di Claude Desktop che si connettono tramite HTTPS con token bearer a un gateway di app Claude auto-ospitato all'interno della tua infrastruttura, che accede gli utenti rispetto al tuo IdP, archivia lo stato di autenticazione in PostgreSQL, trasmette la telemetria al tuo raccoglitore OTLP e inoltra l'inferenza ad Amazon Bedrock, Claude Platform su AWS, Google Cloud, Microsoft Foundry o all'API Anthropic

Per quali funzionalità di Claude Code funzionano attraverso il gateway e cosa supporta il server stesso, vedi Disponibilità e limitazioni di seguito. Per decisioni come costo, bypass, esecuzione di più gateway e piattaforme serverless, vedi la guida di distribuzione.

Altre implementazioni di gateway

Se esegui già un gateway LLM o un gateway API che soddisfa le tue esigenze, continua a usarlo; Altri gateway LLM copre la configurazione di Claude Code rispetto ad esso.

La guida di compatibilità del gateway documenta cosa Claude Code si aspetta da qualsiasi gateway: gli endpoint che chiama, le intestazioni e i campi del corpo da inoltrare, e cosa smette di funzionare quando vengono rimossi. Un gateway di app Claude in esecuzione serve anche il suo proprio riferimento di protocollo su GET /protocol, che descrive gli endpoint che espone ai client Claude Code: accesso SSO, inferenza, consegna di impostazioni gestite, scoperta di modelli e telemetria. Recuperalo con curl https://claude-gateway.internal.example.com/protocol da qualsiasi gateway distribuito, come quello che la guida rapida di seguito produce.

I cambiamenti di rottura del protocollo vengono annunciati in anticipo, ma la compatibilità all'indietro indefinita non è garantita.

Guida rapida

Questa guida rapida percorre il percorso minimo: registra un client OAuth nel tuo IdP, scrivi un gateway.yaml, esegui il gateway insieme a Postgres con Docker Compose, e verifica l'accesso end-to-end. Utilizza un upstream Amazon Bedrock; Claude Platform su AWS, Agent Platform di Google Cloud, Microsoft Foundry e l'API Anthropic sono ugualmente supportati scambiando il blocco upstreams come mostrato nel riferimento di configurazione. Alla fine hai un gateway a cui uno sviluppatore può /login.

Prerequisiti

Avere questi in atto prima di iniziare:

Hai bisogno Dettagli
Claude Code v2.1.195 o successivo Il sottocomando claude gateway e il flusso di accesso al gateway vengono spediti in v2.1.195. Le build pubbliche precedenti non le includono. Sia la macchina che esegue il server gateway che la macchina di ogni sviluppatore devono essere su v2.1.195 o successivo; esegui claude update per ottenere l'ultimo rilascio. L'upstream Claude Platform su AWS richiede Claude Code v2.1.198 o successivo sul server gateway.
Provider di identità OpenID Connect (OIDC) Okta, Microsoft Entra ID, Google Workspace, Keycloak, o Dex, o qualsiasi altro IdP conforme a OIDC come PingFederate. Il gateway esegue il discovery OIDC standard e il flusso del codice di autorizzazione rispetto ad esso. SAML e LDAP non sono supportati.
PostgreSQL 11 o successivo Supporta il flusso di accesso del dispositivo e i contatori dei rate limit. Funziona un servizio PostgreSQL gestito, incluso il livello più piccolo; vedi quali database sono supportati. Con limiti di spesa, contiene anche tabelle di spesa durevole, audit e identità che dovrebbero essere sottoposte a backup. TLS tramite ?sslmode=require è consigliato. PostgreSQL 11, 12 e 13 richiedono Claude Code v2.1.290 o successivo sul server gateway. Il progetto PostgreSQL non mantiene più quelle versioni, quindi usane una più recente dove puoi.
Upstream del modello Credenziali Amazon Bedrock, credenziali Claude Platform su AWS, credenziali Google Cloud, una risorsa Microsoft Foundry o una chiave API Anthropic. Sono supportati più upstream con failover.
HTTPS Il gateway deve essere raggiungibile su https:// dai laptop degli sviluppatori e da qualsiasi browser utilizzato per l'accesso; il gateway serve la pagina di verifica del dispositivo sullo stesso listener. Fornisci un certificato TLS tramite listen.tls o esegui dietro un ingresso che termina TLS, e imposta listen.public_url all'origine esterna in entrambi i casi. Su /login, Claude Code accetta un'origine http:// semplice solo quando l'host del gateway è loopback: localhost, 127.0.0.1, o ::1.
Indirizzo di rete privata Su /login, Claude Code richiede che il nome host o l'indirizzo IP del gateway si risolvano solo in indirizzi privati: RFC 1918, link-local, CGNAT 100.64.0.0/10, IPv6 ULA fc00::/7, o loopback. Per un gateway che ospiti, qualsiasi indirizzo pubblico al di fuori di un blocco che dichiari è rifiutato; vedi il modello di minaccia nella guida di distribuzione. Se le macchine degli sviluppatori instradano HTTPS attraverso un proxy aziendale, l'accesso richiede anche che l'host proxy si risolva in indirizzi privati; se non lo fa, aggiungi l'host del gateway a NO_PROXY in modo che il CLI si connetta direttamente. Se la tua rete interna è numerata da spazio IPv4 pubblico che la tua organizzazione possiede, dichiara quei blocchi in modo che /login accetti un gateway lì.
Runtime Linux Il server gateway viene eseguito solo sul binario Linux nativo. macOS funziona per lo sviluppo locale. Windows non è supportato come piattaforma server.

Passaggi

1

Registra un client OAuth nel tuo IdP

Decidi prima il nome host del gateway, perché l'URI di reindirizzamento deve corrispondere. Crea una nuova applicazione web OIDC e imposta l'URI di reindirizzamento su https://claude-gateway.<your-domain>/oauth/callback, dove l'host è lo stesso valore che imposti come listen.public_url nel passaggio 3. Annota client_id e client_secret. Le istruzioni per IdP sono in Configurazione del provider di identità.

2

Provisioning di un database PostgreSQL

Usa PostgreSQL 11 o successivo. Il livello gestito più piccolo è sufficiente. Il gateway esegue le proprie migrazioni dello schema all'avvio, quindi il ruolo del database ha bisogno dei diritti per creare e alterare le tabelle; vedi store.

3

Scrivi gateway.yaml

I segreti vengono letti tramite l'espansione ${ENV_VAR} in modo che il file stesso possa vivere nel controllo della versione. Usa un nome host public_url che si risolve in un IP privato sulla tua rete, perché /login rifiuta gli indirizzi pubblici. La configurazione minima ha cinque sezioni, e ogni altro campo ha un valore predefinito:

listen:
host: 0.0.0.0
port: 8080
# Obbligatorio a meno che l'host non sia un indirizzo loopback. Utilizzato per l'IdP
# redirect_uri e il documento di discovery.
public_url: https://claude-gateway.internal.example.com

oidc:
issuer: https://login.example.com        # deve servire /.well-known/openid-configuration
client_id: 0oa1example2
client_secret: ${OIDC_CLIENT_SECRET}
allowed_email_domains: [example.com]        # rifiuta id_tokens al di fuori della tua organizzazione
userinfo_fallback: true                  # per IdP il cui id_token omette email/groups; innocuo altrimenti

session:
jwt_secret: ${GATEWAY_JWT_SECRET}        # openssl rand -base64 32
ttl_hours: 1                             # limita anche la latenza di revoca su deprovision IdP

store:
postgres_url: ${GATEWAY_POSTGRES_URL}    # aggiungi ?sslmode=require per Postgres gestito

upstreams:
- provider: bedrock
region: us-east-1
auth: {} # vuoto: catena di credenziali predefinita AWS
# (IRSA, ruolo attività EC2/ECS, variabili env, ~/.aws)

# I modelli vengono tradotti per upstream automaticamente. Il catalogo integrato
# mappa claude-opus-4-8 a us.anthropic.claude-opus-4-8 e così via per ogni
# modello Claude supportato da Bedrock. Imposta false e aggiungi un elenco `models:` per
# esporre solo modelli specifici.
auto_include_builtin_models: true

Questa configurazione è sufficiente per un ciclo di accesso funzionante con il catalogo di modelli Bedrock predefinito. Una volta in esecuzione, aggiungi RBAC per gruppo tramite managed.policies, fan-out di telemetria tramite telemetry, e failover multi-upstream, ARN di throughput provisioning o regioni non statunitensi tramite models.

4

Eseguilo

Costruisci un'immagine container attorno al binario claude che soddisfi i requisiti dell'immagine, quindi eseguila insieme a Postgres. Il file Compose fa riferimento all'immagine come registry.example.com/claude-gateway:2.1.198; sostituisci il tuo registro e tag immagine:

services:
gateway:
image: registry.example.com/claude-gateway:2.1.198
ports: ["8080:8080"]
volumes: ["./gateway.yaml:/etc/claude/gateway.yaml:ro"]
environment:
OIDC_CLIENT_SECRET: ${OIDC_CLIENT_SECRET}
GATEWAY_JWT_SECRET: ${GATEWAY_JWT_SECRET}
GATEWAY_POSTGRES_URL: postgres://gw:pw@postgres/gateway
# Credenziali AWS: in produzione, ometti questi e usa un ruolo
# di istanza. Per il test locale di Compose, passa i tuoi:
AWS_ACCESS_KEY_ID: ${AWS_ACCESS_KEY_ID}
AWS_SECRET_ACCESS_KEY: ${AWS_SECRET_ACCESS_KEY}
AWS_SESSION_TOKEN: ${AWS_SESSION_TOKEN}
depends_on:
postgres:
condition: service_healthy
postgres:
image: postgres:16-alpine
environment: { POSTGRES_USER: gw, POSTGRES_PASSWORD: pw, POSTGRES_DB: gateway }
healthcheck:
test: ["CMD-SHELL", "pg_isready -U gw"]
interval: 5s
volumes: ["pgdata:/var/lib/postgresql/data"]
volumes: { pgdata: }

Il gateway è un singolo binario Linux che legge la configurazione, si connette a Postgres e applica le migrazioni dello schema, esegue il discovery OIDC rispetto al tuo IdP, costruisce client upstream e inizia ad ascoltare.

L'avvio è fail-closed per la configurazione, la connessione Postgres, il discovery OIDC e la costruzione del client upstream. Se uno di questi è irraggiungibile o non configurato correttamente, il gateway esce con un errore piuttosto che servire il traffico in uno stato degradato.

Un avvio riuscito non convalida il percorso di inferenza, perché le credenziali dell'istanza Bedrock e Agent Platform si risolvono sulla prima richiesta, non all'avvio.

Guarda stderr per la sequenza di avvio. Le righe di log utilizzano il formato [gateway] <timestamp> <level> <message>, gli eventi di audit sono JSON a riga singola con un campo evt, e un banner di avvio, omesso di seguito, viene stampato tra la migrazione e le righe di ascolto. Un database nuovo stampa una riga migration N applied per ogni migrazione dello schema; un database già migrato non stampa nulla. Dovresti vedere, in ordine:

{"ts":"2026-06-10T17:03:21.114Z","evt":"config.load","path":"/etc/claude/gateway.yaml","sha256":"…"}
[gateway] 2026-06-10T17:03:21.395Z info waiting for migration lock (another replica may be migrating; check pg_locks for key 6775156 if this persists)
[gateway] 2026-06-10T17:03:21.408Z info migration 1 applied
…
[gateway] 2026-06-10T17:03:21.431Z info migration 6 applied
[gateway] 2026-06-10T17:03:21.512Z info claude gateway listening on http://0.0.0.0:8080

Il gateway registra anche un avviso che access_control.allow_cidrs è vuoto. Questo è previsto qui, perché nulla limita quali indirizzi client il gateway serve fino a quando non imposti un elenco di autorizzazione. Il riferimento access_control ha gli intervalli consigliati.

Se l'avvio esce prima della riga claude gateway listening on, l'ultima riga di stderr nomina il problema:

  • un Postgres irraggiungibile
  • un ruolo Postgres senza autorizzazione DDL
  • un documento di discovery OIDC irraggiungibile o non valido
  • una violazione dello schema di configurazione con il percorso del campo offensivo

Correggilo e riavvia.

Se hai già un ingresso che termina TLS, salta Compose ed esegui il binario direttamente con claude gateway --config gateway.yaml. Imposta public_url all'origine dell'ingresso e associa listen a un indirizzo loopback o interno al cluster.

5

Verifica la superficie di autenticazione

Tre controlli confermano che il gateway può autenticare un utente reale prima di consegnarlo a uno sviluppatore.

Gli esempi utilizzano l'URL pubblico del gateway; per la configurazione locale di Compose senza un ingresso, sostituisci http://localhost:8080 nei primi due controlli. Il terzo controllo apre verification_uri_complete, che è costruito da public_url, quindi per Compose locale imposta public_url: http://localhost:8080 in gateway.yaml e aggiungi http://localhost:8080/oauth/callback come secondo URI di reindirizzamento sul client OAuth dal passaggio 1, perché il gateway costruisce l'IdP redirect_uri da public_url. Il link di verifica si apre quindi nel tuo browser locale.

In Windows PowerShell, esegui curl.exe; il curl semplice è un alias per Invoke-WebRequest e rifiuta questi flag.

Per primo, recupera il documento di discovery, che conferma che il gateway è attivo, la configurazione è valida e tutti i controlli di avvio sono passati:

curl -s https://claude-gateway.internal.example.com/.well-known/oauth-authorization-server | jq

{
"issuer": "https://claude-gateway.internal.example.com",
"device_authorization_endpoint": "…/oauth/device_authorization",
"token_endpoint": "…/oauth/token",
"grant_types_supported": ["urn:ietf:params:oauth:grant-type:device_code", "refresh_token"]
}

La risposta include campi aggiuntivi, come response_types_supported e scopes_supported.

Secondo, richiedi un'autorizzazione del dispositivo, che conferma che il flusso di accesso del dispositivo funziona e Postgres è raggiungibile e scrivibile:

curl -s -X POST https://claude-gateway.internal.example.com/oauth/device_authorization | jq

{
"device_code": "…",
"user_code": "WDJB-MJHT",
"verification_uri": "https://claude-gateway.internal.example.com/device",
"verification_uri_complete": "https://claude-gateway.internal.example.com/device?user_code=WDJB-MJHT",
"expires_in": 600,
"interval": 5
}

Terzo, testa la parte del browser aprendo verification_uri_complete in un browser e confermando il codice. Dovresti essere reindirizzato alla pagina di accesso del tuo IdP e, dopo l'accesso, tornare al gateway con una conferma di accesso.

Usa il primo controllo che fallisce per individuare il problema:

  • Il primo controllo fallisce: l'avvio non è stato completato; controlla stderr
  • Il secondo controllo fallisce: Postgres non è raggiungibile dal gateway o il ruolo non può scrivere; controlla la stringa di connessione e le autorizzazioni
  • Il terzo controllo non raggiunge l'IdP: controlla che l'URI di reindirizzamento dell'IdP corrisponda esattamente a https://<gateway>/oauth/callback
  • Il terzo controllo raggiunge l'IdP ma rimbalza indietro con un errore: leggi il log di audit del gateway, che registra ogni rifiuto di autenticazione con il motivo, come email domain not allowed
6

Accedi a uno sviluppatore

Questo ultimo passaggio avviene su una macchina sviluppatore, non sul server. Imposta forceLoginMethod su "gateway" e forceLoginGatewayUrl su public_url del tuo gateway nel file delle impostazioni gestite di quella macchina, quindi esegui /login, premi Invio sulla schermata Cloud gateway e completa l'accesso del browser. Imposta l'URL del gateway di seguito copre la distribuzione di entrambe le chiavi su ogni macchina sviluppatore.

Connettere gli sviluppatori

Gli sviluppatori si connettono dai propri laptop con un unico accesso tramite browser, usando il proprio account aziendale. Non hanno bisogno di un account claude.ai, di una chiave API o di un abbonamento, perché le richieste al modello passano attraverso il gateway usando la credenziale upstream dell'organizzazione. La connessione è guidata dalle impostazioni gestite lato client che distribuisci tramite MDM, quindi non c'è alcuna configurazione manuale da parte dello sviluppatore; questa sezione descrive ciò che configura l'amministratore.

La CLI calcola l'impronta del certificato TLS foglia del gateway alla prima connessione e la fissa (pinning) per hostname. Verifica di nuovo questa impronta fissata durante l'accesso, nei rinnovi silenziosi della sessione e nel recupero delle impostazioni gestite, mentre le richieste di inferenza usano la validazione TLS standard senza il pinning. Le richieste instradate attraverso un proxy HTTPS saltano la verifica del pinning, quindi aggiungi l'host del gateway a NO_PROXY per mantenerle dirette.

Pubblica l'impronta SHA-256 attesa insieme all'URL del gateway, così gli sviluppatori hanno qualcosa con cui confrontarla. Il prompt di /login mostra i primi 16 caratteri dell'impronta in esadecimale minuscolo senza due punti. Per stampare l'impronta completa in quel formato a partire dal file del certificato, esegui:

openssl x509 -noout -fingerprint -sha256 -in cert.pem | cut -d= -f2 | tr -d : | tr 'A-F' 'a-f'

Quando il certificato viene ruotato, ogni sviluppatore vede di nuovo la richiesta di attendibilità, quindi tratta le rotazioni come un evento pianificato e ripubblica l'impronta. Se la policy del tuo gateway include impostazioni che richiedono approvazione, lo sviluppatore vede di nuovo anche quella finestra di approvazione dopo aver accettato il nuovo certificato, perché Claude Code associa la memoria delle approvazioni al certificato fissato.

Un gateway può restituire il campo facoltativo email nella sua risposta token per indicare l'account usato per un accesso. Quando lo fa, lo sviluppatore conferma l'account prima che Claude Code salvi la credenziale. Dopo un accesso confermato, /status mostra l'account.

La conferma richiede Claude Code v2.1.275 o successivo sulla macchina dello sviluppatore; un client di versione inferiore ignora il campo. Il server gateway incluso nel binario claude non restituisce il campo, quindi i suoi accessi si completano senza la conferma.

Una volta che lo sviluppatore ha effettuato l'accesso, il selettore dei modelli mostra i modelli presenti nella sua allowlist availableModels. Le impostazioni gestite si applicano all'avvio e si aggiornano ogni ora, e la telemetria viene instradata al tuo collector.

Le sessioni si rinnovano silenziosamente prima della scadenza di ttl_hours. Quando un rinnovo fallisce dopo il deprovisioning nell'IdP, Claude Code chiede allo sviluppatore di accedere di nuovo.

Impostare l'URL del gateway

Tre chiavi vanno nel file delle impostazioni gestite specifico per ogni sistema operativo che distribuisci tramite MDM o direttamente su disco. forceLoginMethod e forceLoginGatewayUrl aprono /login direttamente sulla schermata Cloud gateway con l'URL già compilato, e parentSettingsBehavior: "merge" permette a Claude Desktop di fornire l'allowlist di uscita del gateway alle sessioni di Claude Code che avvia, come spiegato in Fornire la policy alle sessioni di Claude Desktop:

{
  "forceLoginMethod": "gateway",
  "forceLoginGatewayUrl": "https://claude-gateway.internal.example.com",
  "parentSettingsBehavior": "merge"
}

Lo sviluppatore preme Invio per connettersi. Il prompt dell'impronta TLS alla prima connessione appare comunque. Una volta che il file è presente su una macchina, uno sviluppatore che non ha completato l'accesso al gateway vede uno dei messaggi descritti in Administrator policy requires a Cloud gateway sign-in. Gli sviluppatori che selezionano un provider cloud tramite una variabile d'ambiente come CLAUDE_CODE_USE_BEDROCK non hanno bisogno dell'accesso al gateway.

Uno sviluppatore non può configurarlo manualmente. Il selettore di accesso non ha un'opzione gateway, e forceLoginGatewayUrl viene ignorato nei file di impostazioni dello sviluppatore. forceLoginMethod da solo, senza un URL, lascia lo sviluppatore su un messaggio "Contact your IT administrator". Le chiavi di accesso vanno nel file che distribuisci alle macchine, non nel blocco managed.policies[].cli del gateway, che raggiunge solo i client già connessi.

Consentire un gateway su uno spazio di indirizzi pubblico di tua proprietà

Alcune organizzazioni numerano la propria rete interna a partire da un blocco IPv4 pubblico di loro proprietà, come lo spazio di indirizzi di un operatore o un /8 legacy, quindi il loro gateway non ha un indirizzo privato. Elenca questi blocchi nell'impostazione gestita gatewayInternalNetworks. /login accetterà quindi un gateway all'interno di un blocco elencato quando la macchina dello sviluppatore vi si connette da un indirizzo interno allo stesso blocco. Ciò richiede Claude Code v2.1.268 o successivo sulla macchina dello sviluppatore; le versioni precedenti ignorano la chiave e applicano la regola degli indirizzi privati.

Aggiungi la chiave alla stessa sorgente di impostazioni gestite delle chiavi di accesso: il file delle impostazioni gestite, il profilo MDM o la policy del registro di sistema. Claude Code la ignora nelle impostazioni utente, di progetto e gestite dal server.

Questo esempio dichiara un solo blocco. Sostituisci 203.0.113.0/24 con il tuo blocco. È un intervallo di documentazione, e Claude Code li rifiuta.

{
  "gatewayInternalNetworks": ["203.0.113.0/24"]
}

Claude Code convalida l'elenco in /login prima di contattare qualsiasi gateway:

  • Ogni voce è un blocco IPv4 scritto come primo indirizzo e un prefisso da /8 a /32.
  • L'elenco contiene al massimo quattro blocchi, e nessuno si sovrappone a un altro.
  • Nessun blocco si sovrappone allo spazio di indirizzi privato: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8, 169.254.0.0/16 e 100.64.0.0/10. /login accetta già un gateway lì senza questa chiave.
  • Nessun blocco si sovrappone a uno spazio che non è mai la rete di un'organizzazione: 198.18.0.0/15 e 192.0.0.0/24, che i client VPN e NAT64 usano come indirizzi locali; gli intervalli di documentazione 192.0.2.0/24, 198.51.100.0/24 e 203.0.113.0/24; e gli intervalli riservati 0.0.0.0/8, 192.88.99.0/24 e multicast 224.0.0.0/4. Puoi dichiarare blocchi all'interno di 240.0.0.0/4, che alcune grandi reti usano come spazio unicast interno.

I blocchi di managed-settings.json e dei suoi file drop-in managed-settings.d/ si combinano in un unico elenco, e questi limiti si applicano all'elenco combinato. Per restringere un blocco, sostituisci la sua voce invece di aggiungerne una seconda sovrapposta in un drop-in; /login rifiuta la sovrapposizione.

Se una voce viola una regola, o il valore non è un elenco di stringhe, Claude Code rifiuta ogni nuovo accesso al gateway su quella macchina e indica il problema nel messaggio. Anche l'accesso a un gateway su un indirizzo privato fallisce, mentre gli accessi esistenti continuano a funzionare. Prova il valore su una macchina prima di distribuirlo. Claude Code elenca anche un valore di tipo errato tra le impostazioni gestite non valide che segnala.

Con un elenco valido, /login applica tre verifiche a un gateway il cui indirizzo si trova all'interno di un blocco elencato:

  • Ogni indirizzo in cui si risolve l'hostname del gateway si trova all'interno di quel singolo blocco. Claude Code rifiuta un nome che ha anche record al di fuori di esso, inclusi indirizzi privati e IPv6.
  • La macchina dello sviluppatore si connette dall'interno dello stesso blocco. Claude Code rifiuta una macchina dietro NAT, all'interno di un container o di WSL2, o su una VPN il cui pool di indirizzi si trova al di fuori del blocco, e indica l'indirizzo da cui la macchina si è connessa.
  • La connessione è diretta. Se HTTPS_PROXY si applica all'host del gateway, /login rifiuta e indica la voce NO_PROXY da aggiungere.

Quando tutte e tre le verifiche hanno esito positivo, la richiesta di attendibilità aggiunge una riga che indica l'indirizzo della macchina, l'indirizzo del gateway e il blocco dichiarato che li contiene entrambi.

La chiave non cambia nulla per gli altri gateway: l'accesso a un gateway su un indirizzo privato funziona come prima, e l'accesso a uno su un indirizzo pubblico al di fuori di ogni blocco elencato viene rifiutato come prima.

Un blocco dichiarato restringe chi può accedere ma non dimostra dove si trova una macchina, quindi dichiara solo spazio di indirizzi controllato dalla tua organizzazione. Un blocco condiviso con altri tenant, come l'intervallo pubblico di un provider cloud, permette a chiunque al suo interno di superare la stessa verifica.

Fornire la policy alle sessioni di Claude Desktop

Claude Desktop esegue le sue schede Cowork e Code, più la scheda Chat quando la abiliti, su sessioni di Claude Code incorporate e invia le loro richieste al modello attraverso il gateway. Passa una policy a ciascuna di queste sessioni, costruita a partire dalla configurazione che il gateway gli fornisce su /user/bootstrap: l'allowlist dei modelli, gli strumenti disabilitati e l'allowlist di uscita derivati dal blocco cli della policy corrispondente, più l'overlay desktop.

Le altre chiavi cli, come gli hook, env e le regole di permesso con ambito come Bash(npm *), raggiungono solo i client che accedono tramite /login. Claude Desktop legge l'URL del gateway dalla propria configurazione gestita ed effettua l'accesso con il proprio flusso, separato dalle chiavi forceLoginMethod e forceLoginGatewayUrl di Impostare l'URL del gateway.

Le impostazioni passate da un processo di avvio sono impostazioni parent. Claude Code ignora le impostazioni parent su qualsiasi macchina che abbia una sorgente gestita distribuita da un amministratore, a meno che la sorgente che fornisce la policy non imposti parentSettingsBehavior: "merge".

Quali macchine richiedono l'opt-in

Le macchine che eseguono solo Claude Desktop lo richiedono. Claude Desktop applica autonomamente l'elenco dei modelli e l'elenco degli strumenti disabilitati alle sessioni incorporate, ma l'allowlist di uscita le raggiunge solo come impostazioni parent, sotto forma di regole di dominio WebFetch e regole di rete della sandbox. Senza l'opt-in, queste sessioni vengono eseguite senza la restrizione di uscita, e nulla ti avvisa. Il gateway rifiuta comunque le richieste di inferenza per i modelli che la policy non concede.

Anche un'allowlist dei marketplace di plugin raggiunge le sessioni incorporate solo come impostazioni parent. Quando disattivi i marketplace di plugin aggiunti dall'utente nella configurazione gestita di Claude Desktop, Claude Desktop 2.16120.0 o successivo nasconde i marketplace che la tua organizzazione non ha predisposto e rifiuta le installazioni da essi. Per impedire alle sessioni incorporate di caricare plugin già installati da quei marketplace, invia loro un elenco strictKnownMarketplaces come impostazioni parent. Senza l'opt-in, Claude Code ignora quell'elenco, e quei plugin continuano a essere caricati.

Le macchine in cui gli sviluppatori accedono tramite /login non lo richiedono; ogni sessione di Claude Code recupera la propria policy dal gateway.

I parchi macchine il cui policyHelper fornisce le impostazioni gestite non possono usarlo: Claude Code non esegue mai il merge delle impostazioni parent su quei parchi macchine, perché legge le impostazioni gestite esclusivamente dall'output dell'helper.

Impostare l'opt-in

Distribuisci lo snippet delle impostazioni gestite di Impostare l'URL del gateway, replicalo in qualsiasi sorgente lato client che abbia priorità superiore al file, quindi verifica.

1

Distribuisci l'opt-in nel file delle impostazioni gestite

Lo snippet precedente include già parentSettingsBehavior: "merge", quindi il file che distribuisci alle macchine lo contiene.

2

Replica lo snippet in qualsiasi sorgente con priorità superiore al file

Claude Code legge parentSettingsBehavior solo dalla sorgente selezionata. Aggiungere qualsiasi chiave di policy a una sorgente può renderla quella selezionata, quindi in una sorgente lato client replica l'intero snippet invece della sola parentSettingsBehavior. Impostazioni gestite lato client tratta i parchi macchine che forniscono la policy tramite Criteri di gruppo o profili di configurazione. Un plist di preferenze gestite su macOS o una policy HKLM su Windows ha priorità superiore al file managed-settings.json, e le impostazioni gestite remote del gateway hanno priorità superiore a entrambi, quindi sulle macchine che accedono al gateway imposta parentSettingsBehavior anche nel blocco cli della policy del gateway.

3

Verifica quale sorgente è selezionata

Su una macchina che esegue solo Claude Desktop, chiama resolveSettings() dell'Agent SDK e leggi policyOrigin nella voce managed del suo elenco sources. Il valore indica la sorgente lato client selezionata, plist, hklm o file, che è la sorgente che deve contenere lo snippet. Le sessioni incorporate di Claude Desktop non recuperano la policy del gateway, quindi il blocco cli del gateway non conta mai come sorgente selezionata per esse.

Limitare le impostazioni parent

Una volta distribuito parentSettingsBehavior: "merge", qualsiasi processo host che avvia Claude Code può fornire impostazioni parent, non solo Claude Desktop ma anche un'applicazione Agent SDK o un'estensione IDE.

Claude Code filtra le impostazioni parent in base a un'allowlist di chiavi restrittive, ma alcune chiavi consentite possono concedere accesso invece di limitarlo. A meno che tu non imposti i blocchi allowManaged*Only, le regole di consenso dei permessi e le allowlist della sandbox fornite dall'host si applicano comunque. Le regole di negazione e di richiesta della tua policy restano in vigore in ogni caso; vengono valutate prima di qualsiasi regola di consenso.

Claude Code inoltra le voci sandbox.credentials fornite dal parent in forma ridotta:

  • Voci deny: inoltrate solo con il loro path o name e la modalità.
  • Voci di file con mode: mask: inoltrate solo come sentinella, come maschera dell'intero file il cui injectHosts è l'elenco vuoto, quindi il proxy non sostituisce mai il valore reale per una voce fornita dal parent su nessuna piattaforma. Vengono eliminati anche tutti i campi di mascheramento strutturato, quindi un pattern di estrazione fornito dal parent non può soppiantare una maschera più rigorosa impostata da un'altra sorgente per lo stesso percorso.
  • Voci envVars con mode: mask: non inoltrate. deny è l'unica restrizione che il canale parent può esprimere tramite le voci envVars.
  • awsPairs e sigv4: inoltrati solo come restrizione. Di sigv4 vengono mantenuti solo i valori deny, e un parent che definisce un blocco sigv4 in qualsiasi forma imposta tutte e tre le forme di richiesta, streaming, presigned e sigv4a, su deny. Una coppia awsPairs non viene mai inoltrata in una forma che possa rifirmare; una coppia che indica una delle variabili AWS convenzionali viene sostituita da una voce inerte che mantiene soppresso l'abbinamento automatico di AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY e AWS_SESSION_TOKEN.

Distribuire i blocchi

Per mantenere le impostazioni parent il più vicino possibile a una forma puramente restrittiva, per quanto il filtro lo consenta, aggiungi tutti e cinque i blocchi allowManaged*Only, e le allowlist che governano, alle stesse sorgenti dell'opt-in al merge:

{
  "forceLoginMethod": "gateway",
  "forceLoginGatewayUrl": "https://claude-gateway.internal.example.com",
  "parentSettingsBehavior": "merge",
  "allowManagedPermissionRulesOnly": true,
  "allowManagedMcpServersOnly": true,
  "allowManagedHooksOnly": true,
  "allowedMcpServers": [{ "serverUrl": "https://mcp.internal.example.com/*" }],
  "sandbox": {
    "network": {
      "allowManagedDomainsOnly": true,
      "allowedDomains": ["github.com", "*.npmjs.org"]
    },
    "filesystem": {
      "allowManagedReadPathsOnly": true,
      "denyRead": ["~/"],
      "allowRead": ["~/projects"]
    }
  }
}

Una policy del sistema operativo, come una policy del registro HKLM o un plist di preferenze gestite, ha priorità superiore a questo file, quindi fornisci l'intero snippet tramite essa invece che tramite il file. Le impostazioni gestite remote del gateway hanno priorità superiore alle sorgenti della policy del sistema operativo e del file, ma raggiungono solo i client connessi. Replica i blocchi, le allowlist e l'opt-in al merge nel blocco cli della policy e mantieni distribuito questo file, perché le macchine che non si connettono mai, incluse quelle che eseguono solo Claude Desktop, ricevono la propria policy esclusivamente dal file.

Comportamento dei blocchi tra le sorgenti

Impostare un blocco non limita gli altri; ogni chiave è documentata nel riferimento delle impostazioni.

Da una sorgente di amministrazione al di sotto di quella vincente, i due blocchi della sandbox si applicano comunque, e allowManagedPermissionRulesOnly blocca comunque le regole di consenso e le additionalDirectories fornite dal parent. Su Claude Code v2.1.273 o successivo, anche il blocco dei server MCP si applica da una sorgente al di sotto di quella vincente, e mentre è attivo, l'elenco gestito allowedMcpServers proviene dalla sorgente di amministrazione con priorità più alta che ne imposta uno.

Il blocco degli hook e l'effetto di allowManagedPermissionRulesOnly sulle regole dello sviluppatore richiedono per impostazione predefinita la sorgente vincente; con l'opt-in al merge managedSourcesBehavior descritto in come Claude Code combina le sorgenti gestite, Claude Code applica per ogni blocco il valore più rigoroso impostato da qualsiasi sorgente. Sui parchi macchine con policyHelper, Claude Code legge i blocchi esclusivamente dall'output dell'helper.

Ogni blocco fa sì che Claude Code ignori le voci dello sviluppatore per quell'impostazione, quindi includi le allowlist della tua organizzazione accanto ai blocchi:

  • Domini di rete: bloccare con un elenco di domini gestiti vuoto blocca tutto il traffico in uscita dalla sandbox.
  • Server MCP: bloccare senza allowedMcpServers in nessuna sorgente di amministrazione né nelle impostazioni fornite dal parent carica ogni server che deniedMcpServers non blocca.
  • Percorsi di lettura: le voci allowRead riconsentono solo percorsi all'interno delle aree denyRead, quindi abbinale a un denyRead gestito.

Impostazioni non coperte dai blocchi

Queste impostazioni fornite dal parent superano il filtro anche con tutti e cinque i blocchi impostati:

  • forceLoginOrgUUID: Claude Code rispetta un valore fornito dal parent quando la sorgente di amministrazione con priorità più alta non imposta un UUID di organizzazione. L'accesso al gateway non verifica questa chiave. Un UUID di organizzazione nella sorgente di amministrazione con priorità più alta blocca il valore del parent ed è quello che Claude Code applica.
  • allowedMcpServers: Claude Code rispetta un'allowlist fornita dal parent quando non è in vigore alcun elenco di amministrazione. allowManagedMcpServersOnly non la blocca, perché il blocco applica come valore gestito qualunque elenco prevalga, incluso uno fornito dal parent quando nessuna sorgente di amministrazione fornisce un elenco. Un elenco nella sorgente di amministrazione con priorità più alta blocca quello del parent ed è l'elenco che Claude Code applica, quindi imposta allowedMcpServers lì, accanto al blocco. Prima della v2.1.223, un valore per una delle due chiavi in qualsiasi sorgente di amministrazione bloccava quello del parent.
  • availableModels: Claude Code rispetta un elenco di modelli fornito dal parent quando la sorgente gestita vincente non ne imposta uno. Se il tuo parco macchine limita i modelli, imposta availableModels nella sorgente vincente.
  • allowedProviders: Claude Code rispetta un'allowlist dei provider API fornita dal parent quando la sorgente gestita vincente non ne imposta una. Se il tuo parco macchine limita i provider API che gli sviluppatori possono usare, imposta allowedProviders nella sorgente vincente. Richiede Claude Code v2.1.285 o successivo.
  • strictKnownMarketplaces: Claude Code rispetta un'allowlist dei marketplace di plugin fornita dal parent quando la sorgente gestita vincente non ne imposta una. Claude Desktop 2.16120.0 o successivo ne invia una quando la sua configurazione gestita disattiva i marketplace di plugin aggiunti dall'utente. Se il tuo parco macchine limita i marketplace, imposta strictKnownMarketplaces nella sorgente vincente. Richiede Claude Code v2.1.282 o successivo.
  • blockedMarketplaces: una blocklist dei marketplace fornita dal parent supera il filtro e si aggiunge a qualsiasi blocklist impostata da una sorgente gestita, poiché una blocklist può solo restringere ulteriormente. Richiede Claude Code v2.1.282 o successivo.
  • strictPluginOnlyCustomization: questa chiave supera il filtro indipendentemente da qualsiasi blocco, e fa sì che Claude Code ignori le personalizzazioni dello sviluppatore, inclusi gli hook di protezione. Nessun blocco la blocca.

Con l'impostazione predefinita first-wins, un valore di amministrazione blocca quello del parent solo quando si trova nella sorgente di amministrazione con priorità più alta, tranne che per allowedMcpServers mentre il blocco dei server MCP è attivo. Con l'opt-in al merge managedSourcesBehavior, come Claude Code combina le sorgenti gestite indica invece quale valore di sorgente si applica.

Connettere Claude Desktop

Claude Desktop si connette allo stesso gateway tramite una chiave MDM diversa: imposta bootstrapUrl nella configurazione gestita di Claude Desktop su <listen.public_url>/user/bootstrap, e abilita la policy dell'utente con una chiave desktop. Overlay di Claude Desktop tratta entrambe le parti. Richiede Claude Code v2.1.203 o successivo sul server gateway.

Claude Desktop fa accedere lo sviluppatore tramite l'identity provider del gateway con lo stesso passaggio SSO nel browser, poi recupera la propria configurazione dal gateway invece che da Anthropic. L'accesso ai modelli e la policy seguono le stesse regole per gruppo della CLI. Uno sviluppatore che usa sia la CLI sia Claude Desktop accede a ciascuno separatamente; la sessione del gateway non è condivisa tra i due.

Una volta connesso, Claude Desktop invia le richieste al modello da ogni scheda abilitata attraverso il gateway. Mostra per impostazione predefinita le schede Cowork e Code. Per attivare anche la scheda Chat, imposta chatTabEnabled su true nella configurazione gestita di Claude Desktop, oppure nel blocco desktop della policy su un gateway che esegue Claude Code v2.1.227 o successivo.

Pipeline CI e macchine remote

Non esiste un flusso con token di servizio per le pipeline non presidiate. L'accesso al gateway esegue sempre il device flow nel browser, quindi un job CI senza uno sviluppatore che approvi l'accesso non può autenticarsi; configura questi job direttamente con il tuo provider.

Una volta che uno sviluppatore ha effettuato l'accesso, ogni sessione di Claude Code su quella macchina usa la sessione del gateway, incluse le esecuzioni non interattive di claude -p e le sessioni avviate dall'Agent SDK. Claude Code applica la policy del gateway a ciascuna di esse.

Il device flow separa la CLI che esegue il polling dal browser che approva, quindi funziona anche una macchina di sviluppo remota senza display: lo sviluppatore esegue /login via SSH sulla macchina remota e apre il link di verifica nel browser del proprio laptop.

Cosa viene imposto agli sviluppatori

Queste garanzie si applicano a ogni sessione con accesso effettuato tramite /login. Le sessioni incorporate avviate da Claude Desktop ricevono la propria policy come descritto in Fornire la policy alle sessioni di Claude Desktop, e il punto sulla telemetria indica dove vanno le loro esportazioni.

  • Accesso ai modelli: le richieste per modelli che la policy non concede restituiscono 400, e il selettore /model è filtrato in base all'allowlist availableModels della policy. Questo include il modello con cui una sessione si avvia prima che lo sviluppatore ne scelga uno; consulta Avviare le sessioni su un modello consentito dalla policy.
  • Destinazione della telemetria: nelle sessioni con accesso effettuato tramite /login, la CLI invia le proprie esportazioni OTLP/HTTP al gateway invece che a un OTEL_EXPORTER_OTLP_ENDPOINT impostato localmente, a meno che una policy non indichi il tuo collector come endpoint. Il gateway inoltra le esportazioni che riceve alle destinazioni in telemetry.forward_to.
    • Nelle sessioni incorporate avviate da Claude Desktop, la CLI invia le proprie esportazioni all'OTEL_EXPORTER_OTLP_ENDPOINT configurato. La CLI allega il token di sessione del gateway a queste esportazioni solo quando quell'endpoint punta al gateway stesso.
    • Se per un segnale non è configurata alcuna destinazione, il gateway lo accetta e lo scarta.
    • Se raccogli già la telemetria di Claude Code direttamente, aggiungi il tuo collector come destinazione forward_to, oppure indicalo in una policy per saltare l'inoltro.
  • Credenziali: il token del gateway è l'unica credenziale della sessione. I profili Anthropic e qualsiasi precedente accesso a claude.ai vengono ignorati mentre si è connessi, quindi gli sviluppatori non devono prima uscire da claude.ai. Per una credenziale ANTHROPIC_API_KEY, ANTHROPIC_AUTH_TOKEN o apiKeyHelper configurata, o una chiave API salvata da un precedente accesso a Claude Console, consulta Il criterio dell'amministratore richiede un accesso tramite Cloud gateway.
  • Impostazioni gestite: le chiavi bloccate non possono essere sovrascritte localmente. La CLI applica la policy all'avvio e applica le modifiche a ogni polling orario, a parte le modifiche che si applicano solo al successivo avvio.
  • Avvio con il gateway irraggiungibile: le sessioni con accesso effettuato terminano all'avvio con un errore dopo circa 10 secondi invece di avviarsi senza le proprie impostazioni.
  • Avvio dopo che il gateway ha terminato la sessione: consulta Imporre l'avvio fail-closed per gli avvii che si aprono senza accesso al gateway e quelli che terminano quando il gateway risponde con un 401.
  • Deprovisioning: una sessione il cui utente è disabilitato nell'IdP scade entro ttl_hours quando il rinnovo successivo fallisce.
  • Disconnessione: /logout elimina la credenziale del gateway dalla macchina dello sviluppatore.
    • Quando il documento di discovery del gateway dichiara un revocation_endpoint con lo stesso schema, host e porta dell'URL del gateway, /logout invia anche i token memorizzati a quell'endpoint, in modo che il gateway possa terminare la sessione dal proprio lato. La richiesta è best effort, quindi la disconnessione si completa sulla macchina dello sviluppatore indipendentemente dal fatto che l'endpoint risponda. La revoca richiede Claude Code v2.1.275 o successivo sulla macchina dello sviluppatore.
    • Il server gateway incluso nel binario claude non ne dichiara alcuno, quindi una disconnessione da esso termina la sessione solo sulla macchina dello sviluppatore. Per forzare la chiusura delle sessioni lato server, consulta Rotazione del segreto JWT.

Cosa può vedere l'organizzazione

La telemetria di utilizzo trasmette al collector dell'organizzazione l'identità dello sviluppatore, il numero di token, il modello e la latenza. Il gateway non registra né memorizza il contenuto dei prompt o delle risposte generate. Se venga raccolta una telemetria più ricca come log e trace, che può includere comandi e percorsi di file, è una scelta per destinazione dell'organizzazione.

Disponibilità e limitazioni

La tabella copre quali funzionalità di Claude Code funzionano quando gli sviluppatori si connettono attraverso il gateway e cosa supporta il server gateway stesso. Dove qualcosa non è supportato, la colonna Note fornisce l'alternativa.

Il gateway consegna i valori anthropic-beta che il CLI invia a ogni upstream, quindi gli operatori non mantengono un'allowlist beta. Per Amazon Bedrock, che ignora l'intestazione, il gateway sposta i valori nel campo anthropic_beta del corpo della richiesta; gli altri upstream ricevono l'intestazione come inviata.

Funzionalità Stato Note
Inoltro di inferenza (Amazon Bedrock, Claude Platform su AWS, Agent Platform di Google Cloud, Microsoft Foundry, Anthropic) Disponibile Con traduzione del modello per upstream e failover. L'upstream Amazon Bedrock utilizza l'endpoint bedrock-runtime e la catena di credenziali predefinita AWS. L'upstream Amazon Bedrock Mantle richiede Claude Code v2.1.283 o successivo sul server gateway, e l'upstream Claude Platform su AWS richiede v2.1.198 o successivo.
Finestra di contesto da 1M token Disponibile I modelli Fable, Sonnet 5 e successivi, e Opus 4.7 e successivi funzionano con la finestra da 1M per impostazione predefinita; vedi Contesto esteso. L'impostazione predefinita da 1M per i modelli Fable e Opus richiede Claude Code v2.1.287 o successivo sulla macchina dello sviluppatore
Accesso ai modelli e impostazioni gestite per gruppo IdP Disponibile L'accesso ai modelli viene applicato lato server; le impostazioni gestite vengono consegnate per gruppo IdP e applicate dal CLI al livello di impostazioni gestite
Claude Desktop Disponibile con consenso esplicito Il gateway fornisce la configurazione di Claude Desktop su /user/bootstrap una volta che una politica acconsente con una chiave desktop, e Claude Desktop invia richieste di modello dalle sue schede Cowork e Code, e dalla scheda Chat quando la abiliti, attraverso il gateway. Per attivare la scheda Chat, vedi Connetti Claude Desktop. Richiede Claude Code v2.1.203 o successivo sul server gateway.
Fan-out di telemetria (OTLP/HTTP) Disponibile Identità-timbrato per esportazione; entrambe le codifiche protobuf e JSON
Provider di identità OIDC Disponibile Qualsiasi IdP conforme a OIDC; il gateway esegue il discovery OIDC standard e il flusso del codice di autorizzazione. Vedi Configurazione del provider di identità per la configurazione per IdP
Limiti di spesa per utente e per gruppo Disponibile Vedi Limiti di spesa
Ricerca web lato server Non disponibile Il CLI non può vedere quale provider upstream il gateway instrada, quindi non può verificare il supporto della ricerca web e disabilita WebSearch sulle sessioni del gateway
Remote Control Non disponibile Il CLI mostra un errore che nomina il gateway
/design-sync e /design-login Non disponibile Entrambi hanno bisogno di claude.ai, che il CLI non contatta sulle sessioni del gateway, quindi nessuno dei due comandi appare lì
Funzionalità che necessitano di recupero dei flag di funzionalità, come /import e claude import Non disponibile Il CLI salta il recupero dei flag sulle sessioni del gateway. Funzionalità che necessitano di recupero dei flag di funzionalità elenca cosa questo disattiva
Prompt caching standard Disponibile Il gateway inoltra i breakpoint cache_control a ogni upstream. Dove risiede la cache copre quali blocchi il CLI contrassegna, incluso il contesto di sistema che aggiunge a metà conversazione
TTL cache di 1 ora Non disponibile Il CLI omette il beta della cache estesa sulle sessioni del gateway, perché non ogni upstream a cui il gateway può instradare supporta il TTL di 1 ora, quindi il prompt caching attraverso il gateway utilizza il TTL di 5 minuti; vedi la nota dell'intestazione beta sopra
Modalità auto Disponibile Segue le regole del provider di terze parti: solo i modelli idonei sui provider di terze parti possono usarla. Prima della v2.1.207, la modalità auto sulle sessioni del gateway richiedeva l'impostazione di CLAUDE_CODE_ENABLE_AUTO_MODE=1, consegnabile tramite il blocco env della politica gestita
Ottimizzazioni solo per la prima parte come ambito cache globale e strumenti efficienti in termini di token Non disponibile Il CLI non le abilita sulle sessioni del gateway; vedi la nota dell'intestazione beta sopra
OTLP/gRPC Non supportato OTLP su HTTP solo
SAML, LDAP e altri auth non OIDC Non supportato Solo OIDC. Fronte con un ponte OIDC se necessario
Multi-tenant (più emittenti OIDC) Non supportato Un emittente per gateway. Esegui istanze separate
Server Windows Non supportato Distribuisci su Linux. macOS solo per lo sviluppo locale
Helm chart Non disponibile Il gateway viene eseguito come una Deployment stateless standard; vedi la guida di distribuzione
Interfaccia utente amministratore Non disponibile La configurazione è il file YAML; ridistribuisci per cambiarla

Passaggi successivi

La guida rapida ti lascia con una configurazione minima in esecuzione sotto Docker Compose. Per andare oltre:

  • Espandi gateway.yaml oltre la configurazione minima, ad esempio per aggiungere RBAC per gruppo, failover multi-upstream o destinazioni di telemetria. Il riferimento di configurazione copre ogni opzione.
  • Passa da Compose a una distribuzione di produzione su Kubernetes o Cloud Run, configura correttamente il tuo IdP e rivedi il modello di sicurezza. La guida di distribuzione e operazioni copre la configurazione per IdP, i requisiti dell'immagine container, i probe di salute e la risoluzione dei problemi.
  • Metti limiti di spesa su singoli sviluppatori o gruppi in modo che un carico di lavoro incontrollato non possa consumare il tuo intero impegno. Limiti di spesa copre l'API amministratore e come funziona l'applicazione.
  • Per un esempio completo su AWS, con ECS Fargate o EKS, Amazon RDS e Secrets Manager, vedi Distribuisci su AWS.
  • Per un esempio completo su Google Cloud, con Cloud Run, Cloud SQL e Secret Manager, vedi Distribuisci su Google Cloud.