São quatro da tarde. Você deixou o Hermes numa aba para tocar uma tarefa e pulou para outra janela para escrever código. Em algum ponto do caminho ele parou e ficou esperando você aprovar um comando rm -rf, e o título da aba escorregou de “Hermes” para “Hermes (1)”. Aquele (1) se perdeu no meio de uma dúzia de abas. Quando você voltou, duas horas depois, ele estava ali o tempo todo, sem fazer nada.

Isso não é um problema específico do Hermes; é o modo de falha padrão de todo assistente em segundo plano: o sinal que ele usa para chamar sua atenção é fraco demais. Fraco a ponto de você precisar ir atrás dele — e ir atrás é justamente o primeiro hábito que você abandona quando o dia aperta.

O Hermes agora trata isso como um problema de atenção que merece uma solução de verdade. A Webapp alterna o título da aba e pinta um ponto âmbar no favicon. O app desktop faz a barra de tarefas piscar enquanto a janela está sem foco — um quique no Dock no macOS, um urgency hint no Linux. E, depois que você concede permissão, o navegador dispara uma notificação de sistema de verdade que leva você de volta àquela conversa quando você clica nela.

Antes era um (1). Agora são três camadas

Vale entender a estratificação, porque ela é deliberadamente contida — cada camada responde a uma pergunta diferente sobre o quanto o Hermes tem certeza de que você não está olhando.

