Atualizações em 05 de outubro de 2026

O Orca 1.4.221 corrige a permissão de um arquivo que pode conter tokens do Copilot. Em uma máquina compartilhada, você precisa conferir o acesso após o Orca gravar uma nova pasta confiável, pois a atualização do aplicativo não corrige sozinha o arquivo anterior. O Claude Code 2.1.290 também ajusta verificações de permissão e modifica configurações consumidas pelas integrações. A 2.1.291, publicada no fim do dia, corrige o descarte de respostas às solicitações de permissão na nuvem e a perda das últimas mensagens ao encerrar uma sessão.

O Kestra 2.0.5 restringe o replay convencional às execuções encerradas, mudança que exige revisar as integrações que repetiam execuções pausadas. A continuidade dos processos recebe correções no Kestra 1.3.42 e no task runner do n8n 2.42.3, mas você ainda precisa conferir separadamente o resultado da tarefa que falhou. Os ajustes do Codex e do Antigravity CLI pertencem à execução no Windows, com mecanismos diferentes para o ambiente remoto e a sandbox. No Next.js, a canary.61 altera a compilação e a análise da aplicação, incluindo compatibilidade com ESLint 10.

Este diário cobre o dia encerrado de 05/10/2026 no fuso America/New_York e reúne dez releases com mudanças técnicas na reconsulta aos 24 repositórios realizada às 18h de 06/10. O Next.js canary.61 está marcado como pré-release. As outras nove publicações estão identificadas como estáveis, incluindo o n8n 2.42.3, cuja estabilidade foi promovida após a publicação original.

Atualizações em Kestra

As duas linhas recebem o mecanismo centralizado de novas tentativas HTTP e a identificação de tarefas de ticketing nos plugins. As correções têm alcances diferentes: na 1.3.42, o cancelamento de uma tarefa preserva o worker. Na 2.0.5, a retomada das execuções e o controle de concorrência do Loop recebem ajustes que você pode conferir em flows isolados.

A restrição de replay convencional na 2.0.5 exige revisar as integrações que repetem execuções ativas ou pausadas. As notas também permitem o replay de uma execução do playground suspensa em breakpoint. Essa exceção precisa ser conferida no playground, separadamente da chamada convencional.

Kestra 1.3.42

Novidades

• Kestra 1.3.42 — Assets: o tipo do asset pode ser editado. A correção associada permite alterar seu namespace e seu tipo.
• Kestra 1.3.42 — Requisições HTTP: o núcleo centraliza o mecanismo de novas tentativas, sem especificar novos intervalos ou valores de timeout nas notas.
• Kestra 1.3.42 — Plugins: uma interface marcadora identifica tarefas de ticketing. A publicação não anuncia uma integração específica com um serviço de chamados.

Melhorias

• Kestra 1.3.42 — Dashboards: os gráficos são montados conforme aparecem durante a rolagem. O carregamento limita requisições simultâneas e reutiliza os elementos de desenho fora da tela, sem uma medição de desempenho publicada.

Correções

• Kestra 1.3.42 — Worker: a interrupção de uma tarefa cancelada não derruba o processo que atende outras tarefas.
• Kestra 1.3.42 — Arquivos de namespace: o editor corrige a gravação repetida do mesmo arquivo, alteração trazida para a linha 1.3.x.
• Kestra 1.3.42 — Compatibilidade de assets: a assinatura antiga de toUpdated com um argumento permanece disponível para os consumidores que ainda a utilizam.
• Kestra 1.3.42 — Editor de flows: a documentação do plugin fecha quando você troca de editor.

Ponto de Atenção

A versão está marcada como estável. Teste sugerido: cancele uma tarefa em uma instalação isolada e execute outra para conferir a continuidade do worker. Edite um asset de teste, alterando seu tipo e namespace. No editor de arquivos, grave duas alterações sucessivas no mesmo arquivo e reabra-o para conferir o conteúdo. O estado da tarefa cancelada deve ser verificado separadamente da continuidade do processo.

Notas da versão

O release oficial do Kestra 1.3.42 foi publicado às 09h20 de 05/10 em Nova York e está marcado como estável. Os workflows de tradução também restringem o processamento aos arquivos da própria contribuição e não executam código de forks.

