> ## Documentation Index
> Fetch the complete documentation index at: https://docs2.openclaw.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Test: suite dal vivo

Per l'avvio rapido, i runner QA, le suite unit/integration e i flussi Docker, vedi
[Testing](/it/help/testing). Questa pagina copre le suite di test **live** (che toccano la rete):
matrice dei modelli, backend CLI, ACP e test live dei provider multimediali, oltre alla
gestione delle credenziali.

## Live: comandi smoke locali

Esporta la chiave del provider necessaria nell'ambiente del processo prima dei controlli live
ad hoc.

Smoke sicuro dei media:

```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}
pnpm openclaw infer tts convert --local --json \
  --text "OpenClaw live smoke." \
  --output /tmp/openclaw-live-smoke.mp3
```

Smoke sicuro di preparazione alle chiamate vocali:

```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}
pnpm openclaw voicecall setup --json
pnpm openclaw voicecall smoke --to "+15555550123"
```

`voicecall smoke` è un dry run a meno che non sia presente anche `--yes`. Usa `--yes` solo
quando vuoi intenzionalmente effettuare una vera chiamata di notifica. Per Twilio, Telnyx e
Plivo, un controllo di preparazione riuscito richiede un URL Webhook pubblico; i fallback
local-only loopback/privati sono rifiutati per progettazione.

## Live: sweep delle capacità del nodo Android

