CLI commands
Onboarding
openclaw onboard
Onboarding guidato completo per la configurazione del Gateway locale o remoto. Usalo quando vuoi che OpenClaw guidi in un unico flusso l’autenticazione del modello, il workspace, il gateway, i canali, le Skills e lo stato di salute.
Guide correlate
Procedura guidata del flusso CLI interattivo.
Come si integra l’onboarding di OpenClaw.
Output, componenti interni e comportamento per ogni passaggio.
Flag non interattivi e configurazioni tramite script.
Flusso di onboarding per l’app della barra dei menu macOS.
Esempi
openclaw onboardopenclaw onboard --modernopenclaw onboard --flow quickstartopenclaw onboard --flow manualopenclaw onboard --flow importopenclaw onboard --import-from hermes --import-source ~/.hermesopenclaw onboard --skip-bootstrapopenclaw onboard --mode remote --remote-url wss://gateway-host:18789--flow import usa provider di migrazione di proprietà del plugin, come Hermes. Viene eseguito solo su una configurazione OpenClaw nuova; se sono presenti config, credenziali, sessioni o file di memoria/identità del workspace esistenti, reimposta o scegli una configurazione nuova prima di importare.
--modern avvia l’anteprima di onboarding conversazionale Crestodian. Senza
--modern, openclaw onboard mantiene il flusso di onboarding classico.
In una nuova installazione in cui il file di configurazione attivo manca o non contiene
impostazioni create dall’utente (vuoto o solo metadati), anche openclaw senza argomenti avvia il flusso di
onboarding classico. Dopo che un file di configurazione contiene impostazioni create dall’utente, openclaw
senza argomenti apre invece Crestodian.
ws:// in chiaro è accettato per local loopback, literal IP privati, .local e
URL Gateway Tailnet *.ts.net. Per altri nomi DNS privati attendibili, imposta
OPENCLAW_ALLOW_INSECURE_PRIVATE_WS=1 nell’ambiente del processo di onboarding.
Locale
L’onboarding interattivo usa la locale della procedura guidata CLI per il testo fisso di configurazione. L’ordine di risoluzione è:
OPENCLAW_LOCALELC_ALLLC_MESSAGESLANG- Fallback all’inglese
Le locale supportate dalla procedura guidata sono en, zh-CN e zh-TW. I valori della locale possono usare
forme con underscore o suffissi POSIX, come zh_CN.UTF-8. Nomi di prodotto, nomi di comando,
chiavi di configurazione, URL, ID provider, ID modello ed etichette di plugin/canale
rimangono letterali.
Esempio:
OPENCLAW_LOCALE=zh-CN openclaw onboardProvider personalizzato non interattivo:
openclaw onboard --non-interactive \ --auth-choice custom-api-key \ --custom-base-url "https://llm.example.com/v1" \ --custom-model-id "foo-large" \ --custom-api-key "$CUSTOM_API_KEY" \ --secret-input-mode plaintext \ --custom-compatibility openai \ --custom-image-input--custom-api-key è opzionale in modalità non interattiva. Se omesso, l’onboarding controlla CUSTOM_API_KEY.
OpenClaw contrassegna automaticamente come compatibili con le immagini gli ID modello di visione più comuni. Passa --custom-image-input per ID di visione personalizzati sconosciuti, oppure --custom-text-input per forzare metadati solo testo.
Usa --custom-compatibility openai-responses per endpoint compatibili con OpenAI che supportano /v1/responses ma non /v1/chat/completions.
LM Studio supporta anche un flag di chiave specifico del provider in modalità non interattiva:
openclaw onboard --non-interactive \ --auth-choice lmstudio \ --custom-base-url "http://localhost:1234/v1" \ --custom-model-id "qwen/qwen3.5-9b" \ --lmstudio-api-key "$LM_API_TOKEN" \ --accept-riskOllama non interattivo:
openclaw onboard --non-interactive \ --auth-choice ollama \ --custom-base-url "http://ollama-host:11434" \ --custom-model-id "qwen3.5:27b" \ --accept-risk--custom-base-url usa come predefinito http://127.0.0.1:11434. --custom-model-id è opzionale; se omesso, l’onboarding usa i valori predefiniti suggeriti da Ollama. Anche gli ID modello cloud come kimi-k2.5:cloud funzionano qui.
Archivia le chiavi provider come riferimenti invece che come testo in chiaro:
openclaw onboard --non-interactive \ --auth-choice openai-api-key \ --secret-input-mode ref \ --accept-riskCon --secret-input-mode ref, l’onboarding scrive riferimenti basati su env invece di valori chiave in chiaro.
Per i provider basati su profilo di autenticazione, questo scrive voci keyRef; per i provider personalizzati scrive models.providers.<id>.apiKey come riferimento env (per esempio { source: "env", provider: "default", id: "CUSTOM_API_KEY" }).
Contratto della modalità non interattiva ref:
- Imposta la variabile env del provider nell’ambiente del processo di onboarding (per esempio
OPENAI_API_KEY). - Non passare flag di chiave inline (per esempio
--openai-api-key) a meno che anche quella variabile env non sia impostata. - Se viene passato un flag di chiave inline senza la variabile env richiesta, l’onboarding fallisce subito con indicazioni.
Opzioni token Gateway in modalità non interattiva:
--gateway-auth token --gateway-token <token>archivia un token in chiaro.--gateway-auth token --gateway-token-ref-env <name>archiviagateway.auth.tokencome SecretRef env.--gateway-tokene--gateway-token-ref-envsi escludono a vicenda.--gateway-token-ref-envrichiede una variabile env non vuota nell’ambiente del processo di onboarding.- Con
--install-daemon, quando l’autenticazione token richiede un token, i token Gateway gestiti tramite SecretRef vengono convalidati ma non persistiti come testo in chiaro risolto nei metadati dell’ambiente del servizio supervisor. - Con
--install-daemon, se la modalità token richiede un token e il SecretRef del token configurato non viene risolto, l’onboarding fallisce in modo chiuso con indicazioni di correzione. - Con
--install-daemon, se sono configurati siagateway.auth.tokensiagateway.auth.passwordegateway.auth.modenon è impostato, l’onboarding blocca l’installazione finché la modalità non viene impostata esplicitamente. - L’onboarding locale scrive
gateway.mode="local"nella configurazione. Se un file di configurazione successivo non contienegateway.mode, considera questo come una configurazione danneggiata o una modifica manuale incompleta, non come una scorciatoia valida per la modalità locale. - L’onboarding locale installa i plugin scaricabili selezionati quando il percorso di configurazione scelto li richiede.
- L’onboarding remoto scrive solo le informazioni di connessione per il Gateway remoto e non installa pacchetti plugin locali.
--allow-unconfiguredè una via di fuga separata per il runtime Gateway. Non significa che l’onboarding possa ometteregateway.mode.
Esempio:
export OPENCLAW_GATEWAY_TOKEN="your-token"openclaw onboard --non-interactive \ --mode local \ --auth-choice skip \ --gateway-auth token \ --gateway-token-ref-env OPENCLAW_GATEWAY_TOKEN \ --accept-riskStato di salute del gateway locale non interattivo:
- A meno che tu non passi
--skip-health, l’onboarding attende un gateway locale raggiungibile prima di uscire con successo. --install-daemonavvia prima il percorso di installazione del gateway gestito. Senza di esso, devi già avere un gateway locale in esecuzione, per esempioopenclaw gateway run.- Se in automazione vuoi solo scritture di config/workspace/bootstrap, usa
--skip-health. - Se gestisci autonomamente i file del workspace, passa
--skip-bootstrapper impostareagents.defaults.skipBootstrap: truee saltare la creazione diAGENTS.md,SOUL.md,TOOLS.md,IDENTITY.md,USER.md,HEARTBEAT.mdeBOOTSTRAP.md. - Su Windows nativo,
--install-daemonprova prima le Attività pianificate e, se la creazione dell’attività viene negata, ripiega su un elemento di login nella cartella Esecuzione automatica per utente.
Comportamento dell’onboarding interattivo con modalità riferimento:
- Scegli Usa riferimento segreto quando richiesto.
- Poi scegli una delle due opzioni:
- Variabile di ambiente
- Provider di segreti configurato (
fileoexec)
- L’onboarding esegue una rapida convalida preliminare prima di salvare il riferimento.
- Se la convalida fallisce, l’onboarding mostra l’errore e ti permette di riprovare.
Scelte endpoint Z.AI non interattive
# Promptless endpoint selectionopenclaw onboard --non-interactive \ --auth-choice zai-coding-global \ --zai-api-key "$ZAI_API_KEY" # Other Z.AI endpoint choices:# --auth-choice zai-coding-cn# --auth-choice zai-global# --auth-choice zai-cnEsempio Mistral non interattivo:
openclaw onboard --non-interactive \ --auth-choice mistral-api-key \ --mistral-api-key "$MISTRAL_API_KEY"Flag non interattivi aggiuntivi
Autenticazione modello basata su token (non interattiva; usata con --auth-choice token):
--token-provider <id>— ID provider del token. Identifica quale provider emette il token.--token <token>— Valore del token per l’autenticazione del modello.--token-profile-id <id>— ID profilo di autenticazione. L’archiviazione generica dei token usa come predefinito<provider>:manual; i flussi di configurazione di proprietà del provider possono usare il proprio valore predefinito, comeanthropic:default.--token-expires-in <duration>— Durata opzionale della scadenza del token (per esempio365d,12h).
Cloudflare AI Gateway (non interattivo):
--cloudflare-ai-gateway-account-id <id>— ID account Cloudflare per il routing tramite Cloudflare AI Gateway.--cloudflare-ai-gateway-gateway-id <id>— ID Cloudflare AI Gateway.
Controllo installazione daemon:
--no-install-daemon— Salta esplicitamente l’installazione del servizio gateway.--skip-daemon— Alias di--no-install-daemon.
Controllo configurazione UI e hook:
--skip-ui— Salta le richieste Control UI / TUI durante l’onboarding.--skip-hooks— Salta le richieste di configurazione webhook / hook durante l’onboarding.
Soppressione output:
--suppress-gateway-token-output— Sopprime l’output Gateway/UI contenente token (suggerimenti token, URL di accesso automatico con token incorporato e avvio automatico della Control UI). Utile in ambienti terminale condivisi e CI.
Note sul flusso
Tipi di flusso
quickstart: richieste minime, genera automaticamente un token gateway.manual: richieste complete per porta, bind e autenticazione (alias diadvanced).import: esegue un provider di migrazione rilevato, mostra l’anteprima del piano, poi applica dopo la conferma.
Prefiltraggio provider
Quando una scelta di autenticazione implica un provider preferito, l’onboarding prefiltra i selettori del modello predefinito e dell’allowlist su quel provider. Per Volcengine e BytePlus, questo corrisponde anche alle varianti coding-plan (volcengine-plan/*, byteplus-plan/*).
Se il filtro del provider preferito non produce ancora modelli caricati, l’onboarding ripiega sul catalogo non filtrato invece di lasciare il selettore vuoto.
Follow-up ricerca web
Alcuni provider di ricerca web attivano richieste di follow-up specifiche del provider:
- Grok può offrire una configurazione opzionale
x_searchcon lo stesso profilo OAuth xAI o la stessa chiave API e una scelta di modellox_search. - Kimi può chiedere la regione API Moonshot (
api.moonshot.airispetto aapi.moonshot.cn) e il modello di ricerca web Kimi predefinito.
Altri comportamenti
- Comportamento dell’ambito DM dell’onboarding locale: Riferimento configurazione CLI.
- Prima chat più rapida:
openclaw dashboard(Control UI, nessuna configurazione canale). - Provider personalizzato: connetti qualsiasi endpoint compatibile con OpenAI o Anthropic, inclusi provider ospitati non elencati. Usa Unknown per rilevare automaticamente.
- Se viene rilevato uno stato Hermes, l’onboarding offre un flusso di migrazione. Usa Migra per piani dry-run, modalità sovrascrittura, report e mappature esatte.
Comandi comuni di follow-up
openclaw channels addopenclaw configureopenclaw agents add <name>Usa openclaw setup come lo stesso punto di ingresso dell’onboarding guidato. Usa openclaw setup --baseline quando ti serve solo la configurazione/workspace di base, openclaw configure in seguito per modifiche mirate e openclaw channels add per la configurazione solo dei canali.