Kestra 2.0.5

Novidades

• Kestra 2.0.5 — Configuração do worker: o tamanho do buffer de trabalhos pode ser configurado. O acesso aos arquivos de namespace pelo controller também depende de configuração, cujos campos e valores não estão detalhados nas notas.
• Kestra 2.0.5 — Requisições HTTP e plugins: a linha 2.0.x recebe o mecanismo centralizado de novas tentativas e a interface marcadora para tarefas de ticketing, também publicados na 1.3.42.

Melhorias

• Kestra 2.0.5 — Comunicação do worker: o acesso ao relay de armazenamento de chave e valor compartilha a implementação de streaming em partes.
• Kestra 2.0.5 — Runtime: selfrun.sh remove a adaptação de LD_PRELOAD utilizada para o DuckDB, sem anúncio de remoção dessa ferramenta.

Correções

• Kestra 2.0.5 — Loop: o valor padrão de Loop.concurrencyLimit é ajustado para 0. A condição de concorrência é simplificada e o deadlock recebe uma correção. A publicação também ajusta o Loop que inclui uma pausa.
• Kestra 2.0.5 — WorkingDirectory e reinício: uma nova tentativa de uma tarefa filha que falhou executa novamente o WorkingDirectory. O reinício da execução também retoma as tarefas irmãs ainda não encerradas.
• Kestra 2.0.5 — Breakpoints: uma execução suspensa em breakpoint pode ser encerrada. No playground, uma execução suspensa em breakpoint pode ser repetida.
• Kestra 2.0.5 — Busca e navegação: a busca de namespaces volta ao servidor. A interface utiliza a aba padrão quando nenhuma é indicada e a documentação do plugin fecha na troca de editor. Páginas de plugins com aliases mostram o tipo do elemento.
• Kestra 2.0.5 — Compilação: a declaração duplicada que causava uma falha na compilação do webserver é removida.

Breaking changes

• Kestra 2.0.5 — Replay convencional: a ação exige uma execução encerrada. Integrações que repetiam execuções ativas ou pausadas precisam aguardar o estado final ou utilizar uma ação de encerramento adequada ao flow. A implementação oficial retorna HTTP 409 na chamada individual recusada e valida as ações em lote. A exceção do playground suspenso em breakpoint tem alcance próprio.

Ponto de Atenção

A publicação está marcada como estável. Teste sugerido: compare o replay de uma execução pausada com o de uma encerrada em uma instalação isolada. Confira a recusa da primeira e a aceitação da segunda, depois verifique o comportamento do playground durante um breakpoint. Para os flows com Loop, compare o limite declarado com o valor padrão 0 e inclua uma pausa na execução de teste.

Uma falha controlada em uma tarefa filha de WorkingDirectory permite conferir se a nova tentativa executa novamente o diretório de trabalho. Os nomes das opções do buffer e do acesso aos arquivos pelo controller precisam ser confirmados na documentação da instalação. Esses testes são sugestões, não resultados obtidos pela Promovaweb.

Notas da versão

O release oficial do Kestra 2.0.5 foi publicado às 09h29 de 05/10 em Nova York e está marcado como estável. A alteração oficial do replay confirma a exigência de estado encerrado na interface e no controller. Os workflows de tradução também não executam código de forks.

Atualizações em n8n

As duas versões publicadas no dia compartilham a correção das permissões de chaves e a apresentação de promoções de créditos do Gateway nos Nodes da comunidade. A 2.42.3 também inclui a correção da continuidade do task runner. Para comparar as publicações, observe a estabilidade indicada para cada uma e as mudanças documentadas no seu release, pois os marcadores móveis stable e beta podem apontar para outra versão em uma consulta futura.

n8n 2.41.7

Novidades

• n8n 2.41.7 — Nodes da comunidade: o editor exibe promoções de créditos do Gateway. As notas não especificam valores, duração ou condições comerciais dessas ofertas.

Melhorias

A publicação não descreve uma melhoria independente da correção das permissões e da apresentação das promoções no editor.

Correções

• n8n 2.41.7 — Escopos de variáveis: membros globais podem atribuir esses escopos às chaves de API (interface de programação de aplicações). A correção afeta a concessão de permissões na chave, sem anúncio de alteração no conteúdo das variáveis.

