GitHub Actions vai bloquear o pull_request_target por padrão em repositórios públicos a partir de 2 de dezembro
O GitHub anunciou que o gatilho pull_request_target passa a ser bloqueado por padrão em repositórios públicos no GitHub Free, Team e Enterprise Cloud. A data de aplicação, que era 2 de novembro, foi adiada para 2 de dezembro de 2026. Repositórios privados e internos ficam de fora, assim como o GitHub Enterprise Server.
O motivo é conhecido: esse gatilho roda no contexto do repositório de destino, com acesso aos segredos dele, mesmo quando o PR vem de um fork. Se o workflow executa código do fork, quem abriu o PR pode chegar aos segredos ou comprometer o pipeline.
Antes da virada há dois ensaios, em 9 e 16 de novembro, das 16h às 18h UTC (13h às 15h em Brasília): nessas janelas, as execuções bloqueadas falham com uma anotação de erro. Fora delas, a regra só avisa. Quem depende do gatilho precisa liberá-lo de forma explícita numa política de eventos do Actions, que pode mirar arquivos de workflow específicos. A aba Insights já mostra quais execuções seriam barradas.
Para quem usa .NET: Se o seu projeto .NET open source usa pull_request_target para comentar cobertura ou publicar pacotes de PRs de fork, confira o Insights antes de 9 de novembro e decida entre liberar o workflow ou trocá-lo por pull_request.
Fonte: GitHub Changelog
API do Claude ganha message threads em beta, e o fast mode do Opus 4.8 tem data para acabar
Desde esta segunda, a Messages API aceita message threads em beta, com o header message-threads-2026-08-12. A primeira requisição vai completa, com a conversa, o system e as tools, e pede a criação da thread. Nas seguintes, a aplicação manda só as mensagens novas e o id da resposta anterior; o servidor guarda o resto. A promessa é requisição menor e tempo até o primeiro token mais baixo e estável em loops longos de agente.
A thread é de melhor esforço: expira 5 minutos depois da última requisição e é apagada no máximo 1 hora após o último uso. Quando some, o continue devolve 404 e é preciso reenviar a conversa inteira. A documentação deixa claro que a aplicação continua dona do histórico, e o recurso não é elegível ao Zero Data Retention. Está disponível na API do Claude, no Claude Platform on AWS, no Google Cloud e no Microsoft Foundry.
Na mesma página de release notes, em 30 de outubro, a Anthropic avisou que o fast mode do claude-opus-4-8 foi depreciado e sai em 30 de novembro de 2026. Depois disso, chamadas com speed: "fast" nesse modelo retornam erro; o caminho indicado é migrar para o Claude Opus 5.5.
Para quem usa .NET: O SDK oficial em C# já traz um helper de thread (client.Beta.Messages.Thread) que cria e continua a thread sozinho, mas guarda o histórico só em memória: num ASP.NET Core com várias instâncias, persista a conversa você mesmo.
Fonte: Claude Platform Release Notes (Anthropic)
Azure Developer CLI de outubro traz azd deploy --preview para ensaiar o deploy sem mudar nada
A Microsoft juntou num só post as versões 1.35.0 a 1.37.2 do Azure Developer CLI. A novidade mais útil é o azd deploy --preview, que mostra o que o deploy faria sem alterar nada no Azure. Ele cobre App Service, Container Apps, Functions, Static Web Apps, AKS e endpoints de IA, com saída em JSON que dá para usar no pipeline.
Também chegaram o deploy de imagens para ambientes express do Container Apps (só pela estratégia de imagem, já que o express não tem múltiplas revisões), o azd env unset em beta para remover chaves do ambiente com confirmação, e o azd pipeline config passando a instalar nos workflows as extensões que a infraestrutura exige. As APIs de extensão de preview de deploy ficaram estáveis na 1.37.0, com mudanças que quebram código para quem escreve extensões em Go.
Para quem usa .NET: Não há mudança específica para .NET ou Aspire nesta leva, mas quem publica APIs .NET com azd ganha um passo de conferência barato antes do deploy de verdade.
Fonte: Azure SDK Blog (Microsoft)
Milan Jovanović desliga o CI dos pull requests e passa a liberar o merge com um signoff local
No sábado, Milan Jovanović contou como tirou o CI em nuvem dos PRs de um repositório .NET dele. Um script local roda build, testes e checagem de formatação, guarda o hash do commit aprovado e publica um status signoff com a extensão gh-signoff, do Basecamp. Um hook de pre-push roda esse script, e uma regra do branch exige o status e o branch atualizado para o merge na main.
O GitHub Actions segue rodando, mas só depois do merge, numa agenda semanal para escanear CVEs nas imagens e sob demanda. Segundo ele, foram 833 PRs integrados assim desde junho. O próprio texto lista os limites: o signoff só prova que alguém com permissão de push o publicou, o --no-verify pula o hook, o ambiente local não é limpo e contribuidores de fork não conseguem assinar, então projeto aberto continua precisando de CI na nuvem.
Para quem usa .NET: A ideia funciona para time pequeno, com confiança mútua e um repositório .NET que compila e testa rápido na máquina; em time grande ou projeto aberto, o CI no PR continua sendo a rede de segurança.
Fonte: Milan Jovanović
Minha leitura
O que importa de verdade neste fim de semana é o aviso do GitHub. Não é novidade técnica, o risco do pull_request_target é conhecido há anos, mas agora tem data, ensaio marcado e falha visível. Quem mantém projeto público deveria abrir o Insights ainda esta semana, porque a primeira janela de bloqueio cai numa segunda à tarde no horário de Brasília, em pleno expediente. E a notícia conversa com o texto do Milan: os PRs de fork são justamente o caso em que nem o signoff local nem o gatilho perigoso resolvem, e o CI isolado continua necessário.
As message threads do Claude são a melhoria que mais vai aparecer no dia a dia de quem roda agente em produção, mas eu leria o recurso pelo que ele é: um cache de conversa com prazo de 5 minutos, não um banco. O histórico continua sendo responsabilidade da aplicação, e o caminho de replay precisa existir desde o primeiro dia. Já o fim do fast mode do Opus 4.8 é aviso para não ignorar: se algum serviço ainda chama esse modelo com speed fast, ele quebra em 30 de novembro. O azd com preview é conveniência bem-vinda, não motivo para trocar de ferramenta.
Leia também
- API do Claude no ASP.NET Core: Streaming e Tool Use
- Claude Code com .NET: configuração e skills (Parte 1)
Precisa de ajuda com backend .NET e IA aplicada? Conheça o serviço.