Agentes compartilhados multiplayer no OpenClaw: dois dispositivos, um contexto

Dois dispositivos podem usar o mesmo agente do OpenClaw com segurança — desde que você trate a fila como texto e a persistência como uma tarefa separada. A sessão compartilhada mantém o contexto; arquivos como active-tasks.md guardam os compromissos.

Essa distinção é o ponto central. O OpenClaw 2.0 (versão v2026.8.1, anunciada em 30 de agosto de 2026) adicionou sessões compartilhadas multiplayer sobre um Gateway que continua sendo um único domínio de confiança. Assim, dois celulares, dois notebooks ou duas pessoas podem conduzir a mesma execução sem que cada um receba uma cópia privada (docs.openclaw.ai). A documentação oficial deixa claro que propriedade, presença e funções são recursos de coordenação, não mecanismos de isolamento entre usuários mal-intencionados (docs.openclaw.ai). E é justamente aí que a prática costuma divergir da teoria: fila, duração da sessão e memória são os pontos que mais causam problemas.

Celular no sofá, notebook na mesa: o que costuma dar errado

Um cenário comum com dois dispositivos nem envolve duas pessoas. É uma única pessoa usando o celular como controle remoto e um Mac Mini ou VPS como host, muitas vezes via Telegram. Um usuário descreveu a situação de forma direta: pedir "my openclaw agent Monica from telegram to install mem0 locally on my mac mini" (x.com).

Quando um segundo dispositivo ou uma segunda pessoa entra na mesma sessão, quatro tipos de falha aparecem com frequência:

1. Mensagens desaparecem sem aviso. Uma das recomendações mais repetidas pela comunidade é ativar o modo de fila para que as mensagens nunca sejam descartadas silenciosamente, combinando isso com active-tasks.md como estado persistente para recuperação após falhas e um Boot.md que releia o arquivo durante a inicialização (x.com). Sem essa combinação, uma mensagem enviada enquanto o agente está no meio de uma rodada é apenas texto da conversa em risco — não uma tarefa salva.
2. As instruções somem depois da compactação ou reinicialização. Um usuário do Reddit resumiu o problema:

"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

No mesmo tópico, usuários relatam que promessas desaparecem depois da compactação ou reinicialização, e que o agente deixa de seguir runbooks salvos. Outra explicação, feita por um mantenedor, descreve o padrão por trás do problema: um agente que "works perfectly for 20 minutes" e depois "silently forgets your instructions and goes rogue" quando o gerenciamento de memória é mal compreendido (x.com).

1. A sessão é redefinida no meio do trabalho. Os padrões de canais do Telegram já incluíram thread: { mode: "idle", idleMinutes: 180 }, que reinicia a sessão depois de algumas horas sem atividade. Um usuário alterou o valor para 4 dias após enfrentar esquecimentos em uma configuração que usava o celular como segunda tela (x.com). O excesso de contexto piora tudo: uso intenso de ferramentas pode fazer a última mensagem ser reinserida, levando o agente a "responds to the same thing over and over" e depois "silently degrades" (x.com).
2. O pareamento falha antes mesmo de o multiplayer começar. Depois de uma atualização, dispositivos pareados perderam os escopos operator.read/operator.write e entraram em um loop infinito de pareamento, com as ferramentas inutilizadas. O fundador respondeu: "This was me being overzealous in fixing a potential security issue" (x.com). Usuários de língua chinesa enfrentaram o mesmo problema com o erro 1008: pairing required, enquanto o dispositivo local ficava preso na fila Pending até a execução de openclaw devices list e depois devices approve <UUID> (x.com).

A presença mostra quando alguém está digitando, mas nenhum indicador transforma uma mensagem enfileirada em uma tarefa salva.

Um Gateway, um domínio de confiança: sessão compartilhada, agentes separados e responsabilidades

