Imagine a cena. Você está mergulhado em uma base de código, com seu assistente de IA ajustado do jeito que você gosta. Suas preferências de modelo, suas instruções personalizadas, suas ferramentas permitidas, seu workflow. Aí um colaborador entra no seu workspace para ajudar em uma funcionalidade. Hoje, ele tem duas opções: usar a sua configuração de IA e perder tudo o que deixa o workflow dele rápido, ou trabalhar em um ambiente separado e perder a possibilidade de mexer nos seus arquivos. As duas são péssimas.

Estamos construindo algo diferente. Chamamos de Traga a sua CLI.

O problema de que ninguém fala

O desenvolvimento assistido por IA tem um problema de colaboração. Toda ferramenta de programação com IA hoje é, na essência, single-player. Sua instância do Claude Code, sua chave de API, suas configurações, seu contexto. Tudo bem quando você trabalha sozinho. Mas software não se faz sozinho.

Pair programming remoto, contribuições open source, sessões de depuração em equipe, revisões de código em que você quer mesmo rodar o código. Todos esses cenários esbarram no mesmo obstáculo: de quem é a IA?

O SynaBun já resolveu a primeira metade disso. Nosso sistema de convites permite compartilhar o workspace inteiro com outra pessoa. Ela vê seu terminal, seu navegador, seus cartões de memória, seu quadro branco. Pode interagir com a sua sessão do Claude Code em tempo real. Funciona. As pessoas usam. Mas existe uma limitação fundamental que sempre reaparece.

Quando um convidado usa a CLI do anfitrião, ele está pegando emprestado o cérebro de outra pessoa. Perde as preferências de modelo, as instruções personalizadas, as permissões de ferramentas, tudo o que faz o workflow de IA dele ser dele.

O que Traga a sua CLI significa de verdade

O conceito é simples. Quando você é convidado para o workspace do SynaBun de alguém, você escolhe. Usar a IA do anfitrião, como antes, ou trazer a sua. Se trouxer a sua, você informa sua chave de API e, se quiser, sua preferência de modelo e suas instruções personalizadas. O servidor do anfitrião inicia um processo do Claude Code separado, só para você, rodando com a sua configuração, mas apontado para os arquivos do projeto do anfitrião.

A sua IA. A base de código dele. O mesmo workspace.

Pare um segundo para absorver isso. Dois desenvolvedores, cada um com o próprio agente de IA, ambos lendo e escrevendo no mesmo projeto. Cada agente tem sua personalidade, seu contexto, seu jeito de resolver problemas. Um pode estar rodando o Opus para trabalho pesado de arquitetura enquanto o outro roda o Sonnet para iterar rápido. Um pode ter permissões de ferramentas rígidas enquanto o outro roda totalmente autônomo. Os dois operando nos mesmos arquivos, em tempo real.

Por que isso muda tudo

Isso não é só um recurso de conveniência. Muda de forma fundamental a cara da colaboração assistida por IA.

Cada desenvolvedor mantém a sua vantagem

Desenvolvedores passam semanas ajustando a configuração de IA. Instruções personalizadas no CLAUDE.md que codificam seu estilo de programar. Preferências de modelo de acordo com o tipo de trabalho que fazem. Permissões de ferramentas configuradas para a sua tolerância a risco. Esse ajuste tem valor. Perdê-lo toda vez que você colabora com alguém é como ser obrigado a usar o layout de teclado de outra pessoa.

Agentes de IA em paralelo na mesma base de código

Com o BringCLI, dois agentes de IA podem trabalhar na mesma base de código ao mesmo tempo. O Claude de um desenvolvedor cuida da API do backend enquanto o do outro cuida dos componentes do frontend. Sem malabarismo de branches, sem conflitos de merge por trabalhar isolado. Desenvolvimento multiagente em tempo real, no mesmo diretório.

Cada um paga pela própria IA

Cada desenvolvedor usa a própria chave de API. O anfitrião não paga a conta do uso de IA de todo mundo. O controle de custos é por usuário, transparente e com teto. O anfitrião define um gasto máximo por sessão de convidado. Sem surpresas.

Confiança sem abrir mão do controle

O anfitrião mantém o controle total. Ele vê cada sessão de CLI de convidado ativa, qual modelo ela está rodando, quanto já custou, e pode encerrá-la na hora se precisar. Os convidados têm acesso aos arquivos do projeto, mas não aos segredos, às chaves de API nem à configuração de sistema do anfitrião. É controle granular de permissões, não um compartilhamento de tudo ou nada.

A arquitetura por baixo do capô

Pesquisamos isso a fundo antes de escrever uma única linha de código. A arquitetura a que chegamos é simples, mas bem pensada.

Quando um convidado ativa o BringCLI, ele envia sua chave de API da Anthropic pela interface do SynaBun. A chave é criptografada em repouso com AES-256-GCM e um segredo do lado do anfitrião que nunca sai da máquina. Quando o convidado inicia uma sessão do Claude, o servidor cria um processo dedicado usando o binário do Claude Code do anfitrião, mas com a chave de API do convidado injetada no ambiente.

O processo do convidado roda em sandbox. Ele opera no diretório do projeto do anfitrião, mas recebe um ambiente com lista de permissões. Só as variáveis de sistema essenciais passam. As chaves de API, os tokens e os segredos do anfitrião são removidos por completo. Nenhum hook do SynaBun é injetado no processo do convidado. Ele roda o Claude Code puro, com a identidade do convidado.

