Agenti condivisi multiplayer in OpenClaw: due dispositivi, un solo contesto

Due dispositivi possono usare lo stesso agente OpenClaw senza problemi, ma solo se consideri la coda come semplice testo e la persistenza come un compito separato. La sessione condivisa conserva il contesto; file come active-tasks.md conservano invece gli impegni.

È questa la distinzione fondamentale. OpenClaw 2.0 (release v2026.8.1, annunciata il 30 agosto 2026) ha introdotto le sessioni condivise multiplayer sopra un Gateway che resta comunque un unico dominio di fiducia. In questo modo due telefoni, due laptop o due persone possono guidare la stessa esecuzione senza creare fork privati (docs.openclaw.ai). La documentazione ufficiale chiarisce però che ownership, presenza e ruoli servono a coordinare il lavoro, non a isolare utenti ostili dal punto di vista della sicurezza (docs.openclaw.ai). Tra ciò che descrivono i documenti e i problemi in cui gli utenti inciampano davvero ci sono tre aree delicate: coda, durata della sessione e memoria.

Telefono sul divano, laptop sulla scrivania: cosa si rompe davvero

Lo scenario più comune con due dispositivi non coinvolge necessariamente due persone. Spesso c’è un solo utente, con il telefono usato come telecomando e un Mac Mini o un VPS come macchina host, magari attraverso Telegram. Un utente lo ha descritto così: chiedere al proprio "openclaw agent Monica from telegram to install mem0 locally on my mac mini" (x.com).

Quando entra in gioco un secondo dispositivo o una seconda persona, gli utenti riportano soprattutto quattro problemi:

1. I messaggi spariscono senza avviso. Uno degli insegnamenti più ricorrenti nella community è avere queue mode enabled so messages never silently drop, insieme a active-tasks.md as persistent state for crash recovery e a un Boot.md che lo rilegga al riavvio (x.com). Senza questa combinazione, un messaggio inviato mentre l’agente sta completando un turno resta testo della conversazione potenzialmente perdibile, non un’attività salvata.
2. Le istruzioni svaniscono dopo il compaction o un riavvio. Un utente di Reddit lo ha riassunto in modo netto:

"There's no durable task queue — when the agent says 'I'll work on that,' it's a conversational promise." — u/Brave_Nobody_6909, r/openclaw

Nello stesso thread si racconta che le promesse possono sparire dopo il compaction o un riavvio, lasciando l’agente incapace di seguire i runbook salvati. Un’analisi pubblicata da un maintainer ammette lo stesso schema: un agente che "works perfectly for 20 minutes" e poi "silently forgets your instructions and goes rogue" quando la gestione della memoria viene interpretata male (x.com).

1. La sessione si resetta mentre stai lavorando. I valori predefiniti dei canali Telegram hanno incluso thread: { mode: "idle", idleMinutes: 180 }, che resetta la sessione dopo alcune ore di inattività. Un utente lo ha portato a 4 giorni dopo aver riscontrato il problema della memoria usando il telefono come secondo schermo (x.com). Il context overflow peggiora ulteriormente la situazione: un uso eccessivo degli strumenti può far reinserire l’ultimo messaggio, così l’agente "responds to the same thing over and over" e poi "silently degrades" (x.com).
2. Il pairing si rompe prima ancora di arrivare al multiplayer. Dopo un aggiornamento, alcuni dispositivi associati hanno perso gli scope operator.read/operator.write e sono finiti in un ciclo infinito di pairing con strumenti inutilizzabili. Il fondatore ha risposto: "This was me being overzealous in fixing a potential security issue" (x.com). Anche utenti cinesi hanno incontrato lo stesso ostacolo con l’errore 1008: pairing required, mentre il dispositivo locale restava nella coda Pending fino all’esecuzione di openclaw devices list e devices approve <UUID> (x.com).

La presenza segnala quando qualcuno sta scrivendo, ma nessun indicatore trasforma un messaggio in coda in un’attività salvata.

Un Gateway, un solo dominio di fiducia: sessioni condivise, agenti separati e responsabilità

