Fazer login no Verboo Code, até a 0.14.4, gerava um token OAuth que não carregava nenhuma informação sobre a máquina de onde saiu. Copiar os arquivos de credencial pra outra instalação levava a sessão junto, sem o backend ter qualquer sinal pra diferenciar uma reautenticação legítima de um token reaproveitado em outro lugar. A 0.14.5 fecha essa lacuna com um único commit, direto no fluxo de autenticação: bind OAuth session to installation.
O que muda na sessão OAuth da 0.14.5?
Cada instalação do CLI passa a ter um identificador próprio: um UUID gerado uma única vez por getOrCreateVerbooInstallationId() e guardado na secure storage local. Esse identificador viaja em três pontos do fluxo de autenticação, todos tocados pelo mesmo patch:
- Autorização (
buildAuthUrl): o parâmetroinstallation_idvai junto na URL que abre o navegador pra login. - Troca do código por tokens (
exchangeCodeForTokens): o mesmo id entra no corpo da requisição que finaliza o login. - Renovação do token (
refreshOAuthToken): toda vez que o CLI renova a sessão em segundo plano, o id volta a ser enviado.
O id só entra em cena quando isVerbooMode() está ativo, ou seja, no fluxo nativo de login do Verboo Code. E ele é deliberadamente persistente: sobrevive a um verboo logout, porque o objetivo não é gerar um id novo a cada sessão, e sim manter o mesmo id fixo pra aquela instalação específica.
"A generated installation UUID isolates native OAuth sessions without reading hardware identifiers. It deliberately survives logout so a later login replaces the session for this installation instead of accumulating tokens." (comentário em src/utils/verbooInstallation.ts, commit dffc3cf)
Por que UUID aleatório, e não fingerprint de hardware
Existia um caminho mais agressivo pra resolver o mesmo problema: gerar o identificador a partir de dado de hardware da máquina (serial de disco, MAC address, o tipo de fingerprint que outras ferramentas usam pra amarrar licença a um computador específico). O patch evita essa rota de propósito, como o próprio comentário no código deixa registrado: "without reading hardware identifiers". A troca é direta. Um UUID aleatório não identifica a máquina fisicamente, só marca "essa é a mesma instalação de sempre" pro backend. Isso é mais barato de manter (não depende de biblioteca de fingerprint por sistema operacional) e não coleta dado nenhum sobre o hardware de quem usa o CLI, ao custo de um vínculo mais fraco: reinstalar do zero gera um id novo, então não impede alguém decidido a burlar o controle. Pra Verboo Code, resolver acúmulo de sessão sem tocar em dado de hardware do usuário foi a troca que fez sentido.
Esse patch entra na mesma linha de patches anteriores de autenticação: a 0.13.3 já tinha fechado brecha de precedência, garantindo que token de outra CLI no shell não sobrescrevesse a sessão Verboo autenticada. A 0.14.5 ataca outro ângulo do mesmo problema, dar ao backend um sinal de origem que o token sozinho nunca carregou.
A operação segue em MRR de R$ 32.202,90 (+50% no mês), com 165 assinantes ativos (+31%), rodando modelos open source em GPU dedicada com tokens ilimitados.
Como atualizar
npm install -g @verboo/code@latestQuem prefere Bun: bun install -g @verboo/code@latest. Veja o diff completo entre a 0.14.4 e a 0.14.5 no GitHub.
Sessão que sabe de qual instalação ela veio é a base pra qualquer controle de acesso mais sério daqui pra frente. Conheça o Verboo Code, agente de programação com tokens ilimitados.
