I backend CLI di OpenClaw

Quando un provider di API è fuori servizio, sotto rate limit o si comporta in modo anomalo, OpenClaw può eseguire una CLI di IA locale come fallback solo testuale. La documentazione è precisa sulla forma: gli strumenti non vengono iniettati direttamente, anche se un backend può ricevere gli strumenti del Gateway attraverso un bridge MCP in loopback, lo streaming è JSONL dove la CLI lo supporta, le sessioni sono supportate così i messaggi successivi restano coerenti, e le immagini passano quando la CLI accetta percorsi. È una rete di sicurezza, non un percorso principale, e non è ACP. Ecco l’avvio rapido, il collegamento del fallback, la meccanica di un turno, le specificità della CLI di Claude, le sessioni, il bridge MCP, la compattazione e i limiti.

Avvio rapido e fallback

• Il plugin Anthropic incluso registra un backend Claude CLI che funziona senza alcuna configurazione, a parte avere Claude Code installato e con l’accesso effettuato; un’esecuzione dell’agente di un solo messaggio con un riferimento a un modello Claude CLI lo dimostra, e il servizio del Gateway deve avere la CLI nel suo path, con un plugin di backend per un eseguibile non standard.
• Per usarlo solo quando i modelli principali falliscono, aggiungi un modello Claude CLI all’elenco dei fallback; i fallback configurati restano utilizzabili quando il principale fallisce per autenticazione, limiti di frequenza o timeout, anche se non sono nella policy dei modelli consentiti, che conta solo per la selezione diretta.
• Per instradare un modello Anthropic canonico attraverso la CLI, imposta l’id del runtime dell’agente su quel modello; le credenziali restano nei profili di autenticazione o nella configurazione del plugin, e comando, argomenti, ambiente, parsing, sessioni, immagini e meccanismi di watchdog sono codice del plugin.
• Un turno seleziona il backend in base al prefisso del provider, costruisce il prompt di sistema dallo stesso prompt di OpenClaw e dal contesto dello spazio di lavoro, esegue la CLI con un id di sessione dove supportato, analizza JSON o testo e salva gli id di sessione per backend, così i messaggi successivi riusano la sessione.

Usalo come rete di sicurezza per risposte testuali che “funzionano sempre”, non come percorso principale.

Le specificità della CLI di Claude

Il backend incluso comunica con l’eseguibile Claude Code installato tramite il suo protocollo stdio strutturato, mantiene un sottoprocesso caldo tra turni compatibili, avviandone uno nuovo quando cambiano il modello, il prompt di sistema o la policy degli strumenti, e riprende dagli id di sessione salvati dopo un riavvio; Claude Code gestisce in proprio l’accesso e l’abbonamento, e OpenClaw non legge, non salva, non rinnova e non inoltra mai i token nativi. Il contesto degli hook di costruzione del prompt arriva a Claude come allegato di hook nativo, le note di sessione salvate vengono riproposte entro un budget ponderato limitato, il resolver nativo delle skill viene usato tramite una directory temporanea di plugin quando una skill ha un percorso materializzato, e le istruzioni Git di Claude Code sono disattivate così le modifiche allo spazio di lavoro non invalidano la sua cronologia in cache. Claude Code si avvia nella sua modalità di permessi predefinita, mentre le risposte ai permessi e l’hook pre-tool di OpenClaw mantengono gli strumenti nativi sotto il controllo dell’host, proiettando i nomi degli strumenti nativi e gli argomenti dei file sui loro equivalenti OpenClaw prima della policy di exec e dell’approvazione; quando l’impostazione ask di exec chiede conferma, le richieste degli strumenti nativi vengono inoltrate al canale della sessione con allow once, allow always per la stessa sessione calda, e deny, dove un timeout, una route irraggiungibile o un turno chiuso valgono tutti come rifiuto, e allow always non si applica mai a Bash. I livelli di ragionamento corrispondono al flag di effort di Claude Code e, per i modelli a budget fisso, a un valore max-thinking-tokens, e funzionano sia l’accesso nativo sia un token di abbonamento incollato.

Bash nativo, sessioni, il bridge

