Atualizações em 08 de outubro de 2026

A aprovação do plano e a permissão para executar ferramentas são configurações distintas nesta versão. Teste sugerido: num projeto descartável, abra /plan com a flag utilizada pela sua automação e confira a espera pela revisão do plano. Depois, verifique a preferência Artifact Review e a ativação de uma extensão com as configurações preenchidas.

A publicação é estável. Você precisa conferir a resposta dos hooks utilizados no projeto, pois a correção da interpretação não comprova o resultado de toda instrução personalizada. As notas não anunciam migração de configuração nem remoção de um contrato. Teste sugerido: em um projeto descartável, configure um hook com uma instrução de recusa para um comando inofensivo e confira sua resposta ao tentar executar esse comando. Em outro teste, utilize um hook prompt de Stop que determine a continuação após um build com erro e observe o encerramento da sessão.

onFailure: "block" é uma opção explícita. A inclusão dessa opção nas notas não comprova a recusa de ações por hooks que continuam com a configuração anterior. No gateway com Bedrock, confira a permissão bedrock:CountTokens. Conectores do claude.ai utilizam por padrão o protocolo MCP 2026-07-28 nas instalações sem consulta de flags, com MCP_PROTOCOL_NEGOTIATION=legacy para o comportamento anterior.

Teste sugerido: num projeto descartável, configure um hook de comando com onFailure: "block" e provoque uma falha inofensiva de inicialização para conferir a recusa da ação. Interrompa temporariamente um servidor MCP de teste por mais de 15 segundos e observe a reconexão. Numa sessão claude -p com trabalho em segundo plano, confirme que a saída conserva a resposta de cada turno concluído.

As ferramentas de worktree exigem a ativação do recurso e um projeto local confiável. Fixar tarefas num grupo compartilhado depende do suporte do servidor, por isso você precisa conferir essa disponibilidade na instalação utilizada. As opções dos provedores personalizados descrevem recursos configuráveis, sem comprovar a disponibilidade de acesso web ou compactação em qualquer provedor. Teste sugerido: num repositório descartável com um arquivo CRLF, aplique uma alteração pequena e confira se os finais de linha foram preservados. Com o recurso de worktrees habilitado, crie e liste uma worktree do projeto confiável. No terminal, copie um bloco por /copy e fixe uma tarefa com p quando o servidor aceitar essa função.

O canal Docker utiliza nousresearch/hermes-agent:stable ou :latest, enquanto as instalações pelo Git recebem a atualização pelo comando hermes update. O aplicativo desktop e o Termux aguardam a próxima publicação conjunta. As notas não descrevem uma migração incompatível nem especificam os valores dos limites corrigidos nas rotas de autenticação. Teste sugerido: numa instalação isolada, confira o login com um redirecionamento local permitido e a recusa de um endereço externo. No gateway de email, envie uma mensagem de teste com um nome de exibição semelhante a um endereço permitido e um remetente diferente, verificando que a autorização utiliza o endereço efetivo.

A publicação está marcada como estável. A correção documentada se limita à apresentação do artefato no editor. As notas não descrevem mudanças nas permissões ou no processamento dos workflows nem uma migração. Teste sugerido: em uma instalação isolada da linha 2.42, inicie a criação de um agente pelo construtor e confira se o artefato aparece durante a geração. Compare a apresentação com a versão anterior.

A versão está marcada como pré-release. A correção dos provedores pertence ao Assistant self-hosted e não anuncia uma mudança geral em todos os Nodes de IA. As notas também não exigem uma migração de configuração. Teste sugerido: em uma instalação isolada, utilize o provedor já configurado no Assistant self-hosted e confira uma resposta. Para uma instalação que utiliza Kimi K3, compare o resultado com a versão anterior. Depois, inicie a criação de um agente e observe a apresentação do artefato durante a geração.

A publicação está marcada como pré-release. A atualização dos exemplos de avaliação de upgrade menciona CVE-2026-94483, mas essa linha isolada não documenta uma correção de vulnerabilidade nova nesta canary. A substituição do tipo de formulário precisa ser conferida nos arquivos utilizados pela aplicação, pois as notas não detalham toda a sua abrangência. Teste sugerido: execute o build de uma cópia da aplicação com Node.js 24 e observe as mensagens de telemetria. Durante o desenvolvimento com Turbopack, compare os avisos de acompanhamento de arquivos e de encerramento com a versão anterior. Confira a tipagem de um formulário utilizado no projeto caso ele dependa de React.FormEvent.

O corpo da canary.5 descreve somente alterações nos testes. As correções de telemetria e do Turbopack pertencem à canary.4, publicada no mesmo dia. As notas da canary.5 não documentam uma mudança na configuração do Google Tag Manager da sua aplicação. Teste sugerido: execute a suíte de testes do repositório numa cópia de trabalho e confira o resultado do teste de ponta a ponta do Google Tag Manager.

O GitHub marca a publicação como estável, mas o chat nativo e o Remote Server continuam experimentais. Os comandos longos corrigidos exigem um terminal aberto após a atualização. Seu histórico conserva uma linha de execução de uso único, portanto a seta para cima seguida de Enter não inicia novamente esse agente.

No Windows 10 em ARM, o executável orca.exe distribuído com o instalador ARM64 continua incompatível. Criar um workspace com agente pelo telefone a partir de uma tarefa ainda pode mudar o workspace visível no desktop. Instalações atualizadas de 1.4.219 ou anterior podem precisar reiniciar os painéis existentes do OpenCode 2 para recuperar seu estado. Teste sugerido: num workspace descartável, deixe um arquivo e uma aba de agente abertos, interrompa a conexão SSH e confira sua recuperação. Abra um terminal novo e execute um comando inofensivo com várias linhas. No chat nativo experimental, escreva um rascunho, reinicie o aplicativo e confira sua preservação.

A publicação é estável e pertence à linha LTS. A verificação de certificados alcança conexões Kubernetes internas do servidor e do agente. Você precisa conferir a cadeia de confiança do cluster no ambiente utilizado para publicar e remover stacks.

As limitações documentadas do Podman permanecem: o script de inclusão automática não o suporta. Conexões por socket entre um servidor Portainer em Docker e um ambiente Podman, ou na direção inversa, não são aceitas. O suporte listado é CentOS 9 com Podman 5 em modo rootful. Em Async Edge, consultar um snapshot ainda pode apresentar uma data inválida de agendamento de atualização. Teste sugerido: em um ambiente isolado com a opção de ocultar bind mounts habilitada, tente publicar um Compose sem privilégios administrativos com um env_file externo à pasta da stack e confirme a recusa. Compare uma publicação equivalente com o arquivo permitido dentro da pasta. Em Kubernetes, execute uma exclusão de namespace em dry-run e confira a preservação dos registros de acesso do Portainer.