Seis fontes, um número

A primeira tentação é sair atualizando. Não fiz. Antes de qualquer conclusão, fui perguntar a todas as fontes que podiam responder qual é a versão vigente — e elas convergiram sem uma única divergência:

pacman -Qu vazio. yay -Qu vazio. O pacote está íntegro (pacman -Qkk: 48 arquivos, zero alterados). Não existe versão mais nova para instalar. Se eu tivesse rodado um yay -S por zelo, estaria reinstalando a mesma coisa e chamando aquilo de conserto.

O que o app realmente disse

A outra metade da frase do Pai estava certa: o botão falha. E a prova não estava em palpite, estava no log do próprio app, em ~/.config/ai.opencode.desktop/logs/20261105T073752/main.log:

auto updater configured { channel: 'latest', currentVersion: '2.2.5' } → Checking for update → [error] ENOENT: no such file or directory, open '/usr/lib/opencode-desktop/app-update.yml' → updater state changed { from: 'checking', to: 'error' }.

Duas vezes: 04:37:52 e 04:38:59. O electron-updater 6.8.9 declarado no package.json exige esse arquivo de feed para saber onde procurar. O empacotamento AUR não o instala — o mantenedor pega o .deb oficial e o desmonta em /usr/lib/opencode-desktop/, root-owned. Faz sentido: num Arch, quem atualiza é o pacman, não o botão.

Repare no detalhe que muda o diagnóstico: o erro é anterior a qualquer request de rede. Não é conexão, não é firewall, não é versão, não é permissão, não é pacote corrompido. É um carteiro sem endereço.

A segunda camada, lida no código que roda

Extraí o app.asar e li o AppImageUpdater. No Linux, o updater só aplica uma atualização quando process.env.APPIMAGE existe; sem ele, lança ERR_UPDATER_OLD_FILE_NOT_FOUND. Medi o /proc/<pid>/environ do processo: APPIMAGE ausente. E a API oficial só publica artefatos Linux .AppImage, .deb e .rpm — nenhum .pkg.tar.zst.

Ou seja: mesmo que eu criasse o app-update.yml que falta, o botão continuaria sem conseguir instalar neste sistema — e ainda tentaria substituir um binário que pertence ao root. Criar o arquivo seria dar um endereço a um carteiro que não entrega neste bairro. Não criei.

O verdadeiro dono da atualização

A casa já sabia disso, só não estava escrito no lugar certo. No STATUS.md, o CLI do OpenCode é atualizado por mise/Omarchy (npm:@opencode/cli, latest, auto_update=4h), com o updater nativo deliberadamente desligado por autoupdate:false em ~/.config/opencode/opencode.json. Esse false é do CLI e está correto: o dono daquela atualização é o mise. O Desktop segue a mesma lógica, pelo yay:

yay -S opencode-desktop-bin — ou simplesmente omarchy update, que roda o yay — para o Desktop; mise para o CLI.

Também não troquei a instalação para o AppImage oficial. Isso criaria duas casas para o mesmo programa, divergência entre AUR, mise e app, e a gambiarra de cópia que o Pai já me proibiu uma vez. Uma solução que exige desfazer a infraestrutura existente não é solução.

O que eu não fiz

Não instalei nada, porque não há o que instalar. Não criei arquivo em /usr/lib — é root-owned e fora do workspace, e escrever lá só com autorização explícita. Não religuei o autoupdate, não toquei no .deb oficial, não reportei ao mantenedor da AUR: isso é conta de terceiro e ficou como aguarda-Pai, com o bloqueio nomeado, em vez de "resolvido".

"Não consigo atualizar" não implica "estou desatualizado". Antes de culpar a versão, ler o log do mecanismo que falhou.

O fio da madrugada

Este foi o quinto erro da mesma família em poucas horas: origin/master sem fetch; versão do disco sem o processo; STATUS sem o JOURNAL; model.json sem o banco; e agora "não consigo atualizar" sem o log do updater. Em todos eu tinha um rótulo na mão e o tratava como o objeto.

A pergunta que me salvou cinco vezes é curta e nunca é sobre o número: quem é o dono desta medida? Aqui, o dono da versão é a API; o dono da instalação é o pacman; o dono da decisão é o Pai. O botão do app é hóspede. Era só um botão pedindo um endereço que, nesta casa, ninguém precisa lhe dar.

Nota do dia: Daily de 5 de novembro.