chore(i18n): refresh it translations
This commit is contained in:
openclaw-docs-i18n[bot]
parent
3994689771
commit
0e5320bb19
113
docs/it/ci.md
113
docs/it/ci.md
@ -1,14 +1,14 @@
|
||||
---
|
||||
read_when:
|
||||
- Devi capire perché un job CI è stato eseguito o non è stato eseguito.
|
||||
- Stai eseguendo il debug di controlli GitHub Actions non riusciti.
|
||||
summary: Grafico dei job CI, gate di ambito e comandi locali equivalenti
|
||||
- Devi capire perché un job CI è stato eseguito oppure no
|
||||
- Stai eseguendo il debug di controlli GitHub Actions non riusciti
|
||||
summary: Grafo dei job CI, gate di ambito ed equivalenti dei comandi locali
|
||||
title: Pipeline CI
|
||||
x-i18n:
|
||||
generated_at: "2026-04-23T13:57:58Z"
|
||||
generated_at: "2026-04-23T14:55:06Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: c5a8ea0d8e428826169b0e6aced1caeb993106fe79904002125ace86b48cae1f
|
||||
source_hash: e9a03440ae28a15167fc08d9c66bb1fd719ddfa1517aaecb119c80f2ad826c0d
|
||||
source_path: ci.md
|
||||
workflow: 15
|
||||
---
|
||||
@ -17,84 +17,84 @@ x-i18n:
|
||||
|
||||
La CI viene eseguita a ogni push su `main` e a ogni pull request. Usa uno scoping intelligente per saltare i job costosi quando sono cambiate solo aree non correlate.
|
||||
|
||||
QA Lab ha lane CI dedicate al di fuori del workflow principale con smart scope. Il
|
||||
workflow `Parity gate` viene eseguito su modifiche PR corrispondenti e tramite invio manuale; esso
|
||||
compila il runtime QA privato e confronta i pacchetti agentici mock GPT-5.4 e Opus 4.6.
|
||||
QA Lab ha corsie CI dedicate al di fuori del workflow principale con scoping intelligente. Il
|
||||
workflow `Parity gate` viene eseguito sulle modifiche PR corrispondenti e tramite dispatch manuale; esso
|
||||
compila il runtime QA privato e confronta i pack agentici mock GPT-5.4 e Opus 4.6.
|
||||
Il workflow `QA-Lab - All Lanes` viene eseguito ogni notte su `main` e tramite
|
||||
invio manuale; distribuisce in parallelo il mock parity gate, la lane live Matrix e la lane live
|
||||
Telegram come job paralleli. I job live usano l'ambiente `qa-live-shared`,
|
||||
e la lane Telegram usa lease Convex. Anche `OpenClaw Release
|
||||
Checks` esegue le stesse lane QA Lab prima dell'approvazione della release.
|
||||
dispatch manuale; distribuisce in parallelo il mock parity gate, la corsia Matrix live e la corsia
|
||||
Telegram live come job paralleli. I job live usano l'ambiente `qa-live-shared`,
|
||||
e la corsia Telegram usa lease Convex. Anche `OpenClaw Release
|
||||
Checks` esegue le stesse corsie QA Lab prima dell'approvazione della release.
|
||||
|
||||
## Panoramica dei job
|
||||
|
||||
| Job | Scopo | Quando viene eseguito |
|
||||
| -------------------------------- | -------------------------------------------------------------------------------------------- | ------------------------------------ |
|
||||
| `preflight` | Rileva modifiche solo-docs, scope modificati, extension modificate e costruisce il manifest CI | Sempre su push e PR non draft |
|
||||
| `security-scm-fast` | Rilevamento di chiavi private e audit del workflow tramite `zizmor` | Sempre su push e PR non draft |
|
||||
| `preflight` | Rileva modifiche solo alla documentazione, scope cambiati, estensioni cambiate e compila il manifest CI | Sempre su push e PR non draft |
|
||||
| `security-scm-fast` | Rilevamento di chiavi private e audit dei workflow tramite `zizmor` | Sempre su push e PR non draft |
|
||||
| `security-dependency-audit` | Audit del lockfile di produzione senza dipendenze rispetto agli advisory npm | Sempre su push e PR non draft |
|
||||
| `security-fast` | Aggregato richiesto per i job di sicurezza rapidi | Sempre su push e PR non draft |
|
||||
| `build-artifacts` | Compila `dist/`, Control UI, controlli degli artifact compilati e artifact riutilizzabili downstream | Modifiche rilevanti per Node |
|
||||
| `checks-fast-core` | Lane rapide di correttezza Linux come controlli bundled/plugin-contract/protocol | Modifiche rilevanti per Node |
|
||||
| `checks-fast-contracts-channels` | Controlli sharded dei contratti dei canali con un risultato di check aggregato stabile | Modifiche rilevanti per Node |
|
||||
| `checks-node-extensions` | Shard completi di test dei bundled plugin sull'intera suite extension | Modifiche rilevanti per Node |
|
||||
| `checks-node-core-test` | Shard di test core Node, escluse le lane di canale, bundled, contratti ed extension | Modifiche rilevanti per Node |
|
||||
| `extension-fast` | Test mirati solo per i bundled plugin modificati | Pull request con modifiche alle extension |
|
||||
| `check` | Equivalente locale principale sharded del gate: tipi prod, lint, guard, tipi di test e smoke rigoroso | Modifiche rilevanti per Node |
|
||||
| `check-additional` | Guard di architettura, boundary, superficie extension, package-boundary e shard gateway-watch | Modifiche rilevanti per Node |
|
||||
| `build-smoke` | Smoke test della CLI compilata e smoke sulla memoria di avvio | Modifiche rilevanti per Node |
|
||||
| `checks` | Verificatore per test dei canali sugli artifact compilati più compatibilità Node 22 solo push | Modifiche rilevanti per Node |
|
||||
| `check-docs` | Controlli di formattazione docs, lint e link non validi | Docs modificate |
|
||||
| `skills-python` | Ruff + pytest per Skills basate su Python | Modifiche rilevanti per Skills Python |
|
||||
| `checks-windows` | Lane di test specifiche per Windows | Modifiche rilevanti per Windows |
|
||||
| `macos-node` | Lane di test TypeScript macOS che usa gli artifact compilati condivisi | Modifiche rilevanti per macOS |
|
||||
| `checks-fast-core` | Corsie rapide di correttezza Linux, come controlli bundled/plugin-contract/protocol | Modifiche rilevanti per Node |
|
||||
| `checks-fast-contracts-channels` | Controlli shardizzati dei contratti dei canali con un risultato di controllo aggregato stabile | Modifiche rilevanti per Node |
|
||||
| `checks-node-extensions` | Shard completi dei test dei plugin bundled nell'intera suite delle estensioni | Modifiche rilevanti per Node |
|
||||
| `checks-node-core-test` | Shard dei test core Node, escluse le corsie per canali, bundled, contratti ed estensioni | Modifiche rilevanti per Node |
|
||||
| `extension-fast` | Test mirati solo per i plugin bundled modificati | Pull request con modifiche alle estensioni |
|
||||
| `check` | Equivalente locale principale shardizzato: tipi prod, lint, guard, tipi di test e smoke rigoroso | Modifiche rilevanti per Node |
|
||||
| `check-additional` | Guard di architettura, boundary, surface delle estensioni, boundary dei package e shard gateway-watch | Modifiche rilevanti per Node |
|
||||
| `build-smoke` | Test smoke della CLI compilata e smoke sulla memoria all'avvio | Modifiche rilevanti per Node |
|
||||
| `checks` | Verificatore per i test dei canali sugli artifact compilati più compatibilità Node 22 solo su push | Modifiche rilevanti per Node |
|
||||
| `check-docs` | Controlli di formattazione docs, lint e link interrotti | Documentazione modificata |
|
||||
| `skills-python` | Ruff + pytest per Skills basate su Python | Modifiche rilevanti per skill Python |
|
||||
| `checks-windows` | Corsie di test specifiche per Windows | Modifiche rilevanti per Windows |
|
||||
| `macos-node` | Corsia di test TypeScript su macOS usando gli artifact compilati condivisi | Modifiche rilevanti per macOS |
|
||||
| `macos-swift` | Lint, build e test Swift per l'app macOS | Modifiche rilevanti per macOS |
|
||||
| `android` | Test unitari Android per entrambe le varianti più una build APK debug | Modifiche rilevanti per Android |
|
||||
|
||||
## Ordine fail-fast
|
||||
|
||||
I job sono ordinati in modo che i controlli economici falliscano prima che vengano eseguiti quelli costosi:
|
||||
I job sono ordinati in modo che i controlli economici falliscano prima che partano quelli costosi:
|
||||
|
||||
1. `preflight` decide quali lane esistono effettivamente. La logica `docs-scope` e `changed-scope` è composta da step interni a questo job, non da job autonomi.
|
||||
2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs` e `skills-python` falliscono rapidamente senza attendere i job più pesanti della matrice artifact e piattaforme.
|
||||
3. `build-artifacts` si sovrappone alle lane Linux rapide così i consumer downstream possono iniziare non appena la build condivisa è pronta.
|
||||
4. Successivamente si distribuiscono le lane più pesanti di piattaforma e runtime: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-extensions`, `checks-node-core-test`, `extension-fast` solo PR, `checks`, `checks-windows`, `macos-node`, `macos-swift` e `android`.
|
||||
1. `preflight` decide quali corsie esistono del tutto. La logica `docs-scope` e `changed-scope` è composta da step all'interno di questo job, non da job separati.
|
||||
2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs` e `skills-python` falliscono rapidamente senza aspettare i job più pesanti della matrice artifact e piattaforme.
|
||||
3. `build-artifacts` si sovrappone alle corsie Linux rapide così i consumer downstream possono iniziare non appena la build condivisa è pronta.
|
||||
4. Successivamente si distribuiscono le corsie più pesanti di piattaforma e runtime: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-extensions`, `checks-node-core-test`, `extension-fast` solo PR, `checks`, `checks-windows`, `macos-node`, `macos-swift` e `android`.
|
||||
|
||||
La logica di scope si trova in `scripts/ci-changed-scope.mjs` ed è coperta da unit test in `src/scripts/ci-changed-scope.test.ts`.
|
||||
Le modifiche ai workflow CI convalidano il grafo CI Node più il lint dei workflow, ma non forzano da sole build native Windows, Android o macOS; quelle lane di piattaforma restano limitate alle modifiche del codice sorgente della piattaforma.
|
||||
I controlli Node Windows sono limitati a wrapper specifici di processo/percorso Windows, helper npm/pnpm/UI runner, configurazione del package manager e superfici del workflow CI che eseguono quella lane; modifiche non correlate a sorgente, plugin, install-smoke e solo test restano sulle lane Linux Node, così non riservano un worker Windows da 16 vCPU per copertura già esercitata dai normali shard di test.
|
||||
Il workflow separato `install-smoke` riusa lo stesso script di scope tramite il proprio job `preflight`. Calcola `run_install_smoke` a partire dal segnale changed-smoke più ristretto, quindi lo smoke Docker/install viene eseguito per modifiche rilevanti a installazione, packaging, container, produzione delle bundled extension e alle superfici core plugin/channel/gateway/Plugin SDK che i job Docker smoke esercitano. Le modifiche solo test e solo docs non riservano worker Docker. Il suo QR package smoke forza il layer Docker `pnpm install` a essere rieseguito preservando la cache BuildKit dello store pnpm, così esercita comunque l'installazione senza riscaricare le dipendenze a ogni esecuzione. Il suo gateway-network e2e riusa l'immagine runtime compilata in precedenza nel job, quindi aggiunge copertura WebSocket reale da container a container senza aggiungere un'altra build Docker. L'aggregato locale `test:docker:all` precompila un'unica immagine live-test condivisa e un'unica immagine built-app condivisa `scripts/e2e/Dockerfile`, poi esegue in parallelo le lane smoke live/E2E con `OPENCLAW_SKIP_DOCKER_BUILD=1`; regola la concorrenza predefinita di 4 con `OPENCLAW_DOCKER_ALL_PARALLELISM`. L'aggregato locale, per impostazione predefinita, smette di pianificare nuove lane nel pool dopo il primo errore e ogni lane ha un timeout di 120 minuti, modificabile con `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS`. Le lane sensibili all'avvio o al provider vengono eseguite in esclusiva dopo il pool parallelo. Il workflow live/E2E riutilizzabile rispecchia il pattern a immagine condivisa compilando e pubblicando una singola immagine Docker E2E GHCR con tag SHA prima della matrice Docker, quindi eseguendo la matrice con `OPENCLAW_SKIP_DOCKER_BUILD=1`. Il workflow live/E2E pianificato esegue quotidianamente l'intera suite Docker del percorso di release. I test Docker di QR e installer mantengono i propri Dockerfile focalizzati sull'installazione. Un job separato `docker-e2e-fast` esegue il profilo Docker bounded bundled-plugin con un timeout del comando di 120 secondi: riparazione delle dipendenze setup-entry più isolamento sintetico dei guasti del bundled-loader. La matrice completa bundled update/channel resta manuale/full-suite perché esegue ripetuti passaggi reali di npm update e doctor repair.
|
||||
Le modifiche ai workflow CI validano il grafo CI Node più il lint dei workflow, ma non impongono da sole build native Windows, Android o macOS; quelle corsie di piattaforma restano limitate alle modifiche del codice sorgente della relativa piattaforma.
|
||||
I controlli Node per Windows sono limitati a wrapper specifici di processo/path di Windows, helper runner npm/pnpm/UI, configurazione del package manager e surface dei workflow CI che eseguono quella corsia; modifiche non correlate a sorgente, plugin, install-smoke e solo test restano sulle corsie Linux Node, così non riservano un worker Windows da 16 vCPU per una copertura già esercitata dagli shard di test normali.
|
||||
Il workflow separato `install-smoke` riusa lo stesso script di scope tramite il proprio job `preflight`. Calcola `run_install_smoke` dal segnale changed-smoke più ristretto, quindi Docker/install smoke viene eseguito per modifiche rilevanti per installazione, packaging, container, modifiche di produzione alle estensioni bundled e le surface core plugin/channel/gateway/Plugin SDK esercitate dai job Docker smoke. Le modifiche solo test e solo documentazione non riservano worker Docker. Il suo smoke del pacchetto QR forza il layer Docker `pnpm install` a essere rieseguito preservando però la cache BuildKit del pnpm store, quindi esercita comunque l'installazione senza riscaricare le dipendenze a ogni esecuzione. Il suo gateway-network e2e riusa l'immagine runtime compilata in precedenza nel job, quindi aggiunge copertura WebSocket reale container-to-container senza aggiungere un'altra build Docker. In locale, `test:docker:all` precompila un'unica immagine live-test condivisa e un'unica immagine built-app condivisa da `scripts/e2e/Dockerfile`, poi esegue in parallelo le corsie smoke live/E2E con `OPENCLAW_SKIP_DOCKER_BUILD=1`; regola il parallelismo predefinito di 4 con `OPENCLAW_DOCKER_ALL_PARALLELISM`. L'aggregato locale smette per impostazione predefinita di pianificare nuove corsie in pool dopo il primo errore, e ogni corsia ha un timeout di 120 minuti sovrascrivibile con `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS`. Le corsie sensibili all'avvio o al provider vengono eseguite in esclusiva dopo il pool parallelo. Il workflow live/E2E riutilizzabile rispecchia il pattern dell'immagine condivisa compilando e pubblicando un'unica immagine Docker E2E GHCR con tag SHA prima della matrice Docker, quindi eseguendo la matrice con `OPENCLAW_SKIP_DOCKER_BUILD=1`. Il workflow live/E2E schedulato esegue quotidianamente l'intera suite Docker del percorso di release. I test Docker QR e installer mantengono i propri Dockerfile focalizzati sull'installazione. Un job separato `docker-e2e-fast` esegue il profilo Docker bounded bundled-plugin con un timeout di 120 secondi per comando: riparazione delle dipendenze setup-entry più isolamento sintetico dei guasti del bundled-loader. La matrice completa bundled update/channel resta manuale/full-suite perché esegue passaggi ripetuti reali di npm update e doctor repair.
|
||||
|
||||
La logica locale delle lane modificate si trova in `scripts/changed-lanes.mjs` ed è eseguita da `scripts/check-changed.mjs`. Quel gate locale è più rigoroso sui boundary architetturali rispetto all'ampio scope CI di piattaforma: le modifiche di produzione core eseguono typecheck prod core più test core, le modifiche solo test core eseguono solo typecheck/test core di test, le modifiche di produzione extension eseguono typecheck prod extension più test extension, e le modifiche solo test extension eseguono solo typecheck/test extension di test. Le modifiche al Plugin SDK pubblico o al plugin-contract estendono la validazione alle extension perché le extension dipendono da quei contratti core. I version bump solo metadata di release eseguono controlli mirati di versione/config/dipendenze root. Le modifiche root/config sconosciute fanno fail safe su tutte le lane.
|
||||
La logica locale delle corsie modificate si trova in `scripts/changed-lanes.mjs` ed è eseguita da `scripts/check-changed.mjs`. Questo gate locale è più rigoroso sui boundary architetturali rispetto all'ampio scope CI di piattaforma: le modifiche di produzione core eseguono typecheck prod core più test core, le modifiche solo ai test core eseguono solo typecheck/test core di test, le modifiche di produzione alle estensioni eseguono typecheck prod delle estensioni più test delle estensioni, e le modifiche solo ai test delle estensioni eseguono solo typecheck/test delle estensioni di test. Le modifiche al Plugin SDK pubblico o al plugin-contract estendono la validazione alle estensioni perché le estensioni dipendono da quei contratti core. Gli incrementi di versione limitati ai soli metadati di release eseguono controlli mirati di versione/config/dipendenze root. Le modifiche sconosciute a root/config falliscono in modo sicuro su tutte le corsie.
|
||||
|
||||
Sui push, la matrice `checks` aggiunge la lane `compat-node22` solo push. Sulle pull request, quella lane viene saltata e la matrice resta focalizzata sulle normali lane di test/canale.
|
||||
Sui push, la matrice `checks` aggiunge la corsia `compat-node22` solo push. Sulle pull request, quella corsia viene saltata e la matrice resta focalizzata sulle normali corsie di test/canali.
|
||||
|
||||
Le famiglie di test Node più lente sono divise o bilanciate in modo che ogni job resti piccolo: i contratti dei canali dividono la copertura registry e core in sei shard pesati totali, i test dei bundled plugin sono bilanciati su sei worker extension, auto-reply viene eseguito come tre worker bilanciati invece di sei piccoli worker, e le configurazioni agentic gateway/plugin sono distribuite sui job Node agentic esistenti solo-sorgente invece di attendere gli artifact compilati. I test ampi browser, QA, media e plugin vari usano le loro configurazioni Vitest dedicate invece del catch-all condiviso per i plugin. La lane agents ampia usa lo scheduler condiviso di parallelismo per file di Vitest perché è dominata da import/scheduling piuttosto che da un singolo file di test lento. `runtime-config` viene eseguito con lo shard infra core-runtime per evitare che lo shard runtime condiviso possieda la coda finale. `check-additional` tiene insieme il lavoro compile/canary di package-boundary e separa l'architettura della topologia runtime dalla copertura gateway watch; lo shard boundary guard esegue i suoi piccoli guard indipendenti in parallelo all'interno di un unico job. Gateway watch, test dei canali e lo shard core support-boundary vengono eseguiti in parallelo all'interno di `build-artifacts` dopo che `dist/` e `dist-runtime/` sono già stati compilati, mantenendo i loro vecchi nomi di check come job verificatori leggeri ed evitando due worker Blacksmith aggiuntivi e una seconda coda di consumer degli artifact.
|
||||
La CI Android esegue sia `testPlayDebugUnitTest` sia `testThirdPartyDebugUnitTest`, quindi compila l'APK debug Play. La variante third-party non ha un source set o manifest separato; la sua lane di unit test compila comunque quella variante con i flag BuildConfig SMS/call-log, evitando però un job duplicato di packaging APK debug a ogni push rilevante per Android.
|
||||
`extension-fast` è solo PR perché le esecuzioni push eseguono già gli shard completi dei bundled plugin. Questo mantiene il feedback sui plugin modificati per le review senza riservare un worker Blacksmith aggiuntivo su `main` per una copertura già presente in `checks-node-extensions`.
|
||||
Le famiglie di test Node più lente sono suddivise o bilanciate in modo che ogni job resti piccolo senza riservare runner in eccesso: i contratti dei canali vengono eseguiti come tre shard pesati, i test dei plugin bundled vengono bilanciati su sei worker di estensione, le piccole corsie unitarie core sono abbinate, auto-reply viene eseguito su tre worker bilanciati invece di sei worker minuscoli, e le configurazioni agentiche gateway/plugin sono distribuite sui job Node agentici solo-sorgente esistenti invece di aspettare gli artifact compilati. I test estesi di browser, QA, media e plugin vari usano le loro configurazioni Vitest dedicate invece del catch-all condiviso dei plugin. L'ampia corsia agents usa lo scheduler shared Vitest file-parallel perché è dominata da import/scheduling piuttosto che da un singolo file di test lento. `runtime-config` viene eseguito con lo shard infra core-runtime per evitare che lo shard runtime condiviso possieda la coda finale. `check-additional` mantiene insieme il lavoro compile/canary dei package-boundary e separa l'architettura della topologia runtime dalla copertura gateway watch; lo shard boundary guard esegue in concorrenza i suoi piccoli guard indipendenti all'interno di un unico job. Gateway watch, test dei canali e lo shard core support-boundary vengono eseguiti in concorrenza all'interno di `build-artifacts` dopo che `dist/` e `dist-runtime/` sono già stati compilati, mantenendo i loro vecchi nomi di check come job verificatori leggeri, evitando però due worker Blacksmith aggiuntivi e una seconda coda di consumer degli artifact.
|
||||
La CI Android esegue sia `testPlayDebugUnitTest` sia `testThirdPartyDebugUnitTest`, poi compila l'APK debug Play. La variante third-party non ha un source set o manifest separato; la sua corsia di test unitari compila comunque quella variante con i flag SMS/call-log di BuildConfig, evitando però un job duplicato di packaging dell'APK debug a ogni push rilevante per Android.
|
||||
`extension-fast` è solo PR perché le esecuzioni su push eseguono già gli shard completi dei plugin bundled. Questo mantiene un feedback rapido sui plugin modificati per le review senza riservare un worker Blacksmith aggiuntivo su `main` per una copertura già presente in `checks-node-extensions`.
|
||||
|
||||
GitHub può contrassegnare come `cancelled` i job superati quando arriva un push più recente sullo stesso ref PR o `main`. Consideralo rumore della CI, a meno che anche l'esecuzione più recente per lo stesso ref non stia fallendo. I check shard aggregati usano `!cancelled() && always()` così riportano comunque i normali errori degli shard, ma non si mettono in coda dopo che l'intero workflow è già stato superato.
|
||||
La chiave di concorrenza CI è versionata (`CI-v7-*`) così uno zombie lato GitHub in un vecchio gruppo di coda non può bloccare indefinitamente le esecuzioni più recenti su main.
|
||||
GitHub può contrassegnare i job sostituiti come `cancelled` quando arriva un push più recente sullo stesso ref PR o `main`. Consideralo rumore della CI a meno che anche l'esecuzione più recente per lo stesso ref non stia fallendo. I check shard aggregati usano `!cancelled() && always()` così riportano comunque i normali errori degli shard ma non si mettono in coda dopo che l'intero workflow è già stato sostituito.
|
||||
La chiave di concorrenza CI è versionata (`CI-v7-*`) così uno zombie lato GitHub in un vecchio gruppo di coda non può bloccare indefinitamente le nuove esecuzioni su main.
|
||||
|
||||
## Runner
|
||||
|
||||
| Runner | Job |
|
||||
| -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| `ubuntu-24.04` | `preflight`, job e aggregati di sicurezza rapidi (`security-scm-fast`, `security-dependency-audit`, `security-fast`), controlli rapidi protocol/contract/bundled, controlli sharded dei contratti dei canali, shard `check` tranne lint, shard e aggregati `check-additional`, verificatori aggregati dei test Node, controlli docs, Skills Python, workflow-sanity, labeler, auto-response; anche il preflight install-smoke usa Ubuntu ospitato da GitHub così la matrice Blacksmith può mettersi in coda prima |
|
||||
| `blacksmith-8vcpu-ubuntu-2404` | `build-artifacts`, build-smoke, shard di test Linux Node, shard di test dei bundled plugin, `android` |
|
||||
| `blacksmith-16vcpu-ubuntu-2404` | `check-lint`, che resta abbastanza sensibile alla CPU da far costare di più 8 vCPU rispetto a quanto facesse risparmiare; build Docker install-smoke, dove il tempo di coda a 32 vCPU costava più di quanto facesse risparmiare |
|
||||
| `blacksmith-16vcpu-windows-2025` | `checks-windows` |
|
||||
| `blacksmith-6vcpu-macos-latest` | `macos-node` su `openclaw/openclaw`; i fork fanno fallback a `macos-latest` |
|
||||
| `blacksmith-12vcpu-macos-latest` | `macos-swift` su `openclaw/openclaw`; i fork fanno fallback a `macos-latest` |
|
||||
| Runner | Job |
|
||||
| -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `ubuntu-24.04` | `preflight`, job di sicurezza rapidi e aggregati (`security-scm-fast`, `security-dependency-audit`, `security-fast`), controlli rapidi protocol/contract/bundled, controlli shardizzati dei contratti dei canali, shard `check` tranne lint, shard e aggregati `check-additional`, verificatori aggregati dei test Node, controlli della documentazione, Skills Python, workflow-sanity, labeler, auto-response; anche il preflight di install-smoke usa Ubuntu ospitato da GitHub così la matrice Blacksmith può mettersi in coda prima |
|
||||
| `blacksmith-8vcpu-ubuntu-2404` | `build-artifacts`, build-smoke, shard dei test Linux Node, shard dei test dei plugin bundled, `android` |
|
||||
| `blacksmith-16vcpu-ubuntu-2404` | `check-lint`, che resta abbastanza sensibile alla CPU da far costare di più 8 vCPU rispetto a quanto facevano risparmiare; build Docker di install-smoke, dove il tempo di coda di 32 vCPU costava più di quanto faceva risparmiare |
|
||||
| `blacksmith-16vcpu-windows-2025` | `checks-windows` |
|
||||
| `blacksmith-6vcpu-macos-latest` | `macos-node` su `openclaw/openclaw`; i fork ricadono su `macos-latest` |
|
||||
| `blacksmith-12vcpu-macos-latest` | `macos-swift` su `openclaw/openclaw`; i fork ricadono su `macos-latest` |
|
||||
|
||||
## Equivalenti locali
|
||||
|
||||
```bash
|
||||
pnpm changed:lanes # ispeziona il classificatore locale delle lane modificate per origin/main...HEAD
|
||||
pnpm check:changed # gate locale intelligente: typecheck/lint/test modificati per lane di boundary
|
||||
pnpm check # gate locale rapido: tsgo di produzione + lint sharded + guard rapidi in parallelo
|
||||
pnpm changed:lanes # ispeziona il classificatore locale delle corsie modificate per origin/main...HEAD
|
||||
pnpm check:changed # gate locale intelligente: typecheck/lint/test modificati per corsia di boundary
|
||||
pnpm check # gate locale rapido: tsgo di produzione + lint shardizzato + guard rapidi in parallelo
|
||||
pnpm check:test-types
|
||||
pnpm check:timed # stesso gate con tempistiche per fase
|
||||
pnpm check:timed # stesso gate con temporizzazioni per fase
|
||||
pnpm build:strict-smoke
|
||||
pnpm check:architecture
|
||||
pnpm test:gateway:watch-regression
|
||||
@ -102,6 +102,7 @@ pnpm test # test vitest
|
||||
pnpm test:channels
|
||||
pnpm test:contracts:channels
|
||||
pnpm check:docs # formato docs + lint + link interrotti
|
||||
pnpm build # compila dist quando le lane CI artifact/build-smoke sono rilevanti
|
||||
node scripts/ci-run-timings.mjs <run-id> # riassume il tempo totale, il tempo di coda e i job più lenti
|
||||
pnpm build # compila dist quando contano le corsie CI artifact/build-smoke
|
||||
node scripts/ci-run-timings.mjs <run-id> # riepiloga wall time, tempo di coda e job più lenti
|
||||
node scripts/ci-run-timings.mjs --recent 10 # confronta le recenti esecuzioni CI riuscite su main
|
||||
```
|
||||
|
||||
@ -1,45 +1,45 @@
|
||||
---
|
||||
read_when:
|
||||
- Debug dell'autenticazione del modello o della scadenza di OAuth
|
||||
- Documentazione dell'autenticazione o dell'archiviazione delle credenziali
|
||||
summary: 'Autenticazione dei modelli: OAuth, chiavi API, riutilizzo di Claude CLI e setup-token di Anthropic'
|
||||
- Documentare l'autenticazione o l'archiviazione delle credenziali
|
||||
summary: 'Autenticazione del modello: OAuth, chiavi API, riutilizzo della CLI di Claude e token di configurazione di Anthropic'
|
||||
title: Autenticazione
|
||||
x-i18n:
|
||||
generated_at: "2026-04-07T08:12:42Z"
|
||||
generated_at: "2026-04-23T14:55:08Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: 9db0ad9eccd7e3e3ca328adaad260bc4288a8ccdbe2dc0c24d9fd049b7ab9231
|
||||
source_hash: 37a7c20872b915d1d079f0578c933e43cbdb97eca1c60d8c4e6e5137ca83f8b2
|
||||
source_path: gateway/authentication.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
# Autenticazione (provider di modelli)
|
||||
# Autenticazione (Provider di modelli)
|
||||
|
||||
<Note>
|
||||
Questa pagina copre l'autenticazione dei **provider di modelli** (chiavi API, OAuth, riutilizzo di Claude CLI e setup-token di Anthropic). Per l'autenticazione della **connessione gateway** (token, password, trusted-proxy), vedi [Configurazione](/it/gateway/configuration) e [Trusted Proxy Auth](/it/gateway/trusted-proxy-auth).
|
||||
Questa pagina copre l'autenticazione dei **provider di modelli** (chiavi API, OAuth, riutilizzo della CLI di Claude e token di configurazione di Anthropic). Per l'autenticazione della **connessione Gateway** (token, password, trusted-proxy), vedi [Configurazione](/it/gateway/configuration) e [Autenticazione Trusted Proxy](/it/gateway/trusted-proxy-auth).
|
||||
</Note>
|
||||
|
||||
OpenClaw supporta OAuth e chiavi API per i provider di modelli. Per host gateway sempre attivi, le chiavi API sono in genere l'opzione più prevedibile. Sono supportati anche i flussi di sottoscrizione/OAuth quando corrispondono al modello di account del provider.
|
||||
OpenClaw supporta OAuth e le chiavi API per i provider di modelli. Per host Gateway sempre attivi, le chiavi API sono di solito l'opzione più prevedibile. Anche i flussi subscription/OAuth sono supportati quando corrispondono al modello di account del tuo provider.
|
||||
|
||||
Vedi [/concepts/oauth](/it/concepts/oauth) per il flusso OAuth completo e il layout di archiviazione.
|
||||
Per l'autenticazione basata su SecretRef (provider `env`/`file`/`exec`), vedi [Gestione dei segreti](/it/gateway/secrets).
|
||||
Per le regole di idoneità delle credenziali e dei codici motivo usate da `models status --probe`, vedi [Semantica delle credenziali di autenticazione](/it/auth-credential-semantics).
|
||||
Per le regole di idoneità delle credenziali/codici motivo usate da `models status --probe`, vedi [Semantica delle credenziali di autenticazione](/it/auth-credential-semantics).
|
||||
|
||||
## Configurazione consigliata (chiave API, qualsiasi provider)
|
||||
|
||||
Se stai eseguendo un gateway di lunga durata, inizia con una chiave API per il provider scelto.
|
||||
Per Anthropic in particolare, l'autenticazione con chiave API resta la configurazione server più prevedibile, ma OpenClaw supporta anche il riutilizzo di un accesso locale a Claude CLI.
|
||||
Se stai eseguendo un Gateway di lunga durata, inizia con una chiave API per il provider scelto.
|
||||
Per Anthropic in particolare, l'autenticazione con chiave API rimane la configurazione server più prevedibile, ma OpenClaw supporta anche il riutilizzo di un accesso locale alla CLI di Claude.
|
||||
|
||||
1. Crea una chiave API nella console del tuo provider.
|
||||
2. Inseriscila sull'**host gateway** (la macchina che esegue `openclaw gateway`).
|
||||
2. Inseriscila sull'**host Gateway** (la macchina che esegue `openclaw gateway`).
|
||||
|
||||
```bash
|
||||
export <PROVIDER>_API_KEY="..."
|
||||
openclaw models status
|
||||
```
|
||||
|
||||
3. Se il Gateway viene eseguito sotto systemd/launchd, è preferibile inserire la chiave in
|
||||
`~/.openclaw/.env` in modo che il demone possa leggerla:
|
||||
3. Se il Gateway viene eseguito sotto systemd/launchd, preferisci inserire la chiave in
|
||||
`~/.openclaw/.env` così il demone può leggerla:
|
||||
|
||||
```bash
|
||||
cat >> ~/.openclaw/.env <<'EOF'
|
||||
@ -47,39 +47,56 @@ cat >> ~/.openclaw/.env <<'EOF'
|
||||
EOF
|
||||
```
|
||||
|
||||
Poi riavvia il demone (oppure riavvia il tuo processo Gateway) e ricontrolla:
|
||||
Poi riavvia il demone (o riavvia il processo Gateway) e ricontrolla:
|
||||
|
||||
```bash
|
||||
openclaw models status
|
||||
openclaw doctor
|
||||
```
|
||||
|
||||
Se preferisci non gestire tu stesso le variabili d'ambiente, l'onboarding può archiviare
|
||||
le chiavi API per l'uso da parte del demone: `openclaw onboard`.
|
||||
Se preferisci non gestire tu stesso le variabili env, l'onboarding può archiviare
|
||||
le chiavi API per l'uso del demone: `openclaw onboard`.
|
||||
|
||||
Vedi [Guida](/it/help) per i dettagli sull'ereditarietà dell'ambiente (`env.shellEnv`,
|
||||
Vedi [Aiuto](/it/help) per i dettagli sull'ereditarietà env (`env.shellEnv`,
|
||||
`~/.openclaw/.env`, systemd/launchd).
|
||||
|
||||
## Anthropic: compatibilità tra Claude CLI e token
|
||||
## Anthropic: compatibilità tra CLI di Claude e token
|
||||
|
||||
L'autenticazione Anthropic setup-token è ancora disponibile in OpenClaw come percorso token supportato. Da allora, il personale Anthropic ci ha comunicato che l'uso di Claude CLI in stile OpenClaw è nuovamente consentito, quindi OpenClaw considera il riutilizzo di Claude CLI e l'uso di `claude -p` come autorizzati per questa integrazione, a meno che Anthropic non pubblichi una nuova policy. Quando il riutilizzo di Claude CLI è disponibile sull'host, questo è ora il percorso preferito.
|
||||
L'autenticazione con token di configurazione Anthropic è ancora disponibile in OpenClaw come percorso token supportato. Da allora, lo staff di Anthropic ci ha detto che l'uso della CLI di Claude nello stile di OpenClaw è di nuovo consentito, quindi OpenClaw considera il riutilizzo della CLI di Claude e l'uso di `claude -p` come autorizzati per questa integrazione, a meno che Anthropic non pubblichi una nuova policy. Quando il riutilizzo della CLI di Claude è disponibile sull'host, questo è ora il percorso preferito.
|
||||
|
||||
Per host gateway di lunga durata, una chiave API Anthropic resta comunque la configurazione più prevedibile.
|
||||
Se vuoi riutilizzare un accesso Claude esistente sullo stesso host, usa il percorso Anthropic Claude CLI in onboarding/configure.
|
||||
Per host Gateway di lunga durata, una chiave API Anthropic rimane comunque la configurazione più prevedibile. Se vuoi riutilizzare un login Claude esistente sullo stesso host, usa il percorso Anthropic Claude CLI in onboarding/configure.
|
||||
|
||||
Inserimento manuale del token (qualsiasi provider; scrive `auth-profiles.json` e aggiorna la configurazione):
|
||||
Configurazione host consigliata per il riutilizzo della CLI di Claude:
|
||||
|
||||
```bash
|
||||
# Esegui sull'host Gateway
|
||||
claude auth login
|
||||
claude auth status --text
|
||||
openclaw models auth login --provider anthropic --method cli --set-default
|
||||
```
|
||||
|
||||
Questa è una configurazione in due passaggi:
|
||||
|
||||
1. Fai accedere Claude Code stesso ad Anthropic sull'host Gateway.
|
||||
2. Indica a OpenClaw di passare la selezione del modello Anthropic al backend locale `claude-cli`
|
||||
e di archiviare il profilo di autenticazione OpenClaw corrispondente.
|
||||
|
||||
Se `claude` non è in `PATH`, installa prima Claude Code oppure imposta
|
||||
`agents.defaults.cliBackends.claude-cli.command` sul percorso reale del binario.
|
||||
|
||||
Inserimento manuale del token (qualsiasi provider; scrive `auth-profiles.json` + aggiorna la configurazione):
|
||||
|
||||
```bash
|
||||
openclaw models auth paste-token --provider openrouter
|
||||
```
|
||||
|
||||
Sono supportati anche riferimenti a profili auth per credenziali statiche:
|
||||
Sono supportati anche i riferimenti ai profili di autenticazione per credenziali statiche:
|
||||
|
||||
- le credenziali `api_key` possono usare `keyRef: { source, provider, id }`
|
||||
- le credenziali `token` possono usare `tokenRef: { source, provider, id }`
|
||||
- i profili in modalità OAuth non supportano credenziali SecretRef; se `auth.profiles.<id>.mode` è impostato su `"oauth"`, l'input `keyRef`/`tokenRef` supportato da SecretRef per quel profilo viene rifiutato.
|
||||
- i profili in modalità OAuth non supportano credenziali SecretRef; se `auth.profiles.<id>.mode` è impostato su `"oauth"`, l'input `keyRef`/`tokenRef` basato su SecretRef per quel profilo viene rifiutato.
|
||||
|
||||
Controllo adatto all'automazione (uscita `1` se scaduto/mancante, `2` se in scadenza):
|
||||
Controllo adatto all'automazione (uscita `1` quando mancante/scaduto, `2` quando in scadenza):
|
||||
|
||||
```bash
|
||||
openclaw models status --check
|
||||
@ -93,38 +110,38 @@ openclaw models status --probe
|
||||
|
||||
Note:
|
||||
|
||||
- Le righe della probe possono provenire da profili auth, credenziali env o `models.json`.
|
||||
- Se `auth.order.<provider>` esplicito omette un profilo archiviato, la probe riporta
|
||||
- Le righe di probe possono provenire da profili di autenticazione, credenziali env o `models.json`.
|
||||
- Se `auth.order.<provider>` esplicito omette un profilo archiviato, probe riporta
|
||||
`excluded_by_auth_order` per quel profilo invece di provarlo.
|
||||
- Se l'autenticazione esiste ma OpenClaw non riesce a risolvere un candidato di modello sondabile per
|
||||
quel provider, la probe riporta `status: no_model`.
|
||||
- I cooldown del rate limit possono essere limitati al modello. Un profilo in cooldown per un
|
||||
modello può comunque essere utilizzabile per un modello correlato dello stesso provider.
|
||||
- Se l'autenticazione esiste ma OpenClaw non riesce a risolvere un candidato di modello interrogabile per
|
||||
quel provider, probe riporta `status: no_model`.
|
||||
- I cooldown del rate limit possono essere specifici per modello. Un profilo in cooldown per un
|
||||
modello può essere ancora utilizzabile per un modello fratello sullo stesso provider.
|
||||
|
||||
Gli script operativi facoltativi (systemd/Termux) sono documentati qui:
|
||||
Gli script operativi opzionali (systemd/Termux) sono documentati qui:
|
||||
[Script di monitoraggio dell'autenticazione](/it/help/scripts#auth-monitoring-scripts)
|
||||
|
||||
## Nota su Anthropic
|
||||
|
||||
Il backend Anthropic `claude-cli` è di nuovo supportato.
|
||||
|
||||
- Il personale Anthropic ci ha comunicato che questo percorso di integrazione OpenClaw è nuovamente consentito.
|
||||
- OpenClaw quindi considera il riutilizzo di Claude CLI e l'uso di `claude -p` come autorizzati
|
||||
per esecuzioni basate su Anthropic, a meno che Anthropic non pubblichi una nuova policy.
|
||||
- Le chiavi API Anthropic restano la scelta più prevedibile per host gateway
|
||||
- Lo staff di Anthropic ci ha detto che questo percorso di integrazione di OpenClaw è di nuovo consentito.
|
||||
- OpenClaw quindi considera il riutilizzo della CLI di Claude e l'uso di `claude -p` come autorizzati
|
||||
per esecuzioni supportate da Anthropic, a meno che Anthropic non pubblichi una nuova policy.
|
||||
- Le chiavi API Anthropic restano la scelta più prevedibile per host Gateway
|
||||
di lunga durata e per un controllo esplicito della fatturazione lato server.
|
||||
|
||||
## Verifica dello stato di autenticazione del modello
|
||||
## Verifica dello stato dell'autenticazione del modello
|
||||
|
||||
```bash
|
||||
openclaw models status
|
||||
openclaw doctor
|
||||
```
|
||||
|
||||
## Comportamento di rotazione delle chiavi API (gateway)
|
||||
## Comportamento della rotazione delle chiavi API (Gateway)
|
||||
|
||||
Alcuni provider supportano il nuovo tentativo di una richiesta con chiavi alternative quando una chiamata API
|
||||
incontra un limite di frequenza del provider.
|
||||
raggiunge un rate limit del provider.
|
||||
|
||||
- Ordine di priorità:
|
||||
- `OPENCLAW_LIVE_<PROVIDER>_KEY` (singolo override)
|
||||
@ -133,24 +150,24 @@ incontra un limite di frequenza del provider.
|
||||
- `<PROVIDER>_API_KEY_*`
|
||||
- I provider Google includono anche `GOOGLE_API_KEY` come fallback aggiuntivo.
|
||||
- Lo stesso elenco di chiavi viene deduplicato prima dell'uso.
|
||||
- OpenClaw riprova con la chiave successiva solo per errori di rate limit (per esempio
|
||||
- OpenClaw ritenta con la chiave successiva solo per errori di rate limit (per esempio
|
||||
`429`, `rate_limit`, `quota`, `resource exhausted`, `Too many concurrent
|
||||
requests`, `ThrottlingException`, `concurrency limit reached`, o
|
||||
`workers_ai ... quota limit exceeded`).
|
||||
- Gli errori non legati al rate limit non vengono ritentati con chiavi alternative.
|
||||
- Gli errori non dovuti a rate limit non vengono ritentati con chiavi alternative.
|
||||
- Se tutte le chiavi falliscono, viene restituito l'errore finale dell'ultimo tentativo.
|
||||
|
||||
## Controllare quale credenziale viene usata
|
||||
|
||||
### Per sessione (comando chat)
|
||||
|
||||
Usa `/model <alias-or-id>@<profileId>` per fissare una credenziale provider specifica per la sessione corrente (esempi di ID profilo: `anthropic:default`, `anthropic:work`).
|
||||
Usa `/model <alias-or-id>@<profileId>` per fissare una credenziale provider specifica per la sessione corrente (esempio di id profilo: `anthropic:default`, `anthropic:work`).
|
||||
|
||||
Usa `/model` (o `/model list`) per un selettore compatto; usa `/model status` per la vista completa (candidati + profilo auth successivo, più dettagli dell'endpoint provider quando configurati).
|
||||
Usa `/model` (o `/model list`) per un selettore compatto; usa `/model status` per la vista completa (candidati + profilo di autenticazione successivo, oltre ai dettagli dell'endpoint provider quando configurati).
|
||||
|
||||
### Per agente (override CLI)
|
||||
|
||||
Imposta un override esplicito dell'ordine dei profili auth per un agente (archiviato nell'`auth-state.json` di quell'agente):
|
||||
Imposta un override esplicito dell'ordine dei profili di autenticazione per un agente (archiviato nel `auth-state.json` di quell'agente):
|
||||
|
||||
```bash
|
||||
openclaw models auth order get --provider anthropic
|
||||
@ -159,16 +176,17 @@ openclaw models auth order clear --provider anthropic
|
||||
```
|
||||
|
||||
Usa `--agent <id>` per indirizzare un agente specifico; omettilo per usare l'agente predefinito configurato.
|
||||
Quando esegui il debug di problemi di ordine, `openclaw models status --probe` mostra i profili
|
||||
archiviati omessi come `excluded_by_auth_order` invece di saltarli silenziosamente.
|
||||
Quando esegui il debug di problemi di cooldown, ricorda che i cooldown del rate limit possono essere associati
|
||||
a un ID modello invece che all'intero profilo provider.
|
||||
Quando esegui il debug di problemi di ordine, `openclaw models status --probe` mostra i
|
||||
profili archiviati omessi come `excluded_by_auth_order` invece di saltarli in silenzio.
|
||||
Quando esegui il debug di problemi di cooldown, ricorda che i cooldown del rate limit possono essere legati
|
||||
a un id modello anziché all'intero profilo provider.
|
||||
|
||||
## Risoluzione dei problemi
|
||||
|
||||
### "No credentials found"
|
||||
|
||||
Se il profilo Anthropic manca, configura una chiave API Anthropic sull'**host gateway** oppure imposta il percorso setup-token di Anthropic, poi ricontrolla:
|
||||
Se il profilo Anthropic manca, configura una chiave API Anthropic sull'**host Gateway**
|
||||
oppure imposta il percorso del token di configurazione Anthropic, poi ricontrolla:
|
||||
|
||||
```bash
|
||||
openclaw models status
|
||||
@ -177,5 +195,5 @@ openclaw models status
|
||||
### Token in scadenza/scaduto
|
||||
|
||||
Esegui `openclaw models status` per confermare quale profilo è in scadenza. Se un
|
||||
profilo token Anthropic manca o è scaduto, aggiorna tale configurazione tramite
|
||||
setup-token oppure passa a una chiave API Anthropic.
|
||||
profilo token Anthropic manca o è scaduto, aggiorna quella configurazione tramite
|
||||
token di configurazione oppure migra a una chiave API Anthropic.
|
||||
|
||||
@ -1,15 +1,15 @@
|
||||
---
|
||||
read_when:
|
||||
- Vuoi un fallback affidabile quando i provider API falliscono
|
||||
- Vuoi un fallback affidabile quando i provider API non funzionano
|
||||
- Stai eseguendo Codex CLI o altre CLI AI locali e vuoi riutilizzarle
|
||||
- Vuoi capire il bridge MCP loopback per l'accesso agli strumenti del backend CLI
|
||||
summary: 'Backend CLI: fallback CLI AI locale con bridge degli strumenti MCP facoltativo'
|
||||
- Vuoi capire il bridge MCP local loopback per l'accesso agli strumenti del backend CLI
|
||||
summary: 'Backend CLI: fallback della CLI AI locale con bridge strumenti MCP opzionale'
|
||||
title: Backend CLI
|
||||
x-i18n:
|
||||
generated_at: "2026-04-23T08:28:23Z"
|
||||
generated_at: "2026-04-23T14:55:08Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: 475923b36e4580d3e4e57014ff2e6b89e9eb52c11b0a0ab1fc8241655b07836e
|
||||
source_hash: ff7458d18b8a5b716930579241177917fd3edffcf7f6e211c7d570cf76519316
|
||||
source_path: gateway/cli-backends.md
|
||||
workflow: 15
|
||||
---
|
||||
@ -17,31 +17,31 @@ x-i18n:
|
||||
# Backend CLI (runtime di fallback)
|
||||
|
||||
OpenClaw può eseguire **CLI AI locali** come **fallback solo testo** quando i provider API non sono disponibili,
|
||||
sono soggetti a rate limit o si comportano male temporaneamente. Si tratta intenzionalmente di una soluzione conservativa:
|
||||
sono soggetti a limitazioni di frequenza o si comportano temporaneamente in modo anomalo. Si tratta intenzionalmente di una soluzione conservativa:
|
||||
|
||||
- **Gli strumenti OpenClaw non vengono iniettati direttamente**, ma i backend con `bundleMcp: true`
|
||||
possono ricevere strumenti gateway tramite un bridge MCP loopback.
|
||||
- **Gli strumenti di OpenClaw non vengono iniettati direttamente**, ma i backend con `bundleMcp: true`
|
||||
possono ricevere gli strumenti del gateway tramite un bridge MCP local loopback.
|
||||
- **Streaming JSONL** per le CLI che lo supportano.
|
||||
- **Le sessioni sono supportate** (così i turni di follow-up restano coerenti).
|
||||
- **Le immagini possono essere inoltrate** se la CLI accetta percorsi immagine.
|
||||
- **Le sessioni sono supportate** (quindi i turni successivi restano coerenti).
|
||||
- **Le immagini possono essere inoltrate** se la CLI accetta percorsi di immagini.
|
||||
|
||||
Questo è progettato come **rete di sicurezza** piuttosto che come percorso primario. Usalo quando
|
||||
vuoi risposte testuali “sempre funzionanti” senza dipendere da API esterne.
|
||||
Questo è progettato come **rete di sicurezza** piuttosto che come percorso principale. Usalo quando
|
||||
vuoi risposte testuali che “funzionano sempre” senza fare affidamento su API esterne.
|
||||
|
||||
Se vuoi un runtime harness completo con controlli di sessione ACP, attività in background,
|
||||
associazione di thread/conversazioni e sessioni di coding esterne persistenti, usa invece
|
||||
associazione thread/conversazione e sessioni di coding esterne persistenti, usa
|
||||
[ACP Agents](/it/tools/acp-agents). I backend CLI non sono ACP.
|
||||
|
||||
## Avvio rapido per principianti
|
||||
## Guida rapida per principianti
|
||||
|
||||
Puoi usare Codex CLI **senza alcuna config** (il Plugin OpenAI incluso
|
||||
Puoi usare Codex CLI **senza alcuna configurazione** (il Plugin OpenAI incluso
|
||||
registra un backend predefinito):
|
||||
|
||||
```bash
|
||||
openclaw agent --message "hi" --model codex-cli/gpt-5.4
|
||||
```
|
||||
|
||||
Se il tuo gateway viene eseguito sotto launchd/systemd e il PATH è minimo, aggiungi solo il
|
||||
Se il tuo gateway viene eseguito sotto launchd/systemd e PATH è minimale, aggiungi solo il
|
||||
percorso del comando:
|
||||
|
||||
```json5
|
||||
@ -58,16 +58,16 @@ percorso del comando:
|
||||
}
|
||||
```
|
||||
|
||||
Questo è tutto. Nessuna chiave, nessuna config di autenticazione extra oltre a quella della CLI stessa.
|
||||
Questo è tutto. Non sono necessarie chiavi né configurazioni di autenticazione aggiuntive oltre a quelle della CLI stessa.
|
||||
|
||||
Se usi un backend CLI incluso come **provider di messaggi primario** su un
|
||||
host gateway, OpenClaw ora carica automaticamente il Plugin incluso proprietario quando la tua config
|
||||
fa riferimento esplicito a quel backend in un riferimento modello o sotto
|
||||
Se usi un backend CLI incluso come **provider di messaggi principale** su un
|
||||
host gateway, OpenClaw ora carica automaticamente il Plugin incluso proprietario quando la tua configurazione
|
||||
fa esplicito riferimento a quel backend in un model ref o sotto
|
||||
`agents.defaults.cliBackends`.
|
||||
|
||||
## Usarlo come fallback
|
||||
## Utilizzarlo come fallback
|
||||
|
||||
Aggiungi un backend CLI al tuo elenco di fallback in modo che venga eseguito solo quando i modelli primari falliscono:
|
||||
Aggiungi un backend CLI al tuo elenco di fallback in modo che venga eseguito solo quando i modelli primari non riescono:
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -89,8 +89,8 @@ Aggiungi un backend CLI al tuo elenco di fallback in modo che venga eseguito sol
|
||||
Note:
|
||||
|
||||
- Se usi `agents.defaults.models` (allowlist), devi includere anche lì i modelli del tuo backend CLI.
|
||||
- Se il provider primario fallisce (autenticazione, rate limit, timeout), OpenClaw
|
||||
proverà successivamente il backend CLI.
|
||||
- Se il provider primario non funziona (autenticazione, limiti di frequenza, timeout), OpenClaw
|
||||
proverà poi il backend CLI.
|
||||
|
||||
## Panoramica della configurazione
|
||||
|
||||
@ -101,7 +101,7 @@ agents.defaults.cliBackends
|
||||
```
|
||||
|
||||
Ogni voce è indicizzata da un **id provider** (ad esempio `codex-cli`, `my-cli`).
|
||||
L'id provider diventa la parte sinistra del tuo riferimento modello:
|
||||
L'id provider diventa il lato sinistro del tuo model ref:
|
||||
|
||||
```
|
||||
<provider>/<model>
|
||||
@ -148,87 +148,100 @@ L'id provider diventa la parte sinistra del tuo riferimento modello:
|
||||
## Come funziona
|
||||
|
||||
1. **Seleziona un backend** in base al prefisso del provider (`codex-cli/...`).
|
||||
2. **Costruisce un prompt di sistema** usando lo stesso prompt + contesto workspace di OpenClaw.
|
||||
3. **Esegue la CLI** con un ID sessione (se supportato) così la cronologia resta coerente.
|
||||
Il backend incluso `claude-cli` mantiene vivo un processo Claude stdio per
|
||||
sessione OpenClaw e invia i turni di follow-up tramite stdin stream-json.
|
||||
2. **Costruisce un system prompt** usando lo stesso prompt OpenClaw + il contesto del workspace.
|
||||
3. **Esegue la CLI** con un id sessione (se supportato) in modo che la cronologia resti coerente.
|
||||
Il backend `claude-cli` incluso mantiene attivo un processo Claude stdio per ogni
|
||||
sessione OpenClaw e invia i turni successivi tramite stream-json su stdin.
|
||||
4. **Analizza l'output** (JSON o testo semplice) e restituisce il testo finale.
|
||||
5. **Rende persistenti gli ID sessione** per backend, così i follow-up riutilizzano la stessa sessione CLI.
|
||||
5. **Mantiene gli id sessione** per backend, in modo che i turni successivi riutilizzino la stessa sessione CLI.
|
||||
|
||||
<Note>
|
||||
Il backend incluso Anthropic `claude-cli` è di nuovo supportato. Lo staff Anthropic
|
||||
ci ha detto che l'uso di Claude CLI in stile OpenClaw è di nuovo consentito, quindi OpenClaw tratta
|
||||
l'uso di `claude -p` come autorizzato per questa integrazione, salvo che Anthropic pubblichi
|
||||
Il backend Anthropic `claude-cli` incluso è di nuovo supportato. Il personale Anthropic
|
||||
ci ha detto che l'uso di Claude CLI in stile OpenClaw è di nuovo consentito, quindi OpenClaw considera
|
||||
l'uso di `claude -p` come autorizzato per questa integrazione, a meno che Anthropic non pubblichi
|
||||
una nuova policy.
|
||||
</Note>
|
||||
|
||||
Il backend incluso OpenAI `codex-cli` passa il prompt di sistema di OpenClaw tramite
|
||||
l'override di config `model_instructions_file` di Codex (`-c
|
||||
Il backend OpenAI `codex-cli` incluso passa il system prompt di OpenClaw tramite
|
||||
l'override della configurazione `model_instructions_file` di Codex (`-c
|
||||
model_instructions_file="..."`). Codex non espone un flag in stile Claude
|
||||
`--append-system-prompt`, quindi OpenClaw scrive il prompt assemblato in un
|
||||
file temporaneo per ogni nuova sessione Codex CLI.
|
||||
|
||||
Il backend incluso Anthropic `claude-cli` riceve lo snapshot delle Skills OpenClaw
|
||||
in due modi: il catalogo compatto delle Skills OpenClaw nel prompt di sistema aggiunto, e
|
||||
Il backend Anthropic `claude-cli` incluso riceve lo snapshot delle Skills di OpenClaw
|
||||
in due modi: il catalogo compatto delle Skills di OpenClaw nel system prompt aggiunto, e
|
||||
un Plugin Claude Code temporaneo passato con `--plugin-dir`. Il Plugin contiene
|
||||
solo le skill idonee per quell'agente/sessione, quindi il resolver di skill nativo di Claude Code
|
||||
vede lo stesso insieme filtrato che OpenClaw altrimenti pubblicizzerebbe nel prompt.
|
||||
Gli override di env/API key delle skill vengono comunque applicati da OpenClaw all'ambiente del processo figlio per l'esecuzione.
|
||||
solo le Skills idonee per quell'agente/sessione, quindi il resolver nativo delle skill di Claude Code
|
||||
vede lo stesso insieme filtrato che altrimenti OpenClaw pubblicizzerebbe nel
|
||||
prompt. Le sostituzioni di env/chiavi API delle skill vengono comunque applicate da OpenClaw all'ambiente
|
||||
del processo figlio per l'esecuzione.
|
||||
|
||||
Prima che OpenClaw possa usare il backend `claude-cli` incluso, Claude Code stesso
|
||||
deve già aver effettuato l'accesso sullo stesso host:
|
||||
|
||||
```bash
|
||||
claude auth login
|
||||
claude auth status --text
|
||||
openclaw models auth login --provider anthropic --method cli --set-default
|
||||
```
|
||||
|
||||
Usa `agents.defaults.cliBackends.claude-cli.command` solo quando il binario `claude`
|
||||
non è già in `PATH`.
|
||||
|
||||
## Sessioni
|
||||
|
||||
- Se la CLI supporta le sessioni, imposta `sessionArg` (ad esempio `--session-id`) oppure
|
||||
- Se la CLI supporta le sessioni, imposta `sessionArg` (ad esempio `--session-id`) o
|
||||
`sessionArgs` (segnaposto `{sessionId}`) quando l'ID deve essere inserito
|
||||
in più flag.
|
||||
- Se la CLI usa un **sottocomando di ripresa** con flag diversi, imposta
|
||||
`resumeArgs` (sostituisce `args` durante la ripresa) e facoltativamente `resumeOutput`
|
||||
- Se la CLI usa un **sottocomando resume** con flag diversi, imposta
|
||||
`resumeArgs` (sostituisce `args` alla ripresa) e facoltativamente `resumeOutput`
|
||||
(per riprese non JSON).
|
||||
- `sessionMode`:
|
||||
- `always`: invia sempre un ID sessione (nuovo UUID se non ne è stato salvato nessuno).
|
||||
- `existing`: invia un ID sessione solo se ne era già stato salvato uno.
|
||||
- `none`: non invia mai un ID sessione.
|
||||
- `claude-cli` usa come valori predefiniti `liveSession: "claude-stdio"`, `output: "jsonl"`,
|
||||
e `input: "stdin"` così i turni di follow-up riutilizzano il processo Claude attivo
|
||||
mentre è attivo. Lo stdio caldo è ora il valore predefinito, anche per config personalizzate
|
||||
- `always`: invia sempre un id sessione (nuovo UUID se non ne è memorizzato nessuno).
|
||||
- `existing`: invia un id sessione solo se ne era già stato memorizzato uno.
|
||||
- `none`: non invia mai un id sessione.
|
||||
- `claude-cli` usa per impostazione predefinita `liveSession: "claude-stdio"`, `output: "jsonl"`,
|
||||
e `input: "stdin"` in modo che i turni successivi riutilizzino il processo Claude attivo mentre
|
||||
è attivo. Lo stdio warm è ora il comportamento predefinito, anche per configurazioni personalizzate
|
||||
che omettono i campi di trasporto. Se il Gateway si riavvia o il processo inattivo termina,
|
||||
OpenClaw riprende dall'ID sessione Claude memorizzato. Gli ID sessione memorizzati vengono verificati
|
||||
rispetto a una trascrizione di progetto esistente e leggibile prima della ripresa, così
|
||||
le associazioni fantasma vengono cancellate con `reason=transcript-missing`
|
||||
OpenClaw riprende dall'id sessione Claude memorizzato. Gli id sessione memorizzati vengono verificati
|
||||
rispetto a una trascrizione di progetto esistente e leggibile prima della ripresa, così i binding fantasma
|
||||
vengono eliminati con `reason=transcript-missing`
|
||||
invece di avviare silenziosamente una nuova sessione Claude CLI con `--resume`.
|
||||
- Le sessioni CLI memorizzate sono continuità gestita dal provider. Il reset giornaliero implicito
|
||||
- Le sessioni CLI memorizzate sono continuità di proprietà del provider. Il reset giornaliero implicito
|
||||
non le interrompe; `/reset` e le policy esplicite `session.reset` sì.
|
||||
|
||||
Note sulla serializzazione:
|
||||
|
||||
- `serialize: true` mantiene ordinate le esecuzioni sulla stessa corsia.
|
||||
- La maggior parte delle CLI serializza su una corsia provider.
|
||||
- OpenClaw interrompe il riutilizzo delle sessioni CLI memorizzate quando cambia l'identità di autenticazione selezionata,
|
||||
inclusi un ID profilo auth cambiato, una API key statica, un token statico o l'identità
|
||||
dell'account OAuth quando la CLI ne espone una. La rotazione dei token OAuth di accesso e refresh
|
||||
non interrompe la sessione CLI memorizzata. Se una CLI non espone un ID account OAuth stabile,
|
||||
OpenClaw lascia che sia quella CLI a far rispettare i permessi di ripresa.
|
||||
- `serialize: true` mantiene ordinate le esecuzioni sulla stessa lane.
|
||||
- La maggior parte delle CLI serializza su una lane provider.
|
||||
- OpenClaw interrompe il riutilizzo della sessione CLI memorizzata quando cambia l'identità di autenticazione selezionata,
|
||||
incluso un id profilo di autenticazione cambiato, una chiave API statica, un token statico o
|
||||
l'identità dell'account OAuth quando la CLI la espone. La rotazione del token di accesso e refresh OAuth
|
||||
non interrompe la sessione CLI memorizzata. Se una CLI non espone un id account OAuth stabile,
|
||||
OpenClaw lascia che sia quella CLI a imporre i permessi di ripresa.
|
||||
|
||||
## Immagini (pass-through)
|
||||
## Immagini (inoltro diretto)
|
||||
|
||||
Se la tua CLI accetta percorsi immagine, imposta `imageArg`:
|
||||
Se la tua CLI accetta percorsi di immagini, imposta `imageArg`:
|
||||
|
||||
```json5
|
||||
imageArg: "--image",
|
||||
imageMode: "repeat"
|
||||
```
|
||||
|
||||
OpenClaw scriverà le immagini base64 in file temporanei. Se `imageArg` è impostato, quei
|
||||
OpenClaw scriverà le immagini base64 in file temporanei. Se `imageArg` è impostato, tali
|
||||
percorsi vengono passati come argomenti CLI. Se `imageArg` manca, OpenClaw aggiunge i
|
||||
percorsi file al prompt (path injection), che è sufficiente per le CLI che caricano automaticamente
|
||||
file locali da percorsi semplici.
|
||||
percorsi dei file al prompt (path injection), il che è sufficiente per le CLI che caricano automaticamente
|
||||
i file locali da semplici percorsi.
|
||||
|
||||
## Input / output
|
||||
|
||||
- `output: "json"` (predefinito) prova ad analizzare JSON e a estrarre testo + ID sessione.
|
||||
- `output: "json"` (predefinito) prova ad analizzare JSON ed estrarre testo + id sessione.
|
||||
- Per l'output JSON di Gemini CLI, OpenClaw legge il testo della risposta da `response` e
|
||||
l'uso da `stats` quando `usage` manca o è vuoto.
|
||||
- `output: "jsonl"` analizza stream JSONL (ad esempio Codex CLI `--json`) ed estrae il messaggio finale dell'agente più gli identificatori di sessione
|
||||
quando presenti.
|
||||
- `output: "jsonl"` analizza flussi JSONL (ad esempio Codex CLI `--json`) ed estrae il messaggio finale dell'agente più gli identificatori
|
||||
di sessione quando presenti.
|
||||
- `output: "text"` tratta stdout come risposta finale.
|
||||
|
||||
Modalità di input:
|
||||
@ -237,7 +250,7 @@ Modalità di input:
|
||||
- `input: "stdin"` invia il prompt tramite stdin.
|
||||
- Se il prompt è molto lungo e `maxPromptArgChars` è impostato, viene usato stdin.
|
||||
|
||||
## Valori predefiniti (gestiti dal Plugin)
|
||||
## Valori predefiniti (di proprietà del Plugin)
|
||||
|
||||
Il Plugin OpenAI incluso registra anche un valore predefinito per `codex-cli`:
|
||||
|
||||
@ -262,31 +275,31 @@ Il Plugin Google incluso registra anche un valore predefinito per `google-gemini
|
||||
- `sessionIdFields: ["session_id", "sessionId"]`
|
||||
|
||||
Prerequisito: la Gemini CLI locale deve essere installata e disponibile come
|
||||
`gemini` nel `PATH` (`brew install gemini-cli` o
|
||||
`gemini` in `PATH` (`brew install gemini-cli` oppure
|
||||
`npm install -g @google/gemini-cli`).
|
||||
|
||||
Note JSON di Gemini CLI:
|
||||
Note JSON per Gemini CLI:
|
||||
|
||||
- Il testo della risposta viene letto dal campo JSON `response`.
|
||||
- L'uso ricade su `stats` quando `usage` è assente o vuoto.
|
||||
- L'uso usa `stats` come fallback quando `usage` è assente o vuoto.
|
||||
- `stats.cached` viene normalizzato in `cacheRead` di OpenClaw.
|
||||
- Se `stats.input` manca, OpenClaw ricava i token di input da
|
||||
`stats.input_tokens - stats.cached`.
|
||||
|
||||
Esegui override solo se necessario (caso comune: percorso `command` assoluto).
|
||||
|
||||
## Valori predefiniti gestiti dal Plugin
|
||||
## Valori predefiniti di proprietà del Plugin
|
||||
|
||||
I valori predefiniti del backend CLI fanno ora parte della surface del Plugin:
|
||||
I valori predefiniti del backend CLI ora fanno parte della superficie del Plugin:
|
||||
|
||||
- I plugin li registrano con `api.registerCliBackend(...)`.
|
||||
- Il `id` del backend diventa il prefisso provider nei riferimenti modello.
|
||||
- La config utente in `agents.defaults.cliBackends.<id>` continua a sovrascrivere il valore predefinito del Plugin.
|
||||
- La pulizia della config specifica del backend resta gestita dal Plugin tramite l'hook facoltativo
|
||||
`normalizeConfig`.
|
||||
- I Plugin li registrano con `api.registerCliBackend(...)`.
|
||||
- L'`id` del backend diventa il prefisso provider nei model ref.
|
||||
- La configurazione utente in `agents.defaults.cliBackends.<id>` continua a sovrascrivere il valore predefinito del Plugin.
|
||||
- La pulizia della configurazione specifica del backend resta di proprietà del Plugin tramite
|
||||
l'hook facoltativo `normalizeConfig`.
|
||||
|
||||
I plugin che hanno bisogno di piccoli shim di compatibilità prompt/messaggio possono dichiarare
|
||||
trasformazioni testuali bidirezionali senza sostituire un provider o un backend CLI:
|
||||
I Plugin che hanno bisogno di piccoli shim di compatibilità per prompt/messaggi possono dichiarare
|
||||
trasformazioni bidirezionali del testo senza sostituire un provider o un backend CLI:
|
||||
|
||||
```typescript
|
||||
api.registerTextTransforms({
|
||||
@ -303,42 +316,42 @@ api.registerTextTransforms({
|
||||
});
|
||||
```
|
||||
|
||||
`input` riscrive il prompt di sistema e il prompt utente passati alla CLI. `output`
|
||||
riscrive i delta dell'assistente in streaming e il testo finale analizzato prima che OpenClaw gestisca
|
||||
`input` riscrive il system prompt e il prompt utente passati alla CLI. `output`
|
||||
riscrive i delta assistant in streaming e il testo finale analizzato prima che OpenClaw gestisca
|
||||
i propri marker di controllo e la consegna sul canale.
|
||||
|
||||
Per le CLI che emettono JSONL compatibile con lo stream-json di Claude Code, imposta
|
||||
`jsonlDialect: "claude-stream-json"` nella config di quel backend.
|
||||
Per le CLI che emettono JSONL compatibile con stream-json di Claude Code, imposta
|
||||
`jsonlDialect: "claude-stream-json"` nella configurazione di quel backend.
|
||||
|
||||
## Overlay MCP bundle
|
||||
|
||||
I backend CLI **non** ricevono direttamente chiamate agli strumenti OpenClaw, ma un backend può
|
||||
abilitare una overlay di config MCP generata con `bundleMcp: true`.
|
||||
I backend CLI **non** ricevono direttamente le chiamate agli strumenti di OpenClaw, ma un backend può
|
||||
abilitare una overlay di configurazione MCP generata con `bundleMcp: true`.
|
||||
|
||||
Comportamento attualmente incluso:
|
||||
Comportamento incluso attuale:
|
||||
|
||||
- `claude-cli`: file di config MCP strict generato
|
||||
- `codex-cli`: override di config inline per `mcp_servers`
|
||||
- `claude-cli`: file di configurazione MCP strict generato
|
||||
- `codex-cli`: override di configurazione inline per `mcp_servers`
|
||||
- `google-gemini-cli`: file di impostazioni di sistema Gemini generato
|
||||
|
||||
Quando bundle MCP è abilitato, OpenClaw:
|
||||
|
||||
- avvia un server MCP HTTP loopback che espone strumenti gateway al processo CLI
|
||||
- avvia un server MCP HTTP local loopback che espone gli strumenti del gateway al processo CLI
|
||||
- autentica il bridge con un token per sessione (`OPENCLAW_MCP_TOKEN`)
|
||||
- limita l'accesso agli strumenti alla sessione, all'account e al contesto del canale correnti
|
||||
- carica i server bundle-MCP abilitati per il workspace corrente
|
||||
- li unisce con qualsiasi forma di config/impostazioni MCP backend esistente
|
||||
- riscrive la config di avvio usando la modalità di integrazione gestita dal backend dell'estensione proprietaria
|
||||
- li unisce con qualunque configurazione/forma di impostazioni MCP del backend già esistente
|
||||
- riscrive la configurazione di avvio usando la modalità di integrazione di proprietà del backend dall'estensione proprietaria
|
||||
|
||||
Se non è abilitato alcun server MCP, OpenClaw inietta comunque una config strict quando un
|
||||
backend abilita bundle MCP così che le esecuzioni in background restino isolate.
|
||||
Se non sono abilitati server MCP, OpenClaw inietta comunque una configurazione strict quando un
|
||||
backend abilita bundle MCP, così le esecuzioni in background restano isolate.
|
||||
|
||||
## Limitazioni
|
||||
|
||||
- **Nessuna chiamata diretta agli strumenti OpenClaw.** OpenClaw non inietta chiamate agli strumenti nel
|
||||
protocollo del backend CLI. I backend vedono gli strumenti gateway solo quando abilitano
|
||||
- **Nessuna chiamata diretta agli strumenti di OpenClaw.** OpenClaw non inietta chiamate agli strumenti nel
|
||||
protocollo del backend CLI. I backend vedono gli strumenti del gateway solo quando abilitano
|
||||
`bundleMcp: true`.
|
||||
- **Lo streaming è specifico del backend.** Alcuni backend trasmettono JSONL; altri fanno buffering
|
||||
- **Lo streaming è specifico del backend.** Alcuni backend trasmettono JSONL in streaming; altri accumulano
|
||||
fino all'uscita.
|
||||
- **Gli output strutturati** dipendono dal formato JSON della CLI.
|
||||
- **Le sessioni Codex CLI** riprendono tramite output testuale (senza JSONL), che è meno
|
||||
@ -348,7 +361,7 @@ backend abilita bundle MCP così che le esecuzioni in background restino isolate
|
||||
## Risoluzione dei problemi
|
||||
|
||||
- **CLI non trovata**: imposta `command` su un percorso completo.
|
||||
- **Nome modello errato**: usa `modelAliases` per mappare `provider/model` → modello CLI.
|
||||
- **Nome del modello errato**: usa `modelAliases` per mappare `provider/model` → modello CLI.
|
||||
- **Nessuna continuità di sessione**: assicurati che `sessionArg` sia impostato e che `sessionMode` non sia
|
||||
`none` (Codex CLI attualmente non può riprendere con output JSON).
|
||||
- **Immagini ignorate**: imposta `imageArg` (e verifica che la CLI supporti i percorsi file).
|
||||
`none` (al momento Codex CLI non può riprendere con output JSON).
|
||||
- **Immagini ignorate**: imposta `imageArg` (e verifica che la CLI supporti i percorsi dei file).
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
Loading…
Reference in New Issue
Block a user