Ponto de Atenção

A versão está marcada como estável. Teste sugerido: em uma instalação de teste, utilize um membro global para configurar uma chave com os escopos de variáveis necessários para uma integração. Confira se a atribuição é aceita e compare o acesso dessa chave com o de outra sem os mesmos escopos. Utilize somente as permissões necessárias para essa verificação.

Você também pode abrir um Node da comunidade para observar a promoção apresentada no editor. As notas não permitem concluir que toda instalação receberá a mesma oferta ou o mesmo número de créditos.

Notas da versão

O release oficial do n8n 2.41.7 foi publicado às 03h26 de 05/10 em Nova York e continua marcado como estável. Na reconsulta de 06/10, o marcador móvel stable aponta para a 2.42.3, sem alterar a tag numérica da 2.41.7.

n8n 2.42.3

Novidades

• n8n 2.42.3 — Nodes da comunidade: o editor apresenta as promoções de créditos do Gateway, como na versão 2.41.7. As condições comerciais não estão detalhadas nas notas.

Melhorias

As notas não apresentam uma melhoria separada das correções do task runner e das permissões, nem da alteração visual nos Nodes da comunidade.

Correções

• n8n 2.42.3 — Task runner: uma rejeição de Promise sem tratamento não encerra o processo do runner. A continuidade do processo não significa que a tarefa responsável pelo erro foi concluída com sucesso.
• n8n 2.42.3 — Escopos de variáveis: membros globais podem conceder esses escopos às chaves de API (interface de programação de aplicações). A correção documentada também aparece na versão estável 2.41.7.

Ponto de Atenção

A versão 2.42.3 está identificada como estável pelo GitHub na reconsulta de 06/10. Teste sugerido: em um ambiente isolado, reproduza uma rejeição de Promise sem tratamento no task runner e acompanhe seu processo. Depois, execute outra tarefa para conferir a continuidade do atendimento, mantendo separado o resultado da tarefa que apresentou o erro.

Notas da versão

O release oficial do n8n 2.42.3 foi publicado às 03h23 de 05/10 em Nova York. A versão está identificada como estável e recebe o marcador móvel stable na reconsulta de 06/10. A mudança de estabilidade não representa uma nova publicação técnica em 06/10.

Atualizações em Antigravity CLI

O isolamento dos comandos no Windows recebe um ajuste que dispensa elevação para administrador e inclui compatibilidade com ferramentas comuns de desenvolvimento. No terminal, as correções preservam a apresentação de tabelas e a identificação de imagens lidas pelo agente. Os novos avisos acima do prompt também distinguem a dispensa permanente de um cartão da sua ocultação pelo restante da sessão.

Antigravity CLI 1.2.17

Novidades

• Antigravity CLI 1.2.17 — Avisos de serviço: cartões acima do prompt apresentam lançamentos de modelos, descontinuações e outros avisos. A interface mostra um cartão por vez, começando pelo mais recente. Com o prompt vazio, Esc dispensa permanentemente o cartão atual e mostra o próximo. O envio de uma mensagem oculta o cartão durante o restante da sessão.

Melhorias

• Antigravity CLI 1.2.17 — Sandbox do Windows: comandos isolados dispensam direitos de administrador. As notas indicam que o Python, o Git e o npm funcionam nesse ambiente sem configuração adicional, preservando a execução dentro da sandbox.

Correções

• Antigravity CLI 1.2.17 — Tabelas Markdown: as colunas mantêm o alinhamento quando uma célula contém emojis ou caracteres combinados, como os utilizados no hindi. A falha afetava sessões por SSH e dentro do tmux.
• Antigravity CLI 1.2.17 — Imagens TIFF: a visualização de arquivos .tiff identifica corretamente o formato e evita a conversão silenciosa para PNG associada ao erro de identificação.

Ponto de Atenção

A publicação está marcada como estável. Teste sugerido: no Windows, abra uma sessão sem elevação para administrador e execute um comando inofensivo do Git ou do Python dentro da sandbox. Confira a execução e a indicação de isolamento. A dispensa dos direitos de administrador não é uma instrução para executar o comando fora da sandbox.