La novità più importante di OpenClaw 2.0 sono le sessioni condivise: un’altra persona può entrare in un lavoro già avviato mantenendone il contesto. Diverse recensioni indipendenti l’hanno descritta come il passaggio da un uso individuale a un lavoro collaborativo (eesel.ai). Alla base della configurazione ci sono però due concetti della documentazione ufficiale.

La modalità multi-user consente a più persone fidate di usare lo stesso agente. Ogni sessione condivisa registra tre livelli: un creatore immutabile (createdActor, scrivibile una sola volta), un proprietario assegnabile, simile all’assegnatario di GitHub e modificabile in qualsiasi momento, e la cronologia dei partecipanti che hanno effettivamente inviato prompt (docs.openclaw.ai). La presenza mostra chi sta visualizzando o scrivendo, ma le bozze digitate non arrivano né al modello né alla trascrizione. Anche l’attribuzione dei turni è esplicitamente best-effort, perché il controllo può fondere gli input di più persone in un unico turno (docs.openclaw.ai). In pratica, un messaggio inviato da un secondo canale mentre l’agente sta eseguendo una chiamata a uno strumento entra nella trascrizione, ma il turno in corso termina per primo: la seconda istruzione viene quindi interpretata come una nota di guida, non come un’interruzione (docs.openclaw.ai).

La modalità multi-agent permette invece a un singolo processo Gateway di ospitare più cervelli isolati, ciascuno con il proprio workspace, agentDir (profili di autenticazione e registro dei modelli) e archivio SQLite delle sessioni in <agentDir>/openclaw-agent.sqlite (github.com). Un binding indirizza ogni evento in ingresso del canale verso un agente; vince la corrispondenza più specifica. Non riutilizzare mai lo stesso agentDir per più agenti, altrimenti si sovrascrivono a vicenda il file auth-profiles.json (stack-junkie.com). Esempio minimo: { agentId: "coding", match: { channel: "telegram", accountId: "coding-bot" } } indirizza un bot verso un solo agente.

La frase da ricordare è: "A gateway is one trust domain" (docs.openclaw.ai). Ruoli, filtri sul proprietario e avatar non isolano gli utenti ostili. Quando gli utenti non sono reciprocamente fidati servono Gateway separati, idealmente anche utenti o host del sistema operativo distinti.

Se i due dispositivi appartengono alla stessa persona, scegli la prima colonna. Se invece due persone non devono vedere abitualmente la cronologia dell’altra, scegli la seconda; quando l’accesso deve essere davvero protetto da utenti non fidati, usa due Gateway. I consigli su Reddit per le coppie che condividono un bot convergono su questa soluzione: "create 2 agents, same auth profile, but 1 geared towards you... and the other to your wife" (u/mr-cto-apps, r/openclaw). In una discussione sulla condivisione di un unico bot Telegram, un utente suggerisce che "most people in your situation just run two instances" (u/dertobi, r/openclaw): un consiglio ancora valido per il lavoro privato separato, anche dopo l’introduzione delle sessioni condivise in 2.0.

Dove finisce il secondo messaggio mentre l’agente è occupato

Immagina tre contenitori distinti: confonderli è il modo più rapido per perdere lavoro.

Contenitore 1: la coda della sessione. Il testo inviato mentre l’agente lavora viene aggiunto alla sessione corrente. La modalità coda lo mette in attesa invece di scartarlo, mentre la presenza ti segnala che l’agente è nel mezzo di un turno: il messaggio guiderà quindi il turno successivo, senza interrompere quello in corso. Le anteprime di digitazione restano temporanee e non entrano nel contesto (docs.openclaw.ai). Dal secondo dispositivo conviene inviare messaggi brevi e inequivocabili, come "dopo aver finito fai X; non riavviare Y", perché la documentazione definisce best-effort l’attribuzione del turno quando la guida fonde gli input di più utenti (docs.openclaw.ai).