* Test: `src/gateway/android-node.capabilities.live.test.ts`
* Script: `pnpm android:test:integration`
* Obiettivo: invocare **ogni comando attualmente pubblicizzato** da un nodo Android connesso e verificare il comportamento del contratto dei comandi.
* Ambito:
  * Setup manuale/precondizionato (la suite non installa/esegue/abbina l'app).
  * Validazione `node.invoke` del Gateway comando per comando per il nodo Android selezionato.
* Pre-setup richiesto:
  * App Android già connessa + abbinata al Gateway.
  * App mantenuta in primo piano.
  * Autorizzazioni/consenso alla cattura concessi per le capacità che ti aspetti superino il test.
* Override opzionali del target:
  * `OPENCLAW_ANDROID_NODE_ID` o `OPENCLAW_ANDROID_NODE_NAME`.
  * `OPENCLAW_ANDROID_GATEWAY_URL` / `OPENCLAW_ANDROID_GATEWAY_TOKEN` / `OPENCLAW_ANDROID_GATEWAY_PASSWORD`.
* Dettagli completi del setup Android: [App Android](/it/platforms/android)

## Live: smoke dei modelli (chiavi dei profili)

I test live sono divisi in due livelli, così possiamo isolare i guasti:

* "Modello diretto" ci dice se il provider/modello può rispondere con la chiave indicata.
* "Gateway smoke" ci dice se l'intera pipeline Gateway+agent funziona per quel modello (sessioni, cronologia, strumenti, policy sandbox, ecc.).

### Livello 1: completamento diretto del modello (senza Gateway)

* Test: `src/agents/models.profiles.live.test.ts`
* Obiettivo:
  * Enumerare i modelli rilevati
  * Usare `getApiKeyForModel` per selezionare i modelli per cui hai credenziali
  * Eseguire un piccolo completamento per modello (e regressioni mirate dove necessario)
* Come abilitarlo:
  * `pnpm test:live` (o `OPENCLAW_LIVE_TEST=1` se invochi Vitest direttamente)
* Imposta `OPENCLAW_LIVE_MODELS=modern`, `small` o `all` (alias di modern) per eseguire effettivamente questa suite; altrimenti viene saltata per mantenere `pnpm test:live` focalizzato sul Gateway smoke
* Come selezionare i modelli:
  * `OPENCLAW_LIVE_MODELS=modern` per eseguire l'allowlist moderna (Opus/Sonnet 4.6+, GPT-5.2 + Codex, Gemini 3, DeepSeek V4, GLM 5.1, MiniMax M3, Grok 4.3)
  * `OPENCLAW_LIVE_MODELS=small` per eseguire l'allowlist vincolata dei modelli piccoli (route Qwen 8B/9B compatibili localmente, Ollama Gemma, OpenRouter Qwen/GLM e Z.AI GLM)
  * `OPENCLAW_LIVE_MODELS=all` è un alias dell'allowlist moderna
  * oppure `OPENCLAW_LIVE_MODELS="openai/gpt-5.5,anthropic/claude-opus-4-6,..."` (allowlist separata da virgole)
  * Le esecuzioni locali Ollama per modelli piccoli usano come default `http://127.0.0.1:11434`; imposta `OPENCLAW_LIVE_OLLAMA_BASE_URL` solo per endpoint LAN, personalizzati o Ollama Cloud.
  * Gli sweep modern/all e small usano come default i rispettivi limiti curati; imposta `OPENCLAW_LIVE_MAX_MODELS=0` per uno sweep esaustivo dei profili selezionati o un numero positivo per un limite più piccolo.
  * Gli sweep esaustivi usano `OPENCLAW_LIVE_TEST_TIMEOUT_MS` per il timeout dell'intero test diretto del modello. Default: 60 minuti.
  * Le probe dirette del modello vengono eseguite con parallelismo a 20 vie per impostazione predefinita; imposta `OPENCLAW_LIVE_MODEL_CONCURRENCY` per sovrascriverlo.
* Come selezionare i provider:
  * `OPENCLAW_LIVE_PROVIDERS="google,google-antigravity,google-gemini-cli"` (allowlist separata da virgole)
* Da dove arrivano le chiavi:
  * Per impostazione predefinita: archivio profili e fallback env
  * Imposta `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` per imporre solo **archivio profili**
* Perché esiste:
  * Separa "l'API del provider è rotta / la chiave non è valida" da "la pipeline agent del Gateway è rotta"
  * Contiene regressioni piccole e isolate (esempio: replay del ragionamento OpenAI Responses/Codex Responses + flussi tool-call)

### Livello 2: Gateway + smoke dell'agent dev (quello che "@openclaw" fa davvero)

* Test: `src/gateway/gateway-models.profiles.live.test.ts`
* Obiettivo:
  * Avviare un Gateway in-process
  * Creare/applicare patch a una sessione `agent:dev:*` (override del modello per esecuzione)
  * Iterare sui modelli con chiavi e verificare:
    * risposta "significativa" (senza strumenti)
    * una vera invocazione di strumento funziona (probe di lettura)
    * probe di strumenti extra opzionali (probe exec+read)
    * i percorsi di regressione OpenAI (solo tool-call → follow-up) continuano a funzionare
* Dettagli delle probe (così puoi spiegare rapidamente i guasti):
  * probe `read`: il test scrive un file nonce nell'area di lavoro e chiede all'agent di leggerlo con `read` e ripetere il nonce.
  * probe `exec+read`: il test chiede all'agent di scrivere con `exec` un nonce in un file temporaneo, quindi rileggerlo con `read`.
  * probe immagine: il test allega un PNG generato (gatto + codice casuale) e si aspetta che il modello restituisca `cat <CODE>`.
  * Riferimento implementativo: `src/gateway/gateway-models.profiles.live.test.ts` e `test/helpers/live-image-probe.ts`.
* Come abilitarlo:
  * `pnpm test:live` (o `OPENCLAW_LIVE_TEST=1` se invochi Vitest direttamente)
* Come selezionare i modelli:
  * Default: allowlist moderna (Opus/Sonnet 4.6+, GPT-5.2 + Codex, Gemini 3, DeepSeek V4, GLM 4.7, MiniMax M3, Grok 4.3)
  * `OPENCLAW_LIVE_GATEWAY_MODELS=small` per eseguire la stessa allowlist vincolata dei modelli piccoli attraverso l'intera pipeline Gateway+agent
  * `OPENCLAW_LIVE_GATEWAY_MODELS=all` è un alias dell'allowlist moderna
  * Oppure imposta `OPENCLAW_LIVE_GATEWAY_MODELS="provider/model"` (o lista separata da virgole) per restringere
  * Gli sweep Gateway modern/all e small usano come default i rispettivi limiti curati; imposta `OPENCLAW_LIVE_GATEWAY_MAX_MODELS=0` per uno sweep esaustivo selezionato o un numero positivo per un limite più piccolo.
* Come selezionare i provider (evita "tutto OpenRouter"):
  * `OPENCLAW_LIVE_GATEWAY_PROVIDERS="google,google-antigravity,google-gemini-cli,openai,anthropic,zai,minimax"` (allowlist separata da virgole)
* Le probe strumenti + immagini sono sempre attive in questo test live:
  * probe `read` + probe `exec+read` (stress degli strumenti)
  * la probe immagine viene eseguita quando il modello pubblicizza il supporto all'input immagine
  * Flusso (ad alto livello):
    * Il test genera un piccolo PNG con "CAT" + codice casuale (`test/helpers/live-image-probe.ts`)
    * Lo invia tramite `agent` `attachments: [{ mimeType: "image/png", content: "<base64>" }]`
    * Il Gateway analizza gli allegati in `images[]` (`src/gateway/server-methods/agent.ts` + `src/gateway/chat-attachments.ts`)
    * L'agent incorporato inoltra al modello un messaggio utente multimodale
    * Asserzione: la risposta contiene `cat` + il codice (tolleranza OCR: errori minori consentiti)

<Tip>
  Per vedere cosa puoi testare sulla tua macchina (e gli id `provider/model` esatti), esegui:

  ```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}
  openclaw models list
  openclaw models list --json
  ```
</Tip>

## Live: smoke backend CLI (Claude, Gemini o altre CLI locali)

* Test: `src/gateway/gateway-cli-backend.live.test.ts`
* Obiettivo: validare la pipeline Gateway + agent usando un backend CLI locale, senza toccare la tua config predefinita.
* I default smoke specifici del backend vivono con la definizione `cli-backend.ts` dell'estensione proprietaria.
* Abilita:
  * `pnpm test:live` (o `OPENCLAW_LIVE_TEST=1` se invochi Vitest direttamente)
  * `OPENCLAW_LIVE_CLI_BACKEND=1`
* Default:
  * Provider/modello predefinito: `claude-cli/claude-sonnet-4-6`
  * Comportamento comando/argomenti/immagine proviene dai metadati del Plugin backend CLI proprietario.
* Override (opzionali):
  * `OPENCLAW_LIVE_CLI_BACKEND_MODEL="claude-cli/claude-sonnet-4-6"`
  * `OPENCLAW_LIVE_CLI_BACKEND_COMMAND="/full/path/to/claude"`
  * `OPENCLAW_LIVE_CLI_BACKEND_ARGS='["-p","--output-format","json"]'`
  * `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_PROBE=1` per inviare un vero allegato immagine (i percorsi vengono iniettati nel prompt). Le ricette Docker lo disattivano per impostazione predefinita salvo richiesta esplicita.
  * `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_ARG="--image"` per passare i percorsi dei file immagine come argomenti CLI invece dell'iniezione nel prompt.
  * `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_MODE="repeat"` (o `"list"`) per controllare come vengono passati gli argomenti immagine quando `IMAGE_ARG` è impostato.
  * `OPENCLAW_LIVE_CLI_BACKEND_RESUME_PROBE=1` per inviare un secondo turno e validare il flusso di ripresa.
  * `OPENCLAW_LIVE_CLI_BACKEND_MODEL_SWITCH_PROBE=1` per aderire alla probe di continuità nella stessa sessione Claude Sonnet -> Opus quando il modello selezionato supporta un target di switch. Le ricette Docker lo disattivano per impostazione predefinita per affidabilità aggregata.
  * `OPENCLAW_LIVE_CLI_BACKEND_MCP_PROBE=1` per aderire alla probe MCP/strumento local loopback. Le ricette Docker lo disattivano per impostazione predefinita salvo richiesta esplicita.

Esempio:

```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}
  OPENCLAW_LIVE_CLI_BACKEND=1 \
  OPENCLAW_LIVE_CLI_BACKEND_MODEL="claude-cli/claude-sonnet-4-6" \
  pnpm test:live src/gateway/gateway-cli-backend.live.test.ts
```

Smoke economico della config Gemini MCP:

```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}
OPENCLAW_LIVE_TEST=1 \
  pnpm test:live src/agents/cli-runner/bundle-mcp.gemini.live.test.ts
```

Questo non chiede a Gemini di generare una risposta. Scrive le stesse impostazioni di sistema
che OpenClaw fornisce a Gemini, quindi esegue `gemini --debug mcp list` per provare che un server
salvato `transport: "streamable-http"` venga normalizzato nella forma HTTP MCP di Gemini
e possa connettersi a un server MCP streamable-HTTP locale.

Ricetta Docker:

```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}
pnpm test:docker:live-cli-backend
```

Ricette Docker per singolo provider:

```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}
pnpm test:docker:live-cli-backend:claude
pnpm test:docker:live-cli-backend:claude-subscription
pnpm test:docker:live-cli-backend:gemini
```

Note:

* Il runner Docker si trova in `scripts/test-live-cli-backend-docker.sh`.
* Esegue lo smoke live del backend CLI dentro l'immagine Docker del repo come utente non-root `node`.
* Risolve i metadati smoke della CLI dall'estensione proprietaria, quindi installa il pacchetto CLI Linux corrispondente (`@anthropic-ai/claude-code` o `@google/gemini-cli`) in un prefisso scrivibile con cache in `OPENCLAW_DOCKER_CLI_TOOLS_DIR` (default: `~/.cache/openclaw/docker-cli-tools`).
* `pnpm test:docker:live-cli-backend:claude-subscription` richiede OAuth portabile della sottoscrizione Claude Code tramite `~/.claude/.credentials.json` con `claudeAiOauth.subscriptionType` oppure `CLAUDE_CODE_OAUTH_TOKEN` da `claude setup-token`. Prima prova `claude -p` diretto in Docker, poi esegue due turni Gateway CLI-backend senza preservare variabili env di chiave API Anthropic. Questa lane di sottoscrizione disabilita per impostazione predefinita le probe Claude MCP/strumento e immagine perché consuma i limiti d'uso della sottoscrizione con accesso effettuato e Anthropic può cambiare il comportamento di fatturazione e rate-limit di Claude Agent SDK / `claude -p` senza una release OpenClaw.
* Lo smoke live del backend CLI ora esercita lo stesso flusso end-to-end per Claude e Gemini: turno testuale, turno di classificazione immagine, quindi chiamata allo strumento MCP `cron` verificata tramite la CLI Gateway.
* Lo smoke predefinito di Claude applica anche una patch alla sessione da Sonnet a Opus e verifica che la sessione ripresa ricordi ancora una nota precedente.

## Live: raggiungibilità proxy APNs HTTP/2

* Test: `src/infra/push-apns-http2.live.test.ts`
* Obiettivo: effettuare un tunnel attraverso un proxy HTTP CONNECT locale verso l'endpoint APNs sandbox di Apple, inviare la richiesta di validazione APNs HTTP/2 e verificare che la vera risposta Apple `403 InvalidProviderToken` ritorni attraverso il percorso proxy.
* Abilita:
  * `OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_APNS_REACHABILITY=1 pnpm test:live src/infra/push-apns-http2.live.test.ts`
* Timeout opzionale:
  * `OPENCLAW_LIVE_APNS_TIMEOUT_MS=30000`

## Live: smoke bind ACP (`/acp spawn ... --bind here`)

* Test: `src/gateway/gateway-acp-bind.live.test.ts`
* Obiettivo: convalidare il flusso reale di associazione conversazione ACP con un agent ACP live:
  * inviare `/acp spawn <agent> --bind here`
  * associare in loco una conversazione sintetica del canale messaggi
  * inviare un normale follow-up nella stessa conversazione
  * verificare che il follow-up arrivi nella trascrizione della sessione ACP associata
* Abilitazione:
  * `pnpm test:live src/gateway/gateway-acp-bind.live.test.ts`
  * `OPENCLAW_LIVE_ACP_BIND=1`
* Valori predefiniti:
  * agent ACP in Docker: `claude,codex,gemini`
  * agent ACP per `pnpm test:live ...` diretto: `claude`
  * Canale sintetico: contesto di conversazione in stile DM Slack
  * Backend ACP: `acpx`
* Override:
  * `OPENCLAW_LIVE_ACP_BIND_AGENT=claude`
  * `OPENCLAW_LIVE_ACP_BIND_AGENT=codex`
  * `OPENCLAW_LIVE_ACP_BIND_AGENT=droid`
  * `OPENCLAW_LIVE_ACP_BIND_AGENT=gemini`
  * `OPENCLAW_LIVE_ACP_BIND_AGENT=opencode`
  * `OPENCLAW_LIVE_ACP_BIND_AGENTS=claude,codex,gemini`
  * `OPENCLAW_LIVE_ACP_BIND_AGENT_COMMAND='npx -y @agentclientprotocol/claude-agent-acp@<version>'`
  * `OPENCLAW_LIVE_ACP_BIND_CODEX_MODEL=gpt-5.5`
  * `OPENCLAW_LIVE_ACP_BIND_OPENCODE_MODEL=opencode/kimi-k2.6`
  * `OPENCLAW_LIVE_ACP_BIND_REQUIRE_TRANSCRIPT=1`
  * `OPENCLAW_LIVE_ACP_BIND_REQUIRE_CRON=1`
  * `OPENCLAW_LIVE_ACP_BIND_PARENT_MODEL=openai/gpt-5.5`
* Note:
  * Questa lane usa la superficie gateway `chat.send` con campi sintetici admin-only per la route di origine, così i test possono collegare il contesto del canale messaggi senza fingere una consegna esterna.
  * Quando `OPENCLAW_LIVE_ACP_BIND_AGENT_COMMAND` non è impostato, il test usa il registro agent integrato del Plugin `acpx` incorporato per l'agent harness ACP selezionato.
  * La creazione MCP Cron della sessione associata è best-effort per impostazione predefinita perché gli harness ACP esterni possono annullare le chiamate MCP dopo che la prova bind/immagine è passata; imposta `OPENCLAW_LIVE_ACP_BIND_REQUIRE_CRON=1` per rendere rigorosa quella sonda Cron post-bind.

Esempio:

```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}
OPENCLAW_LIVE_ACP_BIND=1 \
  OPENCLAW_LIVE_ACP_BIND_AGENT=claude \
  pnpm test:live src/gateway/gateway-acp-bind.live.test.ts
```

Ricetta Docker:

```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}
pnpm test:docker:live-acp-bind
```

Ricette Docker per singolo agent:

```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}
pnpm test:docker:live-acp-bind:claude
pnpm test:docker:live-acp-bind:codex
pnpm test:docker:live-acp-bind:droid
pnpm test:docker:live-acp-bind:gemini
pnpm test:docker:live-acp-bind:opencode
```

Note Docker:

* Il runner Docker si trova in `scripts/test-live-acp-bind-docker.sh`.
* Per impostazione predefinita, esegue lo smoke ACP bind contro gli agent CLI live aggregati in sequenza: `claude`, `codex`, poi `gemini`.
* Usa `OPENCLAW_LIVE_ACP_BIND_AGENTS=claude`, `OPENCLAW_LIVE_ACP_BIND_AGENTS=codex`, `OPENCLAW_LIVE_ACP_BIND_AGENTS=droid`, `OPENCLAW_LIVE_ACP_BIND_AGENTS=gemini` o `OPENCLAW_LIVE_ACP_BIND_AGENTS=opencode` per restringere la matrice.
* Prepara nel container il materiale di autenticazione CLI corrispondente, quindi installa la CLI live richiesta (`@anthropic-ai/claude-code`, `@openai/codex`, Factory Droid tramite `https://app.factory.ai/cli`, `@google/gemini-cli` o `opencode-ai`) se mancante. Il backend ACP stesso è il pacchetto `acpx/runtime` incorporato dal Plugin ufficiale `acpx`.
* La variante Docker Droid prepara `~/.factory` per le impostazioni, inoltra `FACTORY_API_KEY` e richiede quella chiave API perché l'autenticazione locale Factory OAuth/keyring non è portabile nel container. Usa la voce di registro integrata di ACPX `droid exec --output-format acp`.
* La variante Docker OpenCode è una lane di regressione rigorosa per singolo agent. Scrive un modello predefinito temporaneo `OPENCODE_CONFIG_CONTENT` da `OPENCLAW_LIVE_ACP_BIND_OPENCODE_MODEL` (predefinito `opencode/kimi-k2.6`) e `pnpm test:docker:live-acp-bind:opencode` richiede una trascrizione dell'assistant associato invece di accettare lo skip generico post-bind.
* Le chiamate CLI dirette a `acpx` sono solo un percorso manuale/di workaround per confrontare il comportamento fuori dal Gateway. Lo smoke ACP bind Docker esercita il backend runtime `acpx` incorporato in OpenClaw.

## Live: smoke dell'harness app-server Codex

* Obiettivo: convalidare l'harness Codex di proprietà del Plugin tramite il normale metodo gateway
  `agent`:
  * caricare il Plugin `codex` in bundle
  * selezionare `openai/gpt-5.5`, che instrada per impostazione predefinita i turni agent OpenAI tramite Codex
  * inviare un primo turno agent gateway a `openai/gpt-5.5` con l'harness Codex selezionato
  * inviare un secondo turno alla stessa sessione OpenClaw e verificare che il thread app-server
    possa riprendere
  * eseguire `/codex status` e `/codex models` tramite lo stesso percorso di comando gateway
  * facoltativamente eseguire due sonde shell con escalation revisionate da Guardian: un comando
    innocuo che dovrebbe essere approvato e un caricamento fake-secret che dovrebbe essere
    negato così l'agent chiede conferma
* Test: `src/gateway/gateway-codex-harness.live.test.ts`
* Abilitazione: `OPENCLAW_LIVE_CODEX_HARNESS=1`
* Modello predefinito: `openai/gpt-5.5`
* Sonda immagine facoltativa: `OPENCLAW_LIVE_CODEX_HARNESS_IMAGE_PROBE=1`
* Sonda MCP/tool facoltativa: `OPENCLAW_LIVE_CODEX_HARNESS_MCP_PROBE=1`
* Sonda Guardian facoltativa: `OPENCLAW_LIVE_CODEX_HARNESS_GUARDIAN_PROBE=1`
* Lo smoke forza provider/modello `agentRuntime.id: "codex"` così un harness Codex rotto
  non può passare tornando silenziosamente a OpenClaw.
* Autenticazione: autenticazione app-server Codex dal login locale dell'abbonamento Codex. Gli smoke Docker
  possono anche fornire `OPENAI_API_KEY` per sonde non Codex quando applicabile,
  più eventuali `~/.codex/auth.json` e `~/.codex/config.toml` copiati.

Ricetta locale:

```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}
OPENCLAW_LIVE_CODEX_HARNESS=1 \
  OPENCLAW_LIVE_CODEX_HARNESS_IMAGE_PROBE=1 \
  OPENCLAW_LIVE_CODEX_HARNESS_MCP_PROBE=1 \
  OPENCLAW_LIVE_CODEX_HARNESS_GUARDIAN_PROBE=1 \
  OPENCLAW_LIVE_CODEX_HARNESS_MODEL=openai/gpt-5.5 \
  pnpm test:live -- src/gateway/gateway-codex-harness.live.test.ts
```

Ricetta Docker:

```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}
pnpm test:docker:live-codex-harness
```

Note Docker:

* Il runner Docker si trova in `scripts/test-live-codex-harness-docker.sh`.
* Passa `OPENAI_API_KEY`, copia i file di autenticazione della CLI Codex quando presenti, installa
  `@openai/codex` in un prefisso npm montato e scrivibile, prepara l'albero sorgente, quindi esegue solo il test live dell'harness Codex.
* Docker abilita per impostazione predefinita le sonde immagine, MCP/tool e Guardian. Imposta
  `OPENCLAW_LIVE_CODEX_HARNESS_IMAGE_PROBE=0` oppure
  `OPENCLAW_LIVE_CODEX_HARNESS_MCP_PROBE=0` oppure
  `OPENCLAW_LIVE_CODEX_HARNESS_GUARDIAN_PROBE=0` quando serve un'esecuzione di debug più ristretta.
* Docker usa la stessa configurazione runtime Codex esplicita, quindi alias legacy o fallback OpenClaw
  non possono nascondere una regressione dell'harness Codex.

### Ricette live consigliate

Le allowlist ristrette ed esplicite sono le più veloci e le meno instabili:

* Singolo modello, diretto (senza gateway):
  * `OPENCLAW_LIVE_MODELS="openai/gpt-5.5" pnpm test:live src/agents/models.profiles.live.test.ts`

* Profilo diretto small-model:
  * `OPENCLAW_LIVE_MODELS=small pnpm test:live src/agents/models.profiles.live.test.ts`

* Profilo gateway small-model:
  * `OPENCLAW_LIVE_GATEWAY_MODELS=small pnpm test:live src/gateway/gateway-models.profiles.live.test.ts`

* Smoke API Ollama Cloud:
  * `OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_OLLAMA=1 OPENCLAW_LIVE_OLLAMA_BASE_URL=https://ollama.com OPENCLAW_LIVE_OLLAMA_MODEL=glm-5.1:cloud OPENCLAW_LIVE_OLLAMA_WEB_SEARCH=0 pnpm test:live -- extensions/ollama/ollama.live.test.ts`

* Singolo modello, smoke gateway:
  * `OPENCLAW_LIVE_GATEWAY_MODELS="openai/gpt-5.5" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts`

* Chiamata tool su più provider:
  * `OPENCLAW_LIVE_GATEWAY_MODELS="openai/gpt-5.5,anthropic/claude-opus-4-6,google/gemini-3-flash-preview,deepseek/deepseek-v4-flash,zai/glm-5.1,minimax/MiniMax-M3" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts`

* Smoke diretto Z.AI Coding Plan GLM-5.2:
  * `ZAI_CODING_LIVE_TEST=1 pnpm test:live src/agents/zai.live.test.ts`

* Focus Google (chiave API Gemini + Antigravity):
  * Gemini (chiave API): `OPENCLAW_LIVE_GATEWAY_MODELS="google/gemini-3-flash-preview" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts`
  * Antigravity (OAuth): `OPENCLAW_LIVE_GATEWAY_MODELS="google-antigravity/claude-opus-4-6-thinking,google-antigravity/gemini-3-pro-high" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts`

* Smoke Google adaptive thinking:
  * Predefinito dinamico Gemini 3: `pnpm openclaw qa manual --provider-mode live-frontier --model google/gemini-3.1-pro-preview --alt-model google/gemini-3.1-pro-preview --message '/think adaptive Reply exactly: GEMINI_ADAPTIVE_OK' --timeout-ms 180000`
  * Budget dinamico Gemini 2.5: `pnpm openclaw qa manual --provider-mode live-frontier --model google/gemini-2.5-flash --alt-model google/gemini-2.5-flash --message '/think adaptive Reply exactly: GEMINI25_ADAPTIVE_OK' --timeout-ms 180000`

Note:

* `google/...` usa l'API Gemini (chiave API).
* `google-antigravity/...` usa il bridge OAuth Antigravity (endpoint agent in stile Cloud Code Assist).
* `google-gemini-cli/...` usa la CLI Gemini locale sulla tua macchina (autenticazione separata + peculiarità degli strumenti).
* Gemini API rispetto a Gemini CLI:
  * API: OpenClaw chiama l'API Gemini ospitata da Google su HTTP (chiave API / autenticazione profilo); questo è ciò che la maggior parte degli utenti intende per "Gemini".
  * CLI: OpenClaw esegue una shell verso un binario locale `gemini`; ha la propria autenticazione e può comportarsi diversamente (streaming/supporto tool/disallineamento versioni).

## Live: matrice dei modelli (cosa copriamo)

Non esiste un elenco fisso di "modelli CI" (live è opt-in), ma questi sono i modelli **consigliati** da coprire regolarmente su una macchina di sviluppo con chiavi.

### Set smoke moderno (chiamata tool + immagine)

Questa è l'esecuzione dei "modelli comuni" che ci aspettiamo rimanga funzionante:

* OpenAI (non Codex): `openai/gpt-5.5`
* OpenAI ChatGPT/Codex OAuth: `openai/gpt-5.5`
* Anthropic: `anthropic/claude-opus-4-6` (o `anthropic/claude-sonnet-4-6`)
* Google (Gemini API): `google/gemini-3.1-pro-preview` e `google/gemini-3-flash-preview` (evita i modelli Gemini 2.x meno recenti)
* Google (Antigravity): `google-antigravity/claude-opus-4-6-thinking` e `google-antigravity/gemini-3-flash`
* DeepSeek: `deepseek/deepseek-v4-flash` e `deepseek/deepseek-v4-pro`
* Z.AI (GLM): `zai/glm-5.1` (API generale) o `zai/glm-5.2` (Coding Plan)
* MiniMax: `minimax/MiniMax-M3`

Esegui lo smoke gateway con tool + immagine:
`OPENCLAW_LIVE_GATEWAY_MODELS="openai/gpt-5.5,anthropic/claude-opus-4-6,google/gemini-3.1-pro-preview,google/gemini-3-flash-preview,google-antigravity/claude-opus-4-6-thinking,google-antigravity/gemini-3-flash,deepseek/deepseek-v4-flash,zai/glm-5.1,minimax/MiniMax-M3" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts`

### Baseline: chiamata tool (Read + Exec facoltativo)

Scegline almeno uno per famiglia di provider:

* OpenAI: `openai/gpt-5.5`
* Anthropic: `anthropic/claude-opus-4-6` (o `anthropic/claude-sonnet-4-6`)
* Google: `google/gemini-3-flash-preview` (o `google/gemini-3.1-pro-preview`)
* DeepSeek: `deepseek/deepseek-v4-flash`
* Z.AI (GLM): `zai/glm-5.1` (API generale) o `zai/glm-5.2` (Coding Plan)
* MiniMax: `minimax/MiniMax-M3`

Copertura aggiuntiva facoltativa (utile da avere):

* xAI: `xai/grok-4.3` (o l'ultimo disponibile)
* Mistral: `mistral/`… (scegli un modello compatibile con "tools" che hai abilitato)
* Cerebras: `cerebras/`… (se hai accesso)
* LM Studio: `lmstudio/`… (locale; la chiamata tool dipende dalla modalità API)

### Vision: invio immagine (allegato → messaggio multimodale)

Includi almeno un modello capace di immagini in `OPENCLAW_LIVE_GATEWAY_MODELS` (varianti Claude/Gemini/OpenAI compatibili con vision, ecc.) per esercitare la sonda immagine.

### Aggregatori / gateway alternativi

Se hai chiavi abilitate, supportiamo anche il testing tramite:

* OpenRouter: `openrouter/...` (centinaia di modelli; usa `openclaw models scan` per trovare candidati compatibili con tool+immagine)
* OpenCode: `opencode/...` per Zen e `opencode-go/...` per Go (autenticazione tramite `OPENCODE_API_KEY` / `OPENCODE_ZEN_API_KEY`)

Altri provider che puoi includere nella matrice live (se hai credenziali/config):

* Integrati: `openai`, `anthropic`, `google`, `google-vertex`, `google-antigravity`, `google-gemini-cli`, `zai`, `openrouter`, `opencode`, `opencode-go`, `xai`, `groq`, `cerebras`, `mistral`, `github-copilot`
* Tramite `models.providers` (endpoint personalizzati): `minimax` (cloud/API), più qualsiasi proxy compatibile con OpenAI/Anthropic (LM Studio, vLLM, LiteLLM, ecc.)

<Tip>
  Non inserire nei documenti "tutti i modelli" in modo hardcoded. L'elenco autorevole è ciò che `discoverModels(...)` restituisce sulla tua macchina più le chiavi disponibili.
</Tip>

## Credenziali (non committare mai)

I test live rilevano le credenziali nello stesso modo della CLI. Implicazioni pratiche:

* Se la CLI funziona, i test live dovrebbero trovare le stesse chiavi.

* Se un test live dice "no creds", esegui il debug nello stesso modo in cui eseguiresti il debug di `openclaw models list` / della selezione del modello.

* Profili di autenticazione per agente: `~/.openclaw/agents/<agentId>/agent/auth-profiles.json` (questo è ciò che "profile keys" significa nei test live)

* Configurazione: `~/.openclaw/openclaw.json` (o `OPENCLAW_CONFIG_PATH`)

* Directory di stato legacy: `~/.openclaw/credentials/` (copiata nella home live preparata quando presente, ma non nell'archivio principale delle chiavi profilo)

* Le esecuzioni live locali copiano per impostazione predefinita la configurazione attiva, i file `auth-profiles.json` per agente, `credentials/` legacy e le directory di autenticazione CLI esterne supportate in una home di test temporanea; le home live preparate saltano `workspace/` e `sandboxes/`, e gli override di percorso `agents.*.workspace` / `agentDir` vengono rimossi, così le sonde restano fuori dal workspace reale dell'host.

Se vuoi basarti sulle chiavi env, esportale prima dei test locali oppure usa i
runner Docker sotto con un `OPENCLAW_PROFILE_FILE` esplicito.

## Deepgram live (trascrizione audio)

* Test: `extensions/deepgram/audio.live.test.ts`
* Abilita: `DEEPGRAM_API_KEY=... DEEPGRAM_LIVE_TEST=1 pnpm test:live extensions/deepgram/audio.live.test.ts`

## Piano di coding BytePlus live

* Test: `extensions/byteplus/live.test.ts`
* Abilita: `BYTEPLUS_API_KEY=... BYTEPLUS_LIVE_TEST=1 pnpm test:live extensions/byteplus/live.test.ts`
* Override opzionale del modello: `BYTEPLUS_CODING_MODEL=ark-code-latest`

## Media workflow ComfyUI live

* Test: `extensions/comfy/comfy.live.test.ts`
* Abilita: `OPENCLAW_LIVE_TEST=1 COMFY_LIVE_TEST=1 pnpm test:live -- extensions/comfy/comfy.live.test.ts`
* Ambito:
  * Esercita i percorsi bundled di immagine, video e `music_generate` di comfy
  * Salta ogni funzionalità a meno che `plugins.entries.comfy.config.<capability>` non sia configurato
  * Utile dopo modifiche a invio del workflow comfy, polling, download o registrazione del plugin

## Generazione di immagini live

* Test: `test/image-generation.runtime.live.test.ts`
* Comando: `pnpm test:live test/image-generation.runtime.live.test.ts`
* Harness: `pnpm test:live:media image`
* Ambito:
  * Enumera ogni Plugin provider di generazione di immagini registrato
  * Usa le variabili env del provider già esportate prima delle sonde
  * Usa per impostazione predefinita chiavi API live/env prima dei profili di autenticazione archiviati, così chiavi di test obsolete in `auth-profiles.json` non mascherano le credenziali reali della shell
  * Salta i provider senza autenticazione/profilo/modello utilizzabile
  * Esegue ogni provider configurato tramite il runtime condiviso di generazione di immagini:
    * `<provider>:generate`
    * `<provider>:edit` quando il provider dichiara il supporto alla modifica
* Provider bundled attualmente coperti:
  * `deepinfra`
  * `fal`
  * `google`
  * `minimax`
  * `openai`
  * `openrouter`
  * `vydra`
  * `xai`
* Restrizione opzionale:
  * `OPENCLAW_LIVE_IMAGE_GENERATION_PROVIDERS="openai,google,openrouter,xai"`
  * `OPENCLAW_LIVE_IMAGE_GENERATION_PROVIDERS="deepinfra"`
  * `OPENCLAW_LIVE_IMAGE_GENERATION_MODELS="openai/gpt-image-2,google/gemini-3.1-flash-image-preview,openrouter/google/gemini-3.1-flash-image-preview,xai/grok-imagine-image"`
  * `OPENCLAW_LIVE_IMAGE_GENERATION_CASES="google:flash-generate,google:pro-edit,openrouter:generate,xai:default-generate,xai:default-edit"`
* Comportamento di autenticazione opzionale:
  * `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` per forzare l'autenticazione dall'archivio profili e ignorare gli override solo env

Per il percorso CLI distribuito, aggiungi uno smoke `infer` dopo che il test live
provider/runtime è passato:

```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}
OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_INFER_CLI_TEST=1 pnpm test:live -- test/image-generation.infer-cli.live.test.ts
openclaw infer image providers --json
openclaw infer image generate \
  --model google/gemini-3.1-flash-image-preview \
  --prompt "Minimal flat test image: one blue square on a white background, no text." \
  --output ./openclaw-infer-image-smoke.png \
  --json
```

Questo copre il parsing degli argomenti CLI, la risoluzione della configurazione/dell'agente predefinito, l'attivazione dei
Plugin bundled, il runtime condiviso di generazione di immagini e la richiesta live al provider.
Le dipendenze del Plugin devono essere presenti prima del caricamento del runtime.

## Generazione di musica live

* Test: `extensions/music-generation-providers.live.test.ts`
* Abilita: `OPENCLAW_LIVE_TEST=1 pnpm test:live -- extensions/music-generation-providers.live.test.ts`
* Harness: `pnpm test:live:media music`
* Ambito:
  * Esercita il percorso provider bundled condiviso di generazione di musica
  * Attualmente copre Google e MiniMax
  * Usa le variabili env del provider già esportate prima delle sonde
  * Usa per impostazione predefinita chiavi API live/env prima dei profili di autenticazione archiviati, così chiavi di test obsolete in `auth-profiles.json` non mascherano le credenziali reali della shell
  * Salta i provider senza autenticazione/profilo/modello utilizzabile
  * Esegue entrambe le modalità runtime dichiarate quando disponibili:
    * `generate` con input solo prompt
    * `edit` quando il provider dichiara `capabilities.edit.enabled`
  * Copertura attuale della lane condivisa:
    * `google`: `generate`, `edit`
    * `minimax`: `generate`
    * `comfy`: file live Comfy separato, non questo sweep condiviso
* Restrizione opzionale:
  * `OPENCLAW_LIVE_MUSIC_GENERATION_PROVIDERS="google,minimax"`
  * `OPENCLAW_LIVE_MUSIC_GENERATION_MODELS="google/lyria-3-clip-preview,minimax/music-2.6"`
* Comportamento di autenticazione opzionale:
  * `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` per forzare l'autenticazione dall'archivio profili e ignorare gli override solo env

## Generazione di video live

* Test: `extensions/video-generation-providers.live.test.ts`
* Abilita: `OPENCLAW_LIVE_TEST=1 pnpm test:live -- extensions/video-generation-providers.live.test.ts`
* Harness: `pnpm test:live:media video`
* Ambito:
  * Esercita il percorso provider bundled condiviso di generazione di video
  * Per impostazione predefinita usa il percorso smoke sicuro per la release: provider non FAL, una richiesta text-to-video per provider, prompt di un secondo con aragosta e un limite di operazione per provider da `OPENCLAW_LIVE_VIDEO_GENERATION_TIMEOUT_MS` (`180000` per impostazione predefinita)
  * Salta FAL per impostazione predefinita perché la latenza della coda lato provider può dominare il tempo di release; passa `--video-providers fal` o `OPENCLAW_LIVE_VIDEO_GENERATION_PROVIDERS="fal"` per eseguirlo esplicitamente
  * Usa le variabili env del provider già esportate prima delle sonde
  * Usa per impostazione predefinita chiavi API live/env prima dei profili di autenticazione archiviati, così chiavi di test obsolete in `auth-profiles.json` non mascherano le credenziali reali della shell
  * Salta i provider senza autenticazione/profilo/modello utilizzabile
  * Esegue solo `generate` per impostazione predefinita
  * Imposta `OPENCLAW_LIVE_VIDEO_GENERATION_FULL_MODES=1` per eseguire anche le modalità di trasformazione dichiarate quando disponibili:
    * `imageToVideo` quando il provider dichiara `capabilities.imageToVideo.enabled` e il provider/modello selezionato accetta input immagine locale basato su buffer nello sweep condiviso
    * `videoToVideo` quando il provider dichiara `capabilities.videoToVideo.enabled` e il provider/modello selezionato accetta input video locale basato su buffer nello sweep condiviso
  * Provider `imageToVideo` attualmente dichiarati ma saltati nello sweep condiviso:
    * `vydra` perché `veo3` bundled è solo testo e `kling` bundled richiede un URL immagine remoto
  * Copertura Vydra specifica del provider:
    * `OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_VYDRA_VIDEO=1 pnpm test:live -- extensions/vydra/vydra.live.test.ts`
    * quel file esegue `veo3` text-to-video più una lane `kling` che usa per impostazione predefinita una fixture con URL immagine remoto
  * Copertura live `videoToVideo` attuale:
    * solo `runway` quando il modello selezionato è `runway/gen4_aleph`
  * Provider `videoToVideo` attualmente dichiarati ma saltati nello sweep condiviso:
    * `alibaba`, `qwen`, `xai` perché quei percorsi attualmente richiedono URL di riferimento remoti `http(s)` / MP4
    * `google` perché la lane condivisa Gemini/Veo attuale usa input locale basato su buffer e quel percorso non è accettato nello sweep condiviso
    * `openai` perché alla lane condivisa attuale mancano garanzie di accesso alla modifica video specifiche per l'organizzazione
* Restrizione opzionale:
  * `OPENCLAW_LIVE_VIDEO_GENERATION_PROVIDERS="deepinfra,google,openai,runway"`
  * `OPENCLAW_LIVE_VIDEO_GENERATION_MODELS="google/veo-3.1-fast-generate-preview,openai/sora-2,runway/gen4_aleph"`
  * `OPENCLAW_LIVE_VIDEO_GENERATION_SKIP_PROVIDERS=""` per includere ogni provider nello sweep predefinito, incluso FAL
  * `OPENCLAW_LIVE_VIDEO_GENERATION_TIMEOUT_MS=60000` per ridurre il limite di operazione di ciascun provider per una smoke run aggressiva
* Comportamento di autenticazione opzionale:
  * `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` per forzare l'autenticazione dall'archivio profili e ignorare gli override solo env

## Harness media live

* Comando: `pnpm test:live:media`
* Scopo:
  * Esegue le suite live condivise di immagine, musica e video tramite un unico entrypoint nativo del repo
  * Usa le variabili env del provider già esportate
  * Restringe automaticamente ogni suite ai provider che attualmente hanno autenticazione utilizzabile per impostazione predefinita
  * Riusa `scripts/test-live.mjs`, così il comportamento di Heartbeat e modalità quiet resta coerente
* Esempi:
  * `pnpm test:live:media`
  * `pnpm test:live:media image video --providers openai,google,minimax`
  * `pnpm test:live:media video --video-providers openai,runway --all-providers`
  * `pnpm test:live:media music --quiet`

## Correlati

* [Testing](/it/help/testing) - suite unit, di integrazione, QA e Docker