Skip to main content
O ChatCLI se mantém atualizado sozinho. Ele detecta por qual canal o binário em execução foi instalado e aplica a atualização exatamente por aquele canal — nunca cruza canais, nunca briga com o seu gerenciador de pacotes e nunca toca um build que não produziu.

​
Detecção do Canal de Instalação

A detecção roda localmente (sem rede), combinando o caminho real do binário, os metadados de build do Go e o carimbo de versão injetado pelo CI de release:
O check do Homebrew roda primeiro de propósito: o bottle instalado pelo tap é o mesmo asset carimbado publicado na release do GitHub — só o caminho Cellar distingue os dois canais.

​
Por que builds locais nunca são auto-atualizados

Um binário compilado localmente pode carregar patches não commitados. Substituí-lo por um artefato de release destruiria esse trabalho em silêncio, então o ChatCLI apenas indica o caminho:

​
O Comando /update

O /update puro é um pedido explícito: quando existe release mais nova num canal automatizável, ele aplica na hora — a mesma semântica do brew upgrade.
Antes de aplicar qualquer coisa — e no /update check — o ChatCLI mostra a seção de Novidades: os destaques extraídos direto das release notes do GitHub, que chegam na mesma resposta de API da checagem de versão (nenhuma chamada extra de rede). O /update check mostra o mesmo status, mas nunca aplica nada. O mesmo card sustenta o /version e a flag -v/--version: build instalado, canal de instalação detectado, última release, o convite ao /update (mais o comando nativo do canal quando existe) e a seção de novidades sempre que há atualização disponível. O comando também está disponível na palette interativa e no completer de tab, e o /config update mostra a política resolvida a qualquer momento.

​
One-shot: chatcli update

Para scripts, CI e automação, o mesmo fluxo está disponível sem entrar no REPL:
Exit codes: 0 atualizado ou já na última versão (incluindo check), 1 falha de checagem/aplicação ou canal manual (Docker, build local) com update pendente, 2 uso inválido.

​
Self-Replace Verificado

Quando o binário veio direto de uma release do GitHub, o ChatCLI o atualiza no lugar com um pipeline endurecido:
  1. Baixa o checksums.txt da release alvo.
  2. Faz streaming do asset da plataforma para um arquivo de staging no mesmo diretório do binário (garantindo rename atômico no mesmo filesystem) enquanto calcula o SHA-256.
  3. Recusa a instalação em qualquer divergência de checksum — o download é descartado e o binário atual jamais é tocado.
  4. Troca atomicamente: um rename simples no macOS/Linux (o processo em execução continua no inode antigo), ou o dance de renomear para .old no Windows, com rollback automático se a ativação falhar. Restos são limpos no próximo boot.
Releases publicadas antes do checksums.txt existir não podem ser verificadas, e o ChatCLI recusa instalações não verificadas — você recebe uma instrução de download manual. Isso só afeta atualizar para releases muito antigas.
Se o diretório de instalação não for gravável (ex.: /usr/local/bin do root), o updater degrada para um comando pronto para copiar:

​
Auto-Update em Background (Staging)

Defina CHATCLI_AUTO_UPDATE para controlar o comportamento no boot: O modo auto usa staging, o mesmo modelo do Claude Code: o processo em execução nunca é reiniciado nem interrompido. O binário novo pousa no disco enquanto você trabalha, e o próximo start já abre na versão nova — anunciada uma única vez na tela de boas-vindas:
No modo notify (o default), a tela de boas-vindas mostra o convite — o mesmo que o card do /version renderiza, incluindo o comando nativo do canal de instalação detectado:
O banner é instantâneo e atual ao mesmo tempo: ele confia no último dado de release conhecido mesmo depois da janela diária de re-checagem, e quando esse cache está vencido o boot dá ao refresh um orçamento síncrono curto (cerca de 1,5 s) antes de imprimir — então uma release publicada de madrugada aparece já no primeiro banner, não um boot depois. Cache fresco (no máximo uma consulta por dia) não custa nada, e o modo off nem toca a rede. Só quando a checagem não termina dentro do orçamento (rede lenta ou ausente) o anúncio cai para a própria sessão, no turno seguinte do prompt — você continua sem precisar reiniciar (nem rodar /version) para ficar sabendo:
O mesmo aviso in-session dispara no modo auto quando o staging silencioso falha (por exemplo, module proxy inacessível) — um update em background quebrado nunca esconde uma release nova de você.
O Homebrew fica deliberadamente fora do update silencioso em background. O brew upgrade pega o lock global do Homebrew e pode disparar um brew update completo; o ChatCLI só o executa quando você roda /update explicitamente. Processos ChatCLI concorrentes se coordenam por lock file — só um faz o update em background.

​
Configuração

​
Troubleshooting