Sessões em nuvem compartilhadas do OpenClaw 2.0: o que muda quando o agente vira multiplayer?

Fala aí, beleza? O agente de IA acabou de deixar de ser aquela conversa privada entre você e o terminal, e virou um lugar onde mais gente entra e senta junto

O OpenClaw 2.0 corresponde ao release v2026.8.1, com a tag publicada no repositório oficial em 31 de agosto de 2026, às 03:30 UTC (ou seja, ainda dia 30 pra quem tava nos fusos dos EUA)

O projeto apresenta essa como a maior atualização da sua história, e o pedaço que mais mexe com a rotina de quem trabalha em time é justamente esse: as sessões compartilhadas…

OpenClaw 2.0: o release que trouxe o modo multiplayer

O número é bonito de olhar: mais de 16.000 pull requests mesclados, vindos de 933 contribuidores

E se liga nisso: dos 933, 569 contribuíram pela primeira vez

Ou seja, mais da metade do release veio de gente de primeira viagem, o que diz bastante sobre o tamanho que o projeto tomou

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 108 aulas
• 4 projetos
• 9h

Conhecer formação

O OpenClaw é um agente de IA gratuito e de código aberto sob licença MIT, hoje mantido pela OpenClaw Foundation junto com Peter Steinberger

A Foundation foi anunciada em 8 de julho de 2026 como organização sem fins lucrativos 501(c)(3), assumindo a curadoria do projeto com o compromisso de manter o OpenClaw sob licença MIT, aberto e independente

O 2.0 também traz uma interface de navegador reconstruída, que junta conversas, arquivos, aprovações, configuração e atividade do agente ao vivo em um mesmo espaço de trabalho

Guarde essa parte, porque é ali que o multiplayer aparece pra você

Agente pessoal x agente que a equipe acompanha junto

Antes o desenho era simples: uma pessoa, uma transcrição, um contexto que só existia pra quem abriu aquela sessão

Se o colega precisasse entrar, o caminho era copiar e colar transcrição, resumir o que já tinha rolado e torcer pra não perder nada no meio

Agora as sessões compartilhadas permitem que mais de uma pessoa entre em um trabalho já em andamento, continuando ou assumindo a sessão, sem descartar o contexto que o agente já acumulou

Isso é o takeover, e ele é a diferença real

As três camadas de atribuição:

O modo multiusuário dá a cada sessão três camadas de atribuição, e vale entender cada uma porque elas resolvem confusões diferentes:

• Criador imutável: quem abriu a sessão, e isso não muda
• Dono atribuível: a sessão pode ser designada a alguém pelo menu de contexto, exatamente como você atribui uma issue do GitHub pra alguém do time
• Histórico de participantes: o registro de quem realmente enviou prompts ali dentro

Repara que "quem criou", "quem é responsável agora" e "quem mexeu" são três perguntas diferentes

O multiplayer não força as três a serem a mesma pessoa, e é por isso que passar trabalho adiante funciona sem virar bagunça

Presença ao vivo:

A sessão compartilhada mostra presença ao vivo: quem está vendo e quem está digitando, com indicador de digitação acima do campo de mensagem

E aqui tem um detalhe MUITO bem pensado: os rascunhos digitados por participantes não chegam ao modelo nem à transcrição

Ou seja, você pode escrever, apagar, repensar a frase três vezes, e nada disso entra no contexto do modelo nem no histórico

Só o indicador de digitação aparece pros outros, o texto em si não

Os modos de compartilhamento: somente leitura, sugestão e rascunho

Os modos de compartilhamento incluem somente leitura, sugestão e rascunho

A melhor forma de entender é pelo que a pessoa PODE e o que ela não pode fazer:

No modo somente leitura, quem não é membro pode assistir, mas não pode enviar mensagem, direcionar, abortar, aprovar nem alterar o estado da sessão

É o modo "olha, mas não encosta", e ele é mais útil do que parece

No modo de sugestão, o espectador envia sugestões que o dono da sessão ou uma conexão operator.admin pode enviar, enfileirar, editar ou descartar

O espectador não ganha acesso direto de envio, então a sugestão sempre passa por alguém antes de virar prompt de verdade

Quem escolhe o modo?

O dono da sessão e conexões com operator.admin escolhem o modo de colaboração por sessão

Todos os flags vêm ligados (true) por padrão, e desligar um flag remove a opção da Control UI

Tome cuidado com isso: se você desliga um flag achando que está só "escondendo", a opção some da interface pra todo mundo naquele contexto

E os escopos de operador?

Além do modo por sessão, existem escopos de operador, que funcionam num nível acima:

• view: permite ler, mas não alterar, mesmo em sessão compartilhada
• write: permite participar de sessões de outras pessoas, sem passar por cima das restrições que valem naquela sessão
• admin: o escopo com poder de administração das conexões

Dá pra pensar assim: o escopo diz o que a pessoa É no Gateway, e o modo de compartilhamento diz o que ela pode fazer NAQUELA sessão

Em que tipo de trabalho o agente multiplayer compensa

Bora sair do conceito e olhar cenário concreto

Passar um trabalho longo adiante. Aquela sessão que já rodou por horas e acumulou contexto pesado não precisa mais morrer com você, o takeover deixa outra pessoa assumir de onde parou

Acompanhar sem interferir. O modo somente leitura resolve o clássico "quero ver o que o agente tá fazendo, mas não quero atrapalhar a execução"

É o cenário de onboarding, de code review em tempo real, ou simplesmente de quem quer entender como o colega conduz o agente