Camada	Quando dispara	O que você vê	Quando para
Pisca do título da aba	Aba da Webapp oculta ou sem foco	O título alterna a cada segundo entre o título da notificação (por exemplo Approval needed — <chat>) e o título normal	Você volta para a aba
Ponto no favicon	O mesmo	Um ponto âmbar (#f59e0b) desenhado sobre o ícone	Você volta para a aba
Notificação do navegador	Você mesmo clicou em Permitir	Um popup do sistema; o clique dá foco à aba e abre aquela sessão	Você a dispensa ou clica nela
Pisca da barra de tarefas	Janela do desktop sem foco no momento em que uma notificação do sistema dispara	Barra de tarefas piscando no Windows, Dock quicando no macOS, urgency hint no Linux	A janela recebe foco

Repare na divisão de trabalho: o pisca da aba não precisa de permissão nenhuma. Se o evento acontece e a aba não está na frente, ela pisca. As notificações do navegador exigem permissão explícita, porque os navegadores ignoram — e às vezes punem — pedidos de permissão que não nasceram de um gesto do usuário. Antes de você autorizar, o pisca é o único sinal. Depois de autorizar, os dois trabalham juntos.

Por que a notificação do navegador depende de um clique seu

Isso merece uma seção só sua, porque explica a experiência do “configurei as notificações e nunca vi nenhuma”.

O comportamento antigo pedia permissão no instante em que o evento chegava: um evento dispara, o Hermes chama Notification.requestPermission(). Só que Chrome, Safari e Firefox exigem que um pedido de permissão seja iniciado por um gesto do usuário — um clique ou uma tecla. Um pedido nascido de um evento em segundo plano é ignorado ou bloqueado em silêncio, então você nem chega a ter a chance de dizer não.

Agora a permissão é pedida em exatamente dois lugares, ambos dentro das Configurações, ambos por um clique seu:

• Configurações → Notificações → Browser notifications → Allow
• ou o botão Send test notification ao lado

O Hermes nunca pede permissão ao carregar a página e nunca pede a partir de um evento. Se você não clicar, ele só pisca o título e não abre popup nenhum. É uma troca consciente: melhor te interromper uma vez a menos do que brigar com as regras do navegador.

Há uma segunda pegadinha: a API de Notification do navegador só existe em contexto seguro. http://localhost e http://127.0.0.1 contam como seguros, e um endereço HTTPS como o Tailscale serve também. Mas se você abriu a Webapp a partir de outra máquina como http://192.168.x.x:8317, isso é HTTP puro e as notificações ficam indisponíveis. A linha nas configurações diz isso na cara — avisa que é preciso HTTPS, por exemplo Tailscale serve — e o pisca do título continua funcionando. É exatamente por isso que o pisca foi construído para não depender de nada.

Desktop: barra de tarefas piscando, Dock quicando

O app desktop segue outro caminho: ele já tinha notificações nativas do sistema operacional. O que faltava era algo para fazer quando uma notificação dispara com a janela em segundo plano e a própria notificação é engolida pelo Não Perturbe.

Agora, quando uma notificação do sistema dispara com a janela sem foco, o processo principal do Electron chama BrowserWindow.flashFrame(true): o ícone da barra de tarefas pisca no Windows, o ícone do Dock quica no macOS, a janela levanta um urgency hint no Linux. O foco limpa tudo na hora (flashFrame(false)). O patch original veio de um colaborador da comunidade e foi aplicado com a autoria preservada.

A regra de design importante é que ele nunca rouba o foco. Um pisca significa “ei, tem algo esperando por você”; ele não arrasta sua janela para a frente e não navega para lugar nenhum sozinho. O movimento só acontece depois que você clica numa notificação.

Ligar e desligar: tudo passa pelos interruptores que já existem

Os sinais novos não introduzem um sistema de configuração paralelo. Eles reaproveitam as configurações de notificação do desktop (Configurações → Notificações, descritas como por dispositivo):

• Enable notifications é o interruptor geral. Desligado, ele silencia todos os tipos, então nada pisca também.
• Sete tipos de evento têm cada um o seu toggle: Approval needed, Input needed, Response ready, Turn failed, Background task finished, Credit alerts, Plugin notifications.
• Um tipo que você desliga não pisca e não notifica. Se “Response ready” é o que te irrita, desligue esse tipo em vez do recurso inteiro.
• Send test notification prova o caminho: o app desktop usa o canal nativo, e a Webapp pede permissão primeiro e depois publica “Notifications are working.”

Na Webapp, o comando é hermes webapp. Para conferir se o gateway está servindo a Webapp e em que endereço ele se registrou, use hermes webapp --status. O endereço que ele imprime é a sua evidência de que você está (ou não) num contexto seguro.

Quando mesmo assim ele não vai chamar sua atenção

Alguns limites honestos, para você não perder uma noite se perguntando por que nada acontece:

• Nada pisca enquanto a janela está com foco. Os alertas de conclusão sempre foram para quando você está longe; se você está encarando a janela, o Hermes assume que está olhando.
• Um endereço de LAN em HTTP puro não recebe notificações do navegador, só o pisca do título.
• O Não Perturbe engole notificações do sistema, mas não o pisca da aba nem o da barra de tarefas — é justamente esse o ponto das camadas.
• Um navegador suspenso (um notebook dormindo, por exemplo) não abre popup no meio do sono. Quando a aba volta a ficar visível, o pisca recomeça.
• Clicar numa notificação abre a conversa; nunca aprova nada por você. As aprovações continuam manuais.

Já dá para usar hoje

A mudança entrou na main em 2026-10-30 (PR #146882, atendendo a um pedido da comunidade; o patch original #146542 foi resgatado com o autor creditado) e já está na v0.22.6 (2026-11-02): atualize pelo instalador ou com hermes update e o recurso estará lá.

Para experimentar agora você precisa acompanhar a main (uma instalação a partir do código), ou esperar o próximo release. Quando ele sair, lembre de clicar em Allow uma vez nas Configurações — senão você só vai ver o título piscando, concluir que o recurso está quebrado e voltar a vigiar um (1).

Se o problema oposto é o que te incomoda — avisos demais de “tarefa concluída” —, já escrevemos sobre como o Hermes junta tarefas de fundo finalizadas numa única notificação. Aquele texto é sobre sinal demais; este é sobre sinal de menos. O mesmo problema visto pelos dois lados.