• Con l’impostazione ask su on-miss, i comandi Bash nativi vengono verificati rispetto all’elenco degli autorizzati per exec dell’agente usando il valutatore di shell proprio di OpenClaw: una chiamata viene eseguita senza chiedere conferma solo quando ogni segmento si risolve in un binario autorizzato e può essere vincolato completamente, pipeline, sostituzioni, subshell e redirezioni vengono rifiutate prima di qualsiasi richiesta di conferma, e si tratta di una policy a livello di argomenti sul comando che Claude Code eseguirà, non di un’esecuzione in sandbox, perché directory di lavoro, path, ambiente e sandboxing li gestisce Claude Code.
• Le sessioni CLI salvate sono una continuità di proprietà del provider, verificata rispetto a una trascrizione leggibile prima della ripresa; le sessioni nuove possono recuperare la cronologia di OpenClaw dal database delle sessioni quando il confine dell’account corrisponde alla credenziale selezionata, e l’idoneità la decidono un’impronta privata dell’account e una copertura contigua della trascrizione, quindi cambiare account rende non idonea una cronologia mista e un’identità di autenticazione cambiata fa cadere il riuso della sessione. Un tentativo Claude CLI fallito può passare in failover a un modello non CLI inizializzato con un preambolo ricavato dalla trascrizione locale di Claude Code, cioè il suo ultimo riepilogo di compattazione più i turni recenti.
• Un backend che aderisce all’overlay bundle-MCP riceve un server MCP HTTP in loopback che espone gli strumenti del Gateway al processo della CLI con un token per esecuzione, legato alla sessione, all’account e al canale selezionati dal Gateway; le policy allow e deny vincolano anche i server MCP nativi, le esecuzioni ristrette come i job cron disattivano completamente gli strumenti nativi e le personalizzazioni di Claude ed espongono solo gli strumenti OpenClaw consentiti, e i runtime del bridge legati alla sessione vengono eliminati dopo dieci minuti di inattività.

L’articolo su OpenClaw e Claude Code mostra la stessa accoppiata vista dall’altro lato, e il failover dei modelli di OpenClaw è il meccanismo che decide quando entra in gioco il fallback.

Timeout, compattazione, limiti

Due limiti indipendenti: il budget del turno dell’agente, quarantotto ore per impostazione predefinita e zero per illimitato, e il watchdog per assenza di output della CLI, gestito dal backend, attivo anche quando il budget del turno è illimitato; il lavoro in background avviato dentro una CLI muore con il sottoprocesso quando il turno finisce, quindi il lavoro lungo e durevole spetta a un sotto-agente separato. Il backend Claude CLI dichiara di gestire la compattazione nativa, quindi OpenClaw si rimette a Claude Code e inoltra il budget di contesto attraverso la finestra di auto-compact di Claude Code, mentre un comando compact esplicito riprende la sessione vincolata e invia quello nativo; anche il backend Gemini CLI gestisce la propria compattazione, senza comando manuale. Il backend Claude fa capo ad Anthropic e quello di Gemini a Google, e i prerequisiti di quest’ultimo sono la CLI nel path e un profilo con chiave Google AI Studio; non esiste un backend Codex CLI incluso, perché Codex passa attraverso l’harness app-server. I limiti: nessuna chiamata agli strumenti iniettata nel protocollo della CLI senza il bridge, uno streaming che varia a seconda del backend e output strutturati che dipendono dal JSON della CLI stessa. Le approvazioni exec di OpenClaw coprono l’elenco degli autorizzati rispetto a cui viene verificato Bash nativo, mentre la guida a OpenClaw con Gemini descrive il provider dietro il secondo backend incluso.

Su Diali

Su Diali non c’è una CLI sull’host su cui ripiegare: il percorso verso il modello è la chiave API nel Vault o i crediti gestiti, e il failover avviene tra provider anziché verso un binario locale. OpenClaw ospitato su Diali è l’assistente e la guida ai modelli e ai provider di OpenClaw copre i provider che quel percorso può usare.

• Un fallback, non un percorso principale.
• Sottoprocesso caldo, accesso nativo, strumenti solo attraverso il bridge.
• Bash nativo è filtrato da OpenClaw con l’elenco degli autorizzati, mai messo in sandbox.