Cada convidado tem sua própria conexão WebSocket em um endpoint dedicado. O protocolo de mensagens é idêntico ao do anfitrião, então a interface atual do painel do Claude funciona sem mudanças. O servidor só encaminha as mensagens para o processo certo, de acordo com quem as enviou.

Segurança: as perguntas difíceis

Compartilhar um workspace com a IA de outra pessoa levanta questões reais de segurança. Pensamos em cada uma delas.

  • Segurança da chave de API. As chaves dos convidados são criptografadas em repouso e só são descriptografadas em memória na hora de criar o processo. Nunca aparecem em logs, mensagens de erro ou saída de depuração. A conexão exige HTTPS.
  • Isolamento dos segredos do anfitrião. Os processos dos convidados recebem um ambiente com lista de permissões. Não nos limitamos a remover os segredos conhecidos. Só deixamos passar variáveis explicitamente seguras, como PATH, HOME e TEMP. Todo o resto fica de fora por padrão.
  • Proteção de recursos. Cada sessão de convidado tem um teto de custo e um tempo limite de inatividade, e o anfitrião pode definir um número máximo de processos de convidados simultâneos. Agentes fora de controle são encerrados automaticamente.
  • Acesso a arquivos. Os convidados podem ler e escrever arquivos do projeto, o mesmo nível de acesso que já têm com a permissão de terminal. O anfitrião precisa optar por isso explicitamente. Não há BringCLI sem que o anfitrião o ative.
  • Ciclo de vida do processo. Quando o WebSocket fecha, o processo morre. Nada de agentes órfãos rodando em segundo plano.

Como isso funciona na prática

Você está trabalhando em um projeto no SynaBun. Um amigo quer ajudar a depurar um problema. Você gera um link de convite, ele entra no seu workspace e você ativa a permissão do BringCLI. Ele cola a chave de API em um modal de configuração simples, escolhe o modelo preferido e clica em salvar.

Agora a sua Neural Interface mostra duas sessões de CLI ativas. A sua, no azul padrão. A dele, em âmbar. As duas rodando lado a lado no painel do Claude. Você vê que ele está rodando o Sonnet 4.6 e gastou US$ 0,45 até agora. Ele vê seu projeto, seus arquivos, a saída do seu terminal. Mas as respostas da IA dele vêm da chave dele, do modelo dele, das instruções dele.

Ele encontra o bug. O Claude dele escreve a correção. Você revisa na sua própria sessão do Claude. Duas perspectivas, dois agentes de IA, uma verdade compartilhada: o código em disco.

O quadro geral

Achamos que isso é o começo de algo maior. Hoje, as ferramentas de desenvolvimento com IA são dispositivos pessoais. Sua IA, seu contexto, sua máquina. Mas o desenvolvimento de software de verdade é colaborativo. As ferramentas precisam alcançar essa realidade.

O BringCLI é nosso primeiro passo rumo ao desenvolvimento com IA multiplayer. Não aquele em que todo mundo divide uma única IA. Aquele em que cada participante traz a própria inteligência para a mesa, configurada do jeito que trabalha melhor, operando em terreno comum.

Pense no que vem depois. Uma equipe de cinco desenvolvedores, cada um com a própria instância do Claude, todos trabalhando no mesmo monorepo. Cada uma ajustada para o seu domínio. O Claude do especialista em frontend conhece os padrões de React de cor. O Claude do engenheiro de backend tem instruções rígidas de segurança de tipos. O Claude da pessoa de DevOps está configurado para infraestrutura como código. Todos lendo e escrevendo no mesmo projeto, com visibilidade em tempo real do que cada agente está fazendo.

Isso não é ficção científica. A arquitetura já permite isso hoje. Falta só construir.

O que estamos construindo primeiro

Vamos por fases. A primeira versão foca no essencial: configuração da chave de API, criação de processos separados, controle de custos e controles do anfitrião. Ainda sem servidores MCP personalizados para convidados. Sem hooks específicos para convidados. Sem persistência do histórico de sessões. Só a base limpa que torna a colaboração multiagente possível.

Em seguida vem o reforço de segurança. Lista de permissões do ambiente, aplicação do teto de custo, tempos limite de inatividade, limites de processos simultâneos. Depois, a UX completa: seletor de modelo, instruções personalizadas, o painel do anfitrião mostrando todas as CLIs de convidados ativas.

Estamos publicando esta pesquisa agora porque a arquitetura está fechada e queremos a comunidade envolvida. Se você desenvolve com Claude Code e tem opinião sobre como workspaces de IA multiusuário deveriam funcionar, queremos ouvir.

O SynaBun é open source. A pesquisa por trás do BringCLI, incluindo o design completo da arquitetura, a análise de segurança e o roadmap em fases, está documentada no nosso sistema de memória persistente. Cada decisão, cada trade-off, cada alternativa descartada fica armazenada e pesquisável. É o que acontece quando a sua ferramenta de desenvolvimento tem um cérebro que persiste entre sessões.

Acompanhe o progresso no GitHub ou entre no Discord. O futuro do desenvolvimento com IA não é single-player.