Você pode comparar o alinhamento de uma tabela com emojis por SSH ou tmux e abrir uma imagem .tiff de teste para conferir o formato reconhecido. Quando houver um cartão acima do prompt, utilize Esc com o campo vazio para observar sua dispensa. O envio de uma mensagem tem outro alcance, pois oculta o aviso apenas pelo restante da sessão.

Notas da versão

O release oficial do Antigravity CLI 1.2.17 foi publicado às 02h20 de 05/10 em Nova York e está marcado como estável. As notas descrevem quatro alterações, sem uma migração obrigatória de configuração.

Atualizações em Codex

A correção da linha 0.160 atende a uma conexão entre sistemas diferentes: o host Unix conduz a inicialização, mas o servidor MCP (Model Context Protocol) stdio executa no Windows. A lista de variáveis permitidas conserva os diretórios necessários ao processo remoto quando você configura explicitamente seu ambiente. O teste publicado pelo fornecedor também confere a exclusão de uma variável sensível não solicitada.

Codex 0.160.1

Novidades

A publicação descreve uma correção na inicialização remota dos servidores existentes, sem anunciar uma nova modalidade de conexão.

Melhorias

As notas concentram a alteração na preservação do ambiente Windows e não apresentam uma melhoria independente dessa correção.

Correções

• Codex 0.160.1 — Servidores MCP remotos: a lista de variáveis permitidas inclui SYSTEMROOT, TEMP e TMP quando há variáveis remotas explicitamente configuradas. A inicialização por um host Unix preserva esses caminhos do executor Windows, mantendo a filtragem das variáveis não solicitadas.

Ponto de Atenção

A publicação está marcada como estável. Teste sugerido: em uma conexão isolada entre um host Unix e um executor Windows, inicie um servidor MCP stdio com variáveis remotas explicitamente configuradas. Confira a presença de SYSTEMROOT, TEMP e TMP no processo remoto e execute uma chamada simples de ferramenta. Uma variável de teste não solicitada deve permanecer ausente. Utilize valores fictícios e observe somente a presença das variáveis, pois essa conferência não exige mostrar credenciais. A mudança descrita preserva a seleção do ambiente e não corresponde ao encaminhamento indiscriminado das variáveis do host.

Notas da versão

O release oficial do Codex 0.160.1 foi publicado às 14h29 de 05/10 em Nova York e está marcado como estável. A alteração oficial da filtragem do ambiente remoto confirma a preservação das variáveis do Windows e o teste de exclusão de uma variável sensível não solicitada.

Atualizações em Claude Code

As versões 2.1.290 e 2.1.291 combinam mudanças na aplicação das permissões com a preservação das sessões. Os agendamentos de /loop recebem correções durante a compactação e a retomada na 2.1.290. A 2.1.291 corrige uma regressão dessa versão que descartava respostas às solicitações de permissão na nuvem. Você precisa conferir separadamente o recebimento de uma aprovação e a continuidade do trabalho autorizado.

Os arquivos do projeto não podem habilitar o Chrome nesta versão e um identificador retornado por Agent muda de significado. A publicação também corrige a leitura por links simbólicos e o envio de alterações locais para revisão, com procedimentos de recusa quando o trabalho não pode ser preservado ou enviado corretamente.

Claude Code 2.1.290

Novidades

• Claude Code 2.1.290 — Hooks de plugins: turn.step inclui serverToolUses para registrar chamadas executadas pelo servidor. tool.check informa o subagente por agentId e a aprovação exigida pela organização por ceiling. claude plugin validate --json mostra gatingHooks com a presença de .catch.
• Claude Code 2.1.290 — Sessões e Managed Agents: claude attach <name> e claude logs <name> aceitam parte do nome da sessão. /claude-api managed-agents-onboard aceita uma URL com arquivos ant apply ou o nome de um quickstart da Console.

Melhorias

• Claude Code 2.1.290 — Histórico e leitura de páginas: a interface continua atendendo aos comandos durante o carregamento de sessões extensas. O WebFetch informa o texto não lido após 100 mil caracteres e aceita offset para continuar a leitura.
• Claude Code 2.1.290 — Busca e conexão: o orçamento da busca na web é renovado a 100 chamadas por hora, com taxa configurável por CLAUDE_CODE_WEB_SEARCH_REFILLS_PER_HOUR. Um servidor MCP recusado pelo proxy com HTTP 403 não recebe as três novas tentativas anteriores.