Revisão a quatro mãos. Com o modo de sugestão, o segundo par de olhos manda a ideia e o dono decide se envia, enfileira, edita ou descarta

A responsabilidade continua com uma pessoa só, o que evita dois prompts conflitantes chegando ao mesmo agente

Distribuir sessão como se distribui issue. Atribuir dono pelo menu de contexto transforma a sessão em unidade de trabalho rastreável, não em conversa perdida no histórico de alguém

E tem o cenário que eu acho o mais subestimado: a sessão que sobrevive à máquina

Se o cloud worker morre ou é suspenso por ociosidade, a sessão continua na barra lateral, e a próxima mensagem provisiona uma substituta

Quem já pensou em como agentes se recuperam de falhas sabe que continuar é sempre melhor que recomeçar do zero

Sessões em nuvem: onde o trabalho roda e onde o estado fica

O OpenClaw 2.0 oferece três locais de execução para uma sessão (os placements):

1. O próprio Gateway, que é o padrão
2. Um dispositivo pareado, conectado com o comando openclaw connect
3. Um cloud worker, provisionado pelo plugin Crabbox

A regra que importa: máquina descartável, sessão durável

Essa é a parte que eu acho mais elegante do desenho

Nas sessões em nuvem, a máquina é descartável mas a sessão não

Transcrição, arquivos do workspace reconciliados por último, histórico de placement e as credenciais de provedor ficam com o Gateway, em TODOS os placements

A máquina remota é só músculo, o cérebro e a memória continuam em casa

E as credenciais?

A inferência do modelo continua passando pelo Gateway

Isso significa que as credenciais de provedor não chegam à máquina remota, o que muda bastante a conta de risco de rodar coisa em nuvem efêmera

Como se configura:

Para usar cloud sessions, configura-se um perfil em cloudWorkers.profiles

O plugin Crabbox faz o resto do trabalho sujo:

1. Provisiona a máquina sob demanda
2. Roda o comando de setup
3. Inscreve a máquina como nó temporário
4. Derruba tudo quando a sessão termina

O Crabbox suporta provedores como AWS, Azure, Azure Dynamic Sessions, Google Cloud, Hetzner e Proxmox

Então você não fica preso a uma nuvem só, dá pra usar o que o time já tem contratado

Multiplayer não é multi-tenant: o limite de segurança que a documentação deixa explícito

Agora a parte que muita gente vai ler rápido demais, e não devia

A documentação oficial afirma que propriedade de sessão, visibilidade na barra lateral e indicadores de presença são recursos de USABILIDADE, não fronteiras de segurança

Um Gateway compartilhado continua sendo um único domínio de confiança para sessões, ferramentas, credenciais e arquivos

A frase que resume tudo: quem pode operar o agente pode fazer tudo o que aquele agente faz

Todo operador herda a capacidade total do agente, ponto

O que isso quer dizer na prática?

A documentação é direta: o OpenClaw não é uma fronteira de segurança multi-tenant hostil

Usuários mutuamente não confiáveis ou adversariais exigem gateways separados, com credenciais separadas e, de preferência, usuários de sistema ou hosts separados

O suportado é: um trust boundary por gateway

O não suportado é: gateway compartilhado entre usuários adversariais

Então antes de sair adicionando gente, a pergunta certa não é "que permissão eu dou pra essa pessoa", é "essa pessoa cabe dentro do mesmo domínio de confiança que eu?"

Como as pessoas entram:

Usuários do Gateway são criados pela linha de comando:

openclaw gateway users create --id --name --role --allowed-channels

O comando aceita parâmetros como --id, --name, --role e --allowed-channels, e devolve um token por usuário

Depois disso, cada colega abre a Control UI pelo ingress e ganha um perfil durável no Gateway, com nome de exibição, avatar e preferências de aparência por pessoa

É o suficiente pra sessão compartilhada parar de ser um monte de "usuário anônimo" e virar gente com cara e nome na transcrição

Vídeo: agentes de IA na prática

Pra começar do zero com agentes de IA e entender a lógica de um agente que decide e executa sozinho, este vídeo do canal mostra o conceito rodando na prática dentro do n8n

É conteúdo geral sobre agentes de IA, serve como base antes de você mergulhar nas especificidades do OpenClaw 2.0

O que fazer agora com o agente multiplayer

O salto real do OpenClaw 2.0 sessões compartilhadas não é "mais gente na mesma tela"

É o contexto que sobrevive a duas trocas: a troca de PESSOA (takeover sem perder transcrição) e a troca de MÁQUINA (cloud worker morre, sessão continua)

Esse é o tipo de mudança que só aparece de verdade em quem já perdeu contexto valioso por um motivo bobo, seja um colega que precisou assumir, seja uma máquina que caiu

E tem o custo, que a própria documentação faz questão de escrever com todas as letras: o Gateway é um só domínio de confiança

De forma parecida com quem se preocupa com quanto contexto o agente carrega antes de agir, aqui a pergunta é de escopo: o que esse agente alcança, alcança pra todo mundo que entrar

Então o próximo passo concreto é bem menos glamouroso que sair testando: decidir se o seu time cabe num único trust domain ANTES de abrir a sessão pra mais gente

Se cabe, vale explorar a Control UI reconstruída, que junta conversas, arquivos, aprovações, configuração e atividade do agente ao vivo no mesmo espaço

Se não cabe, a resposta da documentação é gateway separado, e não permissão mais apertada

Agora bora ver isso rodando 😀

até o próximo post!