Como passar uma tarefa do OpenClaw 2.0 para outra pessoa sem perder o contexto

Fala aí, beleza? Sabe aquele momento em que você passou a manhã inteira conversando com o agente, ele já entendeu a estrutura do projeto, já sabe o que deu errado, e aí você precisa entregar a tarefa pra outra pessoa?

Normalmente é aqui que tudo desanda

O colega abre uma sessão nova, começa do zero, e você vira uma máquina de copiar e colar explicação no chat

O OpenClaw 2.0 (v2026.8.1, lançado em 31 de agosto de 2026) atacou justamente isso com sessões compartilhadas na nuvem, o tal modo multiplayer: várias pessoas entram em uma conversa em andamento, contribuem com o contexto que já existe ou assumem o trabalho por completo

E olha, isso não é detalhe: antes do 2.0 simplesmente não dava pra trazer outra pessoa pra uma sessão existente sem perder o contexto dela

Contexto é o ativo mais frágil de qualquer agente, e quem já se preocupou com o limite de contexto do Claude Code sabe bem do que eu tô falando

No fim deste post você vai saber passar o bastão de uma sessão mantendo o contexto vivo, e (mais importante) vai saber o que a atribuição de dono NÃO faz

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

O que você precisa antes de passar a tarefa adiante

Antes do passo a passo, o cenário mínimo:

• OpenClaw 2.0 rodando em um gateway multiusuário
• Cada colega abrindo a Control UI pelo menos uma vez, porque é assim que ele ganha um perfil durável de Gateway, com nome de exibição, avatar e preferências de aparência por pessoa
• Identidade verificada, se você quiser saber quem é quem de verdade: com Cloudflare Access ou Tailscale Serve, o login via GitHub verifica a conta por trás do perfil
• Um agente configurado, caso você pretenda entregar a sessão pra um agente em vez de uma pessoa: o ownerId precisa nomear um agente que já existe na configuração

E aqui vai o aviso mais importante do post, logo no começo

O modo multiusuário foi feito pra várias pessoas confiáveis operarem o mesmo agente OpenClaw

Propriedade de sessão, visibilidade na barra lateral e indicadores de presença são recursos de usabilidade e coordenação, não uma fronteira de segurança

Se o seu requisito é que as pessoas não consigam acessar sessões, ferramentas, credenciais ou arquivos umas das outras, isso se resolve com agentes separados ou gateways e hosts separados, não com hand off

Passo a passo: hand off de uma sessão do OpenClaw 2.0 sem perder o contexto

1. Defina a visibilidade e os membros da sessão

A participação em sessão compartilhada mantém a atribuição de criador e te deixa determinar quem vê a sessão e quem entra nela

O erro comum deste passo: começar pelo ‘Assign to’ achando que atribuir o dono já coloca a pessoa lá dentro

Não coloca, membro e dono são coisas diferentes

2. Escolha o nível de contribuição de quem está entrando

Donos e administradores definem se o outro participante pode ler a sessão, sugerir mudanças, trabalhar em rascunho (draft) ou contribuir diretamente

O erro comum deste passo: liberar contribuição direta pra todo mundo por preguiça de decidir

3. Acompanhe a chegada da pessoa pelos indicadores da Control UI

A Control UI mostra presença ao vivo: quem está visualizando e quem está digitando

O erro comum deste passo (e esse pega MUITA gente): achar que o rascunho de digitação do colega já virou contexto pro modelo

Não virou

Os drafts de digitação são presença efêmera: nunca são persistidos, nunca entram no transcript da sessão nem no contexto do modelo, e somem pouco depois que a pessoa para de digitar ou envia

Se é pra o agente saber, tem que ser enviado como prompt

4. Atribua o dono da sessão

Aqui tem dois caminhos

Pela interface, o dono é atribuído como se fosse uma issue do GitHub: menu de contexto da sessão, opção ‘Assign to’, em gateways multiusuário

Pela ação assign_owner das session tools, que entrega a responsabilidade da sessão a uma pessoa ou a um agente:

assign_owner
  ownerType: "human"      // ou "agent"
  ownerId:   "id-da-pessoa-ou-do-agente"
  sessionKey: "opcional: outra sessão visível"

Por padrão o alvo é a sessão atual, e você usa sessionKey quando quer reatribuir outra sessão que já enxerga

O erro comum deste passo: mandar ownerType: "agent" com um id qualquer

Ids de agente devem nomear um agente configurado

5. Confirme que o hand off pegou

A Control UI reflete o novo dono imediatamente, e o tooltip do avatar deixa de ser ‘Created by’ e passa a ser ‘Owned by’

A atribuição também registra quem reatribuiu e quando, então dá pra auditar depois quem passou o quê pra quem