A principal novidade do OpenClaw 2.0 são as sessões compartilhadas: outra pessoa pode entrar em um trabalho em andamento sem perder o contexto. Avaliações independentes trataram isso como a transição de um fluxo operado por uma pessoa para um trabalho colaborativo (eesel.ai). Por baixo dessa camada, dois conceitos da documentação oficial definem qual configuração faz sentido.

O modo multiusuário permite que várias pessoas confiáveis operem um único agente. Cada sessão compartilhada registra três camadas: um criador imutável (createdActor, gravado uma única vez), um responsável que pode ser atribuído — como um assignee no GitHub — e um histórico dos participantes que efetivamente enviaram prompts (docs.openclaw.ai). A presença mostra quem está visualizando ou digitando, mas rascunhos nunca chegam ao modelo nem à transcrição. A atribuição de cada rodada é explicitamente uma aproximação, já que a condução pode combinar as entradas de várias pessoas em uma única rodada (docs.openclaw.ai). Na prática, uma mensagem enviada por um segundo canal enquanto o agente executa uma ferramenta entra na transcrição, mas a rodada em andamento termina primeiro. A segunda instrução funciona como uma orientação para a próxima rodada, não como uma interrupção (docs.openclaw.ai).

O modo multiagente permite que um único processo do Gateway hospede vários cérebros isolados, cada um com seu próprio workspace, agentDir (perfis de autenticação e registro de modelos) e banco SQLite de sessões em <agentDir>/openclaw-agent.sqlite (github.com). Um binding encaminha cada evento recebido de um canal para um agente; a correspondência mais específica vence. Nunca reutilize o mesmo agentDir entre agentes, pois eles podem sobrescrever o auth-profiles.json uns dos outros (stack-junkie.com). Um exemplo mínimo: { agentId: "coding", match: { channel: "telegram", accountId: "coding-bot" } } encaminha um bot para um agente específico.

A frase sobre confiança que vale memorizar é: "A gateway is one trust domain" (docs.openclaw.ai). Funções, filtros de responsável e avatares não isolam usuários mal-intencionados. Quando os usuários não confiam uns nos outros, use Gateways separados — idealmente também usuários ou hosts distintos no sistema operacional.

Para dois dispositivos da mesma pessoa, escolha a coluna da esquerda. Para duas pessoas que não deveriam ver regularmente o histórico uma da outra, escolha a coluna da direita. Quando o acesso precisar ser realmente protegido contra usuários não confiáveis, use dois Gateways. As recomendações do Reddit para casais que compartilham um bot seguem essa direção: "create 2 agents, same auth profile, but 1 geared towards you... and the other to your wife" (u/mr-cto-apps, r/openclaw). Em outro tópico sobre compartilhar um único bot do Telegram, um usuário aconselha que "most people in your situation just run two instances" (u/dertobi, r/openclaw) — conselho que continua válido para trabalhos privados separados, mesmo depois de o 2.0 adicionar sessões compartilhadas.

Para onde vai a segunda mensagem enquanto o agente está ocupado

Pense em três compartimentos, porque é comum confundi-los e perder trabalho justamente na fronteira entre eles.

Compartimento 1: a fila da sessão. O texto enviado enquanto o agente trabalha é anexado à sessão atual. O modo de fila faz a mensagem esperar em vez de descartá-la, e a presença indica que o agente está no meio de uma rodada. Nesse caso, sua mensagem orienta a próxima rodada, sem interromper a atual. As prévias de digitação são temporárias e nunca entram no contexto (docs.openclaw.ai). Mantenha as mensagens enviadas pelo segundo dispositivo curtas e explícitas, como "depois que isso terminar, faça X; não reinicie Y", porque a documentação trata a atribuição de rodadas como uma aproximação quando as orientações de várias pessoas são combinadas (docs.openclaw.ai).

