Sessão compartilhada no OpenClaw 2.0: o que a outra pessoa realmente enxerga?

Convidar alguém para uma sessão do OpenClaw 2.0 não é mandar um print, é abrir um trabalho vivo

Fala aí, beleza? O OpenClaw 2.0 foi anunciado entre 30 e 31 de agosto de 2026 como a maior atualização do projeto até hoje, e o destaque da vez são as shared cloud sessions, ou seja, o agente virou multiplayer

E aí vem a pergunta que ninguém faz antes de clicar em compartilhar: o que a outra pessoa REALMENTE passa a enxergar quando entra ali?

O que mudou no OpenClaw 2.0 e por que a sessão virou multiplayer

O 2.0 não é um retoque de interface

O release veio com shared cloud sessions, onboarding simplificado e um app de navegador reconstruído do zero

A escala do troço é insana: mais de 16.000 pull requests, 933 contribuidores e 569 deles de primeira viagem

Formação Recomendada

Formação Claude Code

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

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

Na interface, o 2.0 acrescentou propriedade de sessão, atribuição de participantes, presença ao vivo e indicadores de digitação

Parece Google Docs, né? É justamente essa a sensação que o produto quer passar

Por baixo, mudou o lugar onde a conversa mora: sessões ativas e transcripts saíram de arquivos JSONL e foram para bancos SQLite locais, num modelo de duas camadas (um arquivo SQLite global para dados de controle do sistema e arquivos SQLite dedicados para estado de workspace e transcripts de cada agente)

Se você já se perguntou o que acontece com a sessão no Claude Code e no OpenCode quando o terminal fecha, o raciocínio aqui é o mesmo: sessão é arquivo, e arquivo alguém lê

Ler, sugerir, rascunho ou participar: o que cada nível de acesso libera

Quem decide o nível do convidado é o dono ou o administrador

São quatro opções, e a diferença entre elas é o tamanho do estrago possível

O modo rascunho é o mais subestimado dos quatro

Como nada dali entra no transcript nem no contexto do modelo, ele serve pra explorar sem sujar a memória da sessão

E no Gateway? A mesma ideia aparece por outro caminho: os papéis de operador são definidos em gateway.roles, e cada definição especifica sessions.others com os valores none, view, suggest ou write, além dos agentes permitidos e um teto fechado de scopes

Então pensa em duas camadas: o nível que o convidado recebe na sessão e o papel do operador no Gateway, que já chega com agentes permitidos e scopes limitados

Quem entra na sessão herda o alcance do agente

Agora a parte que muda tudo

A documentação do OpenClaw diz, com todas as letras, que os controles de sessão compartilhada NÃO são uma fronteira de segurança nem isolamento de tenants

Propriedade da sessão, visibilidade na sidebar e indicadores de presença são recursos de usabilidade

E tem a frase que deveria estar tatuada em quem administra isso: qualquer pessoa capaz de operar um agente pode fazer esse agente executar tudo o que ele é capaz de executar

Traduzindo: o convidado não recebe uma janelinha, ele recebe o alcance do agente

Ferramentas, credenciais e arquivos que o agente já acessa passam a estar, na prática, ao alcance de quem opera

Na cloud session a divisão de trabalho é interessante: comandos, edições de arquivo e trabalho de ferramenta executam remotamente, mas o Gateway continua sendo o dono da conversa, do workspace reconciliado, das credenciais de modelo e dos registros de posicionamento

Ou seja, o processamento sai de casa, o cofre não

E tem um limite importante do lado da rastreabilidade: atribuição e participação nunca concedem acesso à sessão, e o histórico de participantes registra que um ator deu prompt na sessão, não quais palavras foram dele

Atribuição, agregados de participantes e decisões de acesso por criador são contratos separados

A régua saudável, então, é assumir o pior caso e decidir o que entra na sessão ANTES de convidar 😀

Critérios para decidir: o que compartilhar, o que separar e o que nunca deveria estar ali

O que dá pra compartilhar numa boa:

• trabalho vivo com um time que confia mutuamente, que é justamente o cenário que a função foi feita pra atender
• passagem de bastão: a segunda pessoa entra numa sessão em andamento e continua de onde o colega parou, com o contexto preservado
• revisão em nível ler ou sugerir, quando você quer olho de fora sem entregar o volante
• exploração em modo rascunho, quando você não quer aquele conteúdo registrado no transcript nem no contexto do modelo

Se o que você quer é só mostrar o resultado pronto para alguém de fora, isso é outro problema, mais parecido com compartilhar um notebook do NotebookLM do que com abrir um agente

O que é melhor separar:

A orientação da documentação é direta: se as pessoas não podem acessar sessões, ferramentas, credenciais ou arquivos umas das outras, elas devem receber agentes separados ou fronteiras de confiança separadas de gateway/host