Correções

• Claude Code 2.1.290 — Leitura e ferramentas: as restrições alcançam instruções do projeto e imagens acessadas por links simbólicos. As permissões também são conferidas após a modificação da entrada por PreToolUse e comandos com certas expansões do shell exigem aprovação.
• Claude Code 2.1.290 — Agendamentos: compactações feitas a partir desta versão preservam as tarefas de /loop. Outras correções permitem disparar tarefas após a passagem para segundo plano e evitam execuções extras durante a retomada. Subagentes retomados conservam o raciocínio anterior e o cache do prompt.
• Claude Code 2.1.290 — Alterações locais e interface: /ultrareview informa falhas na inclusão do trabalho sem commit. /teleport recusa um stash que apagaria arquivos de uma pasta colocada no lugar de um arquivo rastreado. A extensão do VS Code preserva o foco do diálogo quando outra solicitação de permissão chega.

Breaking changes

• Claude Code 2.1.290 — Configurações do projeto: o Chrome exige --chrome, /chrome ou configuração pessoal. Os arquivos do projeto não podem mais habilitá-lo. CLAUDE_CODE_DISABLE_ATTACHMENTS precisa ser definida pelo ambiente do shell, pelas configurações pessoais ou pelas gerenciadas.
• Claude Code 2.1.290 — Participantes e GitHub: integrações que interpretavam agent_id como name@team precisam ler teammate_id. Hooks TeammateIdle não são disparados pelos subagentes ou forks do participante. Nas sessões de nuvem, o gh api integrado exige --hostname ou uma URL completa para outro host, recusando a indicação apenas por GH_HOST ou GH_REPO.

Ponto de Atenção

A versão está marcada como estável, com alterações que exigem revisar configurações e consumidores dos resultados de Agent. Teste sugerido: em uma sessão isolada, confira a habilitação explícita do Chrome e compare agent_id com teammate_id. Utilize um arquivo fictício com acesso negado para verificar a recusa da leitura por um link simbólico.

Crie uma tarefa inofensiva de /loop, compacte a conversa e retome-a para conferir o agendamento. A correção não recupera tarefas perdidas em compactações de versões anteriores.

Notas da versão

O release oficial do Claude Code 2.1.290 foi publicado às 19h33 de 05/10 em Nova York e está marcado como estável. As notas abrangem o terminal e as integrações de nuvem, além da extensão do VS Code e do Claude Tag.

Claude Code 2.1.291

Novidades

As notas concentram as mudanças em duas regressões das sessões e não anunciam um recurso novo.

Melhorias

A publicação não descreve uma melhoria independente da preservação das respostas de permissão e das mensagens finais.

Correções

• Claude Code 2.1.291 — Permissões na nuvem: as respostas às solicitações de permissão são preservadas, corrigindo o descarte que podia ocorrer na 2.1.290.
• Claude Code 2.1.291 — Histórico da sessão: o encerramento conserva as últimas mensagens, corrigindo uma regressão introduzida na 2.1.288. As notas não anunciam a recuperação de mensagens perdidas anteriormente.

Ponto de Atenção

A versão está marcada como estável. Teste sugerido: responda a uma solicitação de permissão para uma ação inofensiva em uma sessão de nuvem isolada e confira se a resposta é recebida. Em outra conversa de teste, escreva uma mensagem final identificável, encerre a sessão e retome-a para conferir o histórico.

Notas da versão

O release oficial do Claude Code 2.1.291 foi publicado às 23h55 de 05/10 em Nova York. A data em UTC é 06/10, mas o horário local inclui esta publicação no diário de 05/10.

Atualizações em Orca

O Orca modifica o acesso à configuração do Copilot e a relação entre as sessões do Codex no Windows. A primeira alteração corrige uma permissão de arquivo que pode expor tokens a outros usuários da máquina. A segunda compartilha o diretório do Codex nas sessões novas, mas preserva o diretório anterior nos terminais já abertos.