Compartimento 2: tarefas persistentes. Uma mensagem na fila não é uma tarefa durável. Se o Gateway reiniciar, a sessão for compactada ou você usar /new, promessas feitas na conversa podem desaparecer. A solução comunitária que sobrevive a reinicializações é um arquivo, não uma mensagem: active-tasks.md como estado de recuperação após falhas, junto de um Boot.md que o agente lê ao reiniciar a sessão ou o Gateway (x.com). Ferramentas de memória podem reinjetar contexto, mas uma explicação bastante compartilhada alerta que a própria memória carregada pode ser resumida e perdida: "The memory exists on disk. The agent just lost the ability to walk through it" (x.com).

Compartimento 3: trabalho agendado. Cron e Automations funcionam enquanto o Gateway estiver rodando; se o host entrar em suspensão, os agendamentos param (eesel.ai). Um usuário relatou que as execuções de cron tornavam o agente "basically unusable during that time" porque o histórico da sessão inundava o contexto, e recomendou isolar os contextos por tópico do Telegram (x.com). Use jobs agendados para trabalhos recorrentes, nunca como substituto para colocar uma instrução de acompanhamento na fila.

A visualização da fila pode ficar atrasada em relação ao estado real: um tópico relatou que as solicitações apareciam claramente na fila enquanto /subagents e /tasks não mostravam nada (reddit.com). Trate o arquivo do segundo compartimento como a verificação de sobrevivência segura para reinicializações, independentemente do que a interface da fila mostrar.

A configuração com dois dispositivos que não perde instruções

Esta configuração serve para uma pessoa usando notebook e celular ou para dois colegas de confiança em uma sessão compartilhada. Ela segue os guias oficiais de configuração rápida e operação em produção (docs.openclaw.ai), com os ajustes de prevenção de perdas adotados pela comunidade.

1. Coloque o Gateway em um host sempre ligado e acesse-o por identidade. Um VPS pequeno, um Mac do escritório ou um Mac Mini funcionam. Faça o Gateway escutar no loopback e use Tailscale Serve ou Cloudflare Access na frente dele, em vez de expor uma porta pública ou compartilhar um token. O acesso baseado em identidade é o que permite atribuir pessoas às sessões e dar crédito nos commits; com um token compartilhado, todos acabam usando o mesmo perfil de proprietário (docs.openclaw.ai).
2. Conecte os dois dispositivos à mesma sessão, não a duas sessões. Abra a Control UI ou o canal de chat em cada dispositivo, defina explicitamente o responsável pela sessão (Control UI Assign to me / Assign to, ou a ferramenta sessions com assign_owner) e use @menções para passar o trabalho adiante. DMs e salas de grupo exigem allowlists separadas (docs.openclaw.ai). Trocar o responsável muda a responsabilidade, mas não altera o compartilhamento vinculado ao criador nem a autoridade sobre o arquivo. Por isso, mantenha o criador estável.
3. Ative a fila e faça o trabalho sobreviver às reinicializações. Mude a sessão compartilhada para o modo de fila, para que uma mensagem enviada no meio da rodada espere em vez de competir com ela — sem essa opção, usuários relatam que mensagens podem desaparecer silenciosamente. Mantenha um active-tasks.md no workspace, com uma linha por compromisso (concluído / em andamento / próximo), e adicione um Boot.md instruindo o agente a ler o arquivo na inicialização (x.com). Teste se o modelo responde antes de depender do segundo dispositivo, pois salvar as credenciais não confirma que a configuração funcionou (docs.openclaw.ai).
4. Aumente a duração da sessão nos canais acessados pelo celular. Se o Telegram for a segunda tela e o tópico usar o reset informado thread: { mode: "idle", idleMinutes: 180 }, aumente esse período para trabalhos longos — um usuário chegou a 4 dias — e mantenha os tópicos separados para que a saída do cron não inunde o contexto compartilhado.
5. Dê a cada pessoa sua própria conta de modelo. Os perfis do Gateway podem armazenar credenciais pessoais. Novas sessões priorizam o padrão pessoal sem alterar o padrão do Gateway, e os demais usuários veem apenas um rótulo no nível da pessoa, não o e-mail ou o ID da conta (docs.openclaw.ai). As credenciais devem ser inseridas pela interface protegida ou por prompts ocultos no terminal, nunca coladas na conversa, onde acabariam na transcrição compartilhada.
6. Faça um teste de ponta a ponta. No segundo dispositivo, envie uma mensagem durante uma rodada e confirme que ela foi retida e processada depois que a rodada ativa terminar. Em seguida, reinicie o Gateway e confirme que active-tasks.md recupera o compromisso. O checklist oficial de produção termina da mesma forma: verifique todo o fluxo antes de considerá-lo concluído (docs.openclaw.ai).