O erro comum deste passo: comemorar cedo demais

Reatribuir o dono muda responsabilidade e exibição apenas, e não concede nem remove acesso

6. Opcional: crédito de coautoria no Git

Com o crédito de coautoria Git habilitado, os commits que saem de uma sessão compartilhada carregam trailers Co-authored-by pras pessoas que conduziram o trabalho, e os pull requests gerados linkam de volta pra sessão

É ótimo pra ninguém ficar sem crédito num trabalho que passou por três mãos

O detalhe: o crédito vale pra participantes elegíveis com identidade GitHub verificada, então lembra do passo da verificação lá em cima

Problemas comuns no hand off (e como evitar)

‘Passei o dono, mas a pessoa não consegue compartilhar nem acessar’

Causa: assign_owner muda responsabilidade e exibição, só isso

Ele não transfere a autoridade de compartilhamento (que continua com o criador) e não concede nem remove acesso

Solução: ajustar membros e nível de contribuição à parte, como controles separados da atribuição de dono

‘Tirei o acesso e ele ainda aparece disponível’

Causa: existe uma janela de atraso entre a revogação e o bloqueio efetivo

O acesso revogado pode aparecer brevemente como disponível até a UI atualizar ou o Gateway rejeitar a ação

Solução: não tratar a tela como fonte da verdade instantânea, e não usar isso como mecanismo de segurança

‘A sessão simplesmente não aparece pro colega’

Causa: provavelmente ela ainda está como draft

Dá pra iniciar uma sessão como draft justamente pra manter o trabalho em andamento fora da barra lateral dos colegas até publicar

E tem o caso das threads incognito, que em gateways multiusuário são visíveis apenas para conexões com escopo de admin, nunca aparecem nas session tools de outra sessão nem na busca de transcripts

Solução: publicar o draft antes de chamar alguém

Detalhe curioso: drafts não ficam ocultos pra admins, que os veem com um marcador fantasma esmaecido 🙂

E a prevenção que vale repetir: se a exigência real é isolamento, vai de agentes separados ou gateways e hosts separados

Quando vale a pena usar o hand off de sessão

• Fim de expediente com trabalho pela metade: você atribui o dono, o colega entra na sessão em andamento e continua de onde você parou, com o contexto preservado
• Revisão sem poder de escrita: chama alguém com nível de ler ou sugerir, a pessoa acompanha e propõe, sem meter a mão direto
• Investigação de bug que só acontece na máquina do outro: aquele clássico em que o bug não reproduz na sua máquina fica bem mais fácil quando o colega entra na mesma sessão em vez de receber um print e uma explicação resumida
• Delegar pra um agente: ownerType: "agent" com o id de um agente configurado, e a responsabilidade da sessão vai pra ele
• Trabalhar escondido até ficar apresentável: sessão em draft, publica depois
• Achar o que é seu no meio da bagunça: o cartão de informações de uma pessoa mostra as sessões que ela possui, e o filtro ‘Involving me’ mostra as suas mais aquelas em que você já enviou pelo menos um prompt
• Separar DMs por pessoa: em setups multiusuário dá pra isolar as mensagens diretas por usuário, pra elas não caírem todas na mesma sessão compartilhada, configurando dmScope como per-channel-peer no openclaw.json:

{
  "dmScope": "per-channel-peer"
}

Vídeo: contexto sobre ferramentas de IA para programar

Pra dar um panorama do cenário de ferramentas de IA pra programar, o vídeo do canal ‘IA de programar grátis, sem login e com 1 milhão de contexto (MiMo Code)’ apresenta uma dessas alternativas na prática

Conclusão: o contexto agora fica com a sessão, não com a pessoa

A sacada do modo multiusuário é que a atribuição vive em três camadas: um criador imutável, um dono (owner) atribuível e o histórico de participantes que efetivamente enviaram prompts

Ou seja: o contexto deixa de ser propriedade de quem abriu o chat e passa a morar na sessão

O ganho real não é o botão bonito, é parar de reexplicar tudo do zero toda vez que alguém assume a tarefa

E pra dimensionar de onde isso saiu: o OpenClaw foi iniciado por Peter Steinberger em novembro de 2025 e é mantido por maintainers e milhares de contribuidores no repositório openclaw/openclaw, com o release 2.0 sendo construído por 933 contribuidores e mais de 16 mil pull requests mergeados

Projeto grande, mudança grande

Próximo passo? Publica teu primeiro draft compartilhado, atribui o dono e confere o tooltip virando ‘Owned by’

Depois vale explorar o resto do 2.0: busca em conversas passadas por palavra ou frase exata, cartões de progresso persistentes que sobrevivem a recarregamentos e a visibilidade da atividade de subagentes e das edições acumuladas

Até o próximo post! =)