O chat nativo e os perfis de agentes recebem novas integrações. As correções de memória liberam referências de telas encerradas, enquanto a busca informa falhas de conclusão. As notas mantêm limitações do OpenCode e do Windows ARM, por isso você precisa conferir o terminal efetivamente iniciado após a atualização.

Orca 1.4.221

Novidades

• Orca 1.4.221 — Agentes e perfis: o histórico inclui Qoder. O aplicativo inicia Qoder CLI China e Qwen Code, permite vincular GLM Coding Plans diretamente e oferece perfis separados para OpenCode e Devin. O Antigravity recebe um cartão Accounts e permite continuar históricos do IDE e da versão 2.0 no CLI.
• Orca 1.4.221 — Chat e interface: workspaces de servidores pareados abrem chats estruturados quando Chat é o padrão. O OpenCode pode utilizar esse modo. Notificações do desktop podem ser desativadas por máquina e um atalho configurável mostra ou oculta workspaces filhos.

Melhorias

• Orca 1.4.221 — Workers do Codex: worker-start aceita max e ultra para modelos ainda ausentes da lista do Orca. Menus de confirmação de plano e perguntas abertas indicam que o agente aguarda sua resposta.
• Orca 1.4.221 — Memória e arquivos: o fechamento de abas libera referências mantidas por terminais e previews. O aplicativo reduz cópias de imagens e históricos, sem medição de consumo publicada. O visualizador reconhece arquivos CSV separados por ponto e vírgula.

Correções

• Orca 1.4.221 — Configuração do Copilot: ~/.copilot/config.json fica acessível somente ao proprietário após o Orca adicionar uma pasta confiável. Um arquivo alterado por uma versão anterior recebe a correção na próxima inclusão de pasta. A atualização do aplicativo, por si só, não modifica essa permissão.
• Orca 1.4.221 — Worktrees e SSH: uma remoção interrompida pelo Git permanece na lista para outra tentativa. A exclusão de workspaces volta a funcionar nos projetos do runtime WSL em C:\. A observação de arquivos continua após reconexões SSH e substituições de pastas.
• Orca 1.4.221 — Terminal e edição: os agentes utilizam o comando orca fornecido pelo aplicativo mesmo quando o shell inclui uma instalação global anterior. A edição com Find aberto conserva o cursor. A busca corrige os resultados incompletos e informa quando não terminou.
• Orca 1.4.221 — Atualização e notebooks: no macOS, Update & Restart informa as instâncias em segundo plano que precisam ser encerradas e permite outra tentativa. Fechar um notebook cancela a inicialização pendente do kernel.

Breaking changes

• Orca 1.4.221 — Codex no Windows: novas sessões compartilham o ~/.codex utilizado fora do Orca. Servidores MCP configurados somente no diretório gerenciado anterior precisam ser cadastrados novamente. A autenticação feita apenas no Orca é copiada, mas a confiança na pasta e as permissões de comandos podem exigir nova aprovação. Os terminais existentes continuam no diretório antigo.

Ponto de Atenção

A publicação está marcada como estável. Teste sugerido: em um host isolado, confira a permissão de ~/.copilot/config.json após o registro de uma pasta confiável, sem exibir os tokens. No Windows, compare o diretório e os servidores MCP de um terminal novo do Codex com os de uma sessão aberta na versão anterior.

O chat nativo e o Remote Server continuam experimentais mesmo nesta publicação estável. O comando orca permanece indisponível no Windows 10 ARM. Painéis existentes do OpenCode 2 podem exigir reinicialização para mostrar seu estado. Um worker do OpenCode pode deixar a tarefa no campo de composição, situação para a qual as notas orientam utilizar Enter. A correção dessa falha está prevista para outra publicação.

Os terminais já abertos conservam o serviço anterior. As notas gerais mantêm a ressalva de aprovação do hook de estado do Codex e a pausa de até 30 segundos em painéis retomados com ~/.codex, por isso confira qual sessão está executando. Os testes sugeridos não foram realizados pela Promovaweb.

Notas da versão

O release oficial do Orca 1.4.221 foi publicado às 19h49 de 05/10 em Nova York e está marcado como estável. Na reconsulta de 06/10, as notas substituem a descrição do build diário por uma ressalva sobre o Remote Server experimental e anunciam uma versão 2.0 para a semana. O anúncio não comprova a correção das falhas atuais.