Não adianta confiar em avatar de dono nem em filtro de interface, isso é enfeite

Dentro de um time que confia mutuamente, dá pra organizar os contextos sem montar um data center: é possível rodar múltiplos agentes isolados dentro de um mesmo processo de Gateway, cada um com seu workspace, seu diretório de estado (agentDir) e seu histórico de sessões em SQLite

Agora, se as pessoas são mutuamente não confiáveis, o mesmo processo de Gateway não resolve: o modelo suportado é uma fronteira de confiança por Gateway, e aí a receita é Gateway separado, com credenciais separadas

O que NUNCA deveria estar ali:

Credencial, dado de terceiro e assunto privado dentro de uma sessão que outra pessoa pode continuar

O motivo é mecânico, não é paranoia: o escopo do agente inclui arquivos do workspace, perfis de autenticação, registro de modelos e store de sessões

Quem continua a sessão continua com tudo isso por perto

Três armadilhas de privacidade que aparecem depois que a sessão vira compartilhada

Sintoma 1: a mensagem privada apareceu pra todo mundo

Causa: em setups multiusuário sem isolamento de DM ativado, todos os usuários compartilham o mesmo contexto de conversa, e as mensagens privadas de um ficam visíveis para os outros

Com session.dmScope: "main", o DM colapsa na sessão principal e no mesmo escopo de recall

Solução e prevenção: existe dmScope por peer para isolar, e visibility com valor self para deixar o recall restrito à sessão atual

Para isolamento de verdade, o caminho é um agente por pessoa, já que conversas diretas colapsam por padrão na chave da sessão principal do agente

Sintoma 2: a sessão sumiu da lista, ou ninguém enxerga a sessão

Causa: em Gateways multiusuário, uma conexão não administrativa só enxerga, lê, continua ou arquiva as sessões cujo createdActor.id registrado corresponde ao perfil de Gateway de quem chama

E tem o efeito colateral clássico: sessões sem atribuição, criadas via CLI do host ou pelo desktop, ficam ocultas para esses chamadores

Antes de sair achando que perdeu trabalho, confira por qual caminho aquela sessão nasceu

Sintoma 3: tirei o acesso e a pessoa ainda parece ter permissão

Causa: depois de revogar um acesso, a permissão pode continuar parecendo disponível por um breve período, até a interface atualizar ou o Gateway rejeitar a ação

Solução no caso de dispositivo pareado:

openclaw nodes remove --node <id|name|ip>

Esse comando revoga o papel de node do dispositivo no store de dispositivos pareados e desconecta as sessões com papel de node daquele dispositivo

E aqui entra um ponto que muita gente ignora: o LUGAR onde a sessão roda muda o que fica exposto

São três destinos possíveis: o gateway local (padrão), hardware próprio conectado via openclaw connect (Paired Devices) ou máquinas descartáveis alugadas pela ferramenta de provisionamento Crabbox, que suporta backends como AWS e Hetzner

Compartilhar uma sessão que roda na sua máquina de trabalho não é a mesma conversa que compartilhar uma que roda numa máquina descartável, beleza?

Vale compartilhar sessão? O veredito honesto

O modelo suportado é uma fronteira de confiança por Gateway

Um operador, ou um time que confia mutuamente, de preferência um usuário de SO, host ou VPS por fronteira

Gateway ou agente compartilhado entre usuários mutuamente não confiáveis simplesmente não é suportado: nesse caso a receita é Gateway separado com credenciais separadas

Do lado da imprensa especializada o tom também é de pé atrás: em 31/08/2026, o The Register avaliou que as notas de versão do 2.0 endereçam pouco dos riscos de segurança acumulados do projeto

Vale lembrar que o projeto já tinha publicado antes uma versão focada em segurança, a 2026.2.12, que corrigiu mais de 40 issues

Veredito: pra colaboração dentro de um time que confia mutuamente, a sessão compartilhada é mto massa e resolve um problema real, que é perder contexto na troca de mãos

Como controle de acesso, é inadequado, e quem diz isso primeiro é a própria documentação

Conclusão

A régua cabe numa frase: filtro de interface não é isolamento

Então, antes de convidar alguém para uma sessão compartilhada no OpenClaw 2.0, faz esse checklist rápido:

1. revise o que o agente alcança de verdade (ferramentas, credenciais, arquivos do workspace, perfis de autenticação)
2. escolha o nível de acesso MÍNIMO que resolve o problema, e lembre que no Gateway isso vive em sessions.others com none, view, suggest ou write
3. se a resposta pra pergunta "eu confio totalmente nessa pessoa com tudo isso?" for não, abra um agente ou um Gateway separado em vez de compartilhar a sessão

Sessão multiplayer é conveniência

Fronteira de confiança é arquitetura, e essas duas coisas não se substituem…

até o próximo post! 🙂