Contenitore 2: le attività persistenti. Un messaggio in coda non è un’attività durevole. Se il Gateway si riavvia, la sessione esegue il compaction o usi /new, le promesse della conversazione possono sparire. La soluzione della community che resiste ai riavvii è un file, non un messaggio: active-tasks.md come stato di recupero dagli arresti anomali e un Boot.md che l’agente legge all’avvio della sessione e del Gateway (x.com). Gli strumenti di memoria possono reiniettare il contesto, ma un’analisi molto condivisa avverte che anche la memoria caricata può essere riassunta fino a sparire: "The memory exists on disk. The agent just lost the ability to walk through it" (x.com).

Contenitore 3: il lavoro pianificato. Cron e Automations funzionano mentre il Gateway è in esecuzione; se l’host va in sospensione, le attività pianificate si fermano (eesel.ai). Un utente ha raccontato che le esecuzioni cron rendevano l’agente "basically unusable during that time" perché la cronologia riempiva il contesto, consigliando di isolare i contesti per argomento Telegram (x.com). Usa i job pianificati per il lavoro ricorrente, mai come sostituti dell’accodamento di una nuova istruzione.

L’ispezione della coda può essere in ritardo rispetto alla situazione reale: una discussione ha segnalato richieste visibilmente accodate mentre /subagents e /tasks non mostravano nulla (reddit.com). Per verificare che il lavoro sopravviva al riavvio, affidati al file del secondo contenitore, indipendentemente da ciò che mostra l’interfaccia della coda.

La configurazione a due dispositivi che non perde le istruzioni

Questa è la configurazione adatta a una persona che usa laptop e telefono, oppure a due colleghi fidati che lavorano nella stessa sessione. Si basa sulla procedura rapida e sui runbook per l’uso in produzione (docs.openclaw.ai), con le correzioni contro la perdita di dati emerse nella community.

1. Metti il Gateway su un host sempre acceso e accedi tramite identità. Può bastare un piccolo VPS, un Mac dell’ufficio o un Mac Mini. Associa il Gateway a loopback e pubblicalo tramite Tailscale Serve o Cloudflare Access, invece di esporre una porta pubblica o usare un token condiviso. L’accesso basato sull’identità consente di attribuire le azioni alle singole persone e di assegnare il credito ai commit; con un token condiviso tutti risultano lo stesso profilo proprietario (docs.openclaw.ai).
2. Collega entrambi i dispositivi alla stessa sessione. Apri la Control UI o il canale di chat su ciascun dispositivo, assegna esplicitamente il proprietario della sessione (Control UI Assign to me / Assign to, oppure lo strumento sessions con assign_owner) e usa le @mention per passare il lavoro. DM e stanze di gruppo richiedono allowlist separate (docs.openclaw.ai). Cambiare proprietario modifica la responsabilità, non la condivisione legata al creatore né l’autorità sull’archivio: mantieni quindi stabile il creatore.
3. Attiva la coda e rendi il lavoro resistente ai riavvii. Imposta la sessione condivisa in modalità coda, così un messaggio inviato durante un turno resta in attesa invece di competere con l’esecuzione in corso. Senza questa impostazione, gli utenti riportano che i messaggi possono sparire senza avviso. Conserva nel workspace un active-tasks.md con una riga per ogni impegno (fatto / in corso / prossimo) e aggiungi un Boot.md che ordini all’agente di leggerlo all’avvio (x.com). Verifica che il modello risponda prima di affidarti al secondo dispositivo: salvare le credenziali da solo non conferma che tutto funzioni (docs.openclaw.ai).
4. Allunga la durata della sessione sui canali usati dal telefono. Se Telegram è il secondo schermo e il thread usa il reset segnalato thread: { mode: "idle", idleMinutes: 180 }, aumenta il valore per i lavori lunghi: un utente lo ha portato a 4 giorni. Mantieni inoltre separati gli argomenti, così l’output dei cron non invade il contesto condiviso.
5. Assegna a ogni persona il proprio account del modello. I profili del Gateway possono contenere credenziali personali; le nuove sessioni preferiscono il default personale senza modificare quello globale del Gateway, mentre gli altri utenti vedono solo un’etichetta a livello di persona, non email o account ID (docs.openclaw.ai). Le credenziali vanno inserite tramite UI protetta o prompt del terminale nascosti, mai incollate nella conversazione, dove finirebbero nella trascrizione condivisa.
6. Fai una verifica completa. Dal secondo dispositivo invia un messaggio durante un turno e controlla che venga conservato ed elaborato dopo la fine del turno attivo. Poi riavvia il Gateway e verifica che active-tasks.md ripristini l’impegno. Anche la checklist ufficiale per la produzione termina allo stesso modo: verifica tutto il flusso prima di considerare concluso il lavoro (docs.openclaw.ai).