Atualizações em Next.js

A canary.61 reúne alterações na compilação e na análise da aplicação. A estabilização de forbidden() e unauthorized() pertence à linha canary, que continua identificada como pré-release. Você pode conferir o build e o lint em uma cópia da aplicação, mantendo a comparação com a configuração utilizada na versão anterior.

Next.js 16.4.0-canary.61

Novidades

• Next.js 16.4.0-canary.61 — Autorização e análise: forbidden() e unauthorized() são estabilizadas nesta linha. A skill do analisador recebe o grafo versionado como JSON Lines e Instant Insights inclui prefetch() e navigation().

Melhorias

• Next.js 16.4.0-canary.61 — Turbopack e cache: o cache de caminhos canonizados procura primeiro o prefixo armazenado mais longo. O build coleta as dependências dos parâmetros de raiz de 'use cache' e ordena a lista de variáveis de ambiente das entradas duráveis do cache.
• Next.js 16.4.0-canary.61 — ESLint: o eslint-config-next inclui compatibilidade com ESLint 10. As notas não anunciam uma atualização automática da instalação existente.

Correções

• Next.js 16.4.0-canary.61 — Configuração e rotas: os caminhos de exportação padrão preservam o objeto de configuração. Os metadados do modo de compilação e os prefixos dinâmicos de assets ficam separados desse objeto. O cliente recebe correções para erros de rotas inteiramente estáticas.
• Next.js 16.4.0-canary.61 — Runtime e diagnóstico: a otimização dos exports ESM baseada em getters é revertida. Erros de entrada e saída síncrona aparecem nos logs das pré-renderizações de runtime e o next-swc recompila a parte nativa quando seus arquivos JavaScript incorporados mudam.

Ponto de Atenção

A canary.61 é uma pré-release. Teste sugerido: execute o build de uma cópia da aplicação com sua configuração habitual e compare os logs das rotas estáticas. Na instalação com ESLint 10, confira o lint com o eslint-config-next correspondente. Você também pode comparar o grafo JSON Lines do analisador e as respostas das rotas que utilizam forbidden() ou unauthorized().

As opções de configuração dessas funções precisam ser confirmadas na documentação da instalação. A estabilização anunciada não transforma a versão canary em uma edição estável.

Notas da versão

O release oficial do Next.js 16.4.0-canary.61 foi publicado às 19h47 de 05/10 em Nova York e está marcado como pré-release. A canary.60 foi publicada no dia anterior e permanece na edição de 04/10.

Conferência das permissões e da continuidade das execuções

As mudanças do Orca e do Claude Code exigem conferir permissões e configurações consumidas pelos agentes. Comece pela permissão de ~/.copilot/config.json após a nova gravação de pasta confiável. No Windows, compare os terminais novos e antigos do Codex dentro do Orca e cadastre os servidores MCP necessários no diretório compartilhado. Depois, confira a configuração do Chrome e os identificadores de Agent no Claude Code, seguidos da retomada de uma tarefa inofensiva de /loop após a compactação. Na 2.1.291, confira também o recebimento de uma resposta de permissão na nuvem e a conservação das mensagens ao encerrar e retomar a sessão.

O Kestra e o n8n corrigem a continuidade dos processos, mas preservam a necessidade de conferir o resultado da tarefa. Compare o replay pausado e encerrado no Kestra 2.0.5, depois observe o worker após um cancelamento na 1.3.42. No n8n, confira os escopos das chaves e a continuidade do runner na 2.42.3, agora marcada como estável. A execução no Windows tem verificações próprias: o Antigravity CLI deve conservar a sandbox sem elevação e o Codex remoto deve preservar as variáveis necessárias, excluindo as não solicitadas.

Por último, execute o build e o lint com ESLint 10 em uma cópia da aplicação com Next.js canary.61. Compare o grafo do analisador e as respostas das funções de autorização. Essa sequência acompanha os mecanismos descritos pelos fornecedores, sem representar testes já realizados pela Promovaweb.

Para investigar o replay dos flows e as permissões das integrações com orientação técnica ao vivo, conheça o Desenvolvimento Colaborativo da Dev Side Studio. Para aprofundar esses temas com orientação e aplicação, conheça as formações da Promovaweb.