Regras para impedir que o contexto compartilhado se deteriore

Três regras cobrem a maior parte da deterioração descrita pelos usuários.

Identifique toda gravação de memória. O problema mais silencioso é o acúmulo de regras sem autoria, até que ninguém se sinta autorizado a removê-las: "six months in the shared context is full of rules nobody can trace to a person, so nobody feels allowed to delete them", com a sugestão de colocar "author on every memory write" (x.com). O padrão problemático é compartilhar gravações sem registrar quem as fez. Prefixe as notas duráveis com quem pediu e quando; faça uma limpeza mensal.

Coloque o usuário de menor confiança em um sandbox. As funções podem limitar o acesso às sessões, os agentes permitidos e os escopos do operador. Sessões de convidados podem ser forçadas a usar sandboxes com workspaceAccess: "none", fazendo com que as ferramentas de arquivos e shell usem um workspace privado em vez do workspace compartilhado do agente (docs.openclaw.ai). Mantenha rascunhos privados em sessões Draft. Eles não aparecem nas barras laterais de outros usuários, mas nunca ficam ocultos para administradores (docs.openclaw.ai).

Saiba quando parar de compartilhar. Um operador de vários agentes chamou o vazamento de contexto de "biggest practical challenge", dizendo que os agentes "drift into each other's territory" (u/BP041, r/openclaw). Desenvolvedores de língua chinesa convergem para uma regra mais direta: ajuste um agente e depois clone-o por máquina — "help it clone to a new device" para transformar uma configuração ajustada em "one per person" (x.com) — sincronizando apenas a memória e os dotfiles, enquanto credenciais e sessões ativas ficam para trás (x.com). Isso corresponde à própria alternativa indicada na documentação: cofres de Memory Wiki separados por agente (vault.scope = "agent"), diretórios Markdown compartilhados de forma explícita em vez de busca cruzada nas transcrições e Gateways separados quando o isolamento precisa ser real (github.com).

FAQ

Dois dispositivos podem compartilhar a mesma sessão de agente do OpenClaw ao mesmo tempo?

Sim. Os dois dispositivos entram na mesma sessão; é a sessão, e não o dispositivo, que mantém o contexto. Defina um responsável e use o modo de fila para que a mensagem do segundo dispositivo espere (docs.openclaw.ai).

Por que as instruções desaparecem depois da compactação, de /new ou de uma reinicialização?

Porque uma mensagem de chat não é uma tarefa armazenada. A compactação resume o contexto, /new começa uma sessão nova e as reinicializações eliminam o estado mantido na memória. Guarde os compromissos em active-tasks.md e use um Boot.md para relê-los (x.com).

Duas pessoas devem compartilhar um agente ou usar um agente para cada uma?

Compartilhe um agente quando as duas pessoas precisam da mesma conversa, memória e fila. Use um agente para cada pessoa — ou um Gateway para cada uma — quando históricos, credenciais ou permissões não puderem se misturar; os recursos multiusuário não oferecem isolamento de segurança (docs.openclaw.ai). Quando a atribuição do GitHub estiver configurada, a condução compartilhada pode incluir trailers de commit Co-authored-by (docs.openclaw.ai).

Compartilhar ou clonar: escolha em 30 segundos

O modo de fila impede que dois usuários digitando ao mesmo tempo falem por cima um do outro, mas não resolve instruções conflitantes — a entrada combinada ainda pode misturar orientações. Já o arquivo mantém as instruções vivas depois da reinicialização.