Le regole per evitare che il contesto condiviso si deteriori

Tre regole coprono gran parte dei problemi di deterioramento descritti dagli utenti.

Firma ogni modifica alla memoria. Il guasto più silenzioso si verifica quando regole senza autore si accumulano fino a diventare intoccabili: "six months in the shared context is full of rules nobody can trace to a person, so nobody feels allowed to delete them", con la soluzione suggerita "author on every memory write" (x.com). Il problema nasce dalla scrittura condivisa senza attribuzione. Aggiungi alle note persistenti chi ha richiesto la modifica e quando, poi fai pulizia ogni mese.

Isola l’utente con meno fiducia. I ruoli possono limitare l’accesso alle sessioni, gli agenti consentiti e gli scope dell’operatore. Le sessioni guest possono inoltre essere obbligate a usare sandbox con workspaceAccess: "none", così gli strumenti per file e shell lavorano in un workspace privato invece che in quello dell’agente condiviso (docs.openclaw.ai). Conserva le bozze private nelle sessioni Draft, ricordando che restano fuori dalle sidebar degli altri utenti ma non sono mai nascoste agli amministratori (docs.openclaw.ai).

Capisci quando smettere di condividere. Un utente che gestisce più agenti ha definito il context bleed la "biggest practical challenge", spiegando che gli agenti "drift into each other's territory" (u/BP041, r/openclaw). I builder cinesi arrivano a una regola ancora più diretta: configura un agente, poi clonalo per ogni macchina — "help it clone to a new device" — così una configurazione ottimizzata diventa "one per person" (x.com). Sincronizza solo memoria e dotfile, lasciando fuori credenziali e sessioni attive (x.com). È la stessa via d’uscita prevista dalla documentazione: vault Memory Wiki per agente (vault.scope = "agent"), directory Markdown condivise in modo esplicito invece della ricerca incrociata nelle trascrizioni e Gateway separati quando l’isolamento deve essere reale (github.com).

FAQ

Due dispositivi possono condividere contemporaneamente la stessa sessione di un agente OpenClaw?

Sì. Entrambi i dispositivi entrano nella stessa sessione; è la sessione, non il dispositivo, a contenere il contesto. Assegna un proprietario e attiva la modalità coda, così il messaggio del secondo dispositivo resta in attesa (docs.openclaw.ai).

Perché le istruzioni spariscono dopo il compaction, /new o un riavvio?

Perché un messaggio in chat non è un’attività salvata. Il compaction riassume il contesto, /new avvia una sessione vuota e i riavvii eliminano lo stato in memoria. Conserva gli impegni in active-tasks.md e aggiungi un Boot.md che lo rilegga (x.com).

Due persone dovrebbero condividere un agente o usarne uno a testa?

Condividi un agente quando entrambe hanno bisogno dello stesso thread, della stessa memoria e della stessa coda. Usa un agente a testa, o un Gateway a testa, quando cronologia, credenziali o permessi non devono mescolarsi: le funzioni multi-user non forniscono isolamento di sicurezza (docs.openclaw.ai). La guida condivisa può aggiungere trailer di commit Co-authored-by quando l’attribuzione GitHub è configurata (docs.openclaw.ai).

Condividere o clonare: scegli in 30 secondi

La modalità coda impedisce a due persone di parlarsi sopra, ma non risolve le istruzioni in conflitto: gli input fusi possono comunque mescolarsi. Il file, invece, mantiene vive le istruzioni anche dopo un riavvio.