GitHub Actions will block pull_request_target by default in public repositories starting December 2
GitHub announced that the pull_request_target trigger will be blocked by default in public repositories on GitHub Free, Team and Enterprise Cloud. The enforcement date, originally November 2, was moved to December 2, 2026. Private and internal repositories are excluded, as is GitHub Enterprise Server.
The reason is well known: this trigger runs in the context of the target repository, with access to its secrets, even when the PR comes from a fork. If the workflow runs code from the fork, whoever opened the PR can reach the secrets or compromise the pipeline.
Before the switch there are two dry runs, on November 9 and 16, from 16:00 to 18:00 UTC (13:00 to 15:00 in Brasília): during those windows, blocked runs fail with an error annotation. Outside them, the rule only warns. Anyone who depends on the trigger needs to allow it explicitly in an Actions event policy, which can target specific workflow files. The Insights tab already shows which runs would be blocked.
For .NET developers: if your open-source .NET project uses pull_request_target to comment coverage or publish packages from fork PRs, check Insights before November 9 and decide between allowing the workflow or switching it to pull_request.
Source: GitHub Changelog
Claude API gets message threads in beta, and Opus 4.8 fast mode has an end date
Since this Monday, the Messages API accepts message threads in beta, with the header message-threads-2026-08-12. The first request is complete, with the conversation, the system and the tools, and asks for the thread to be created. In the following ones, the application sends only the new messages and the id of the previous response; the server keeps the rest. The promise is smaller requests and a lower, steadier time to first token in long agent loops.
The thread is best effort: it expires 5 minutes after the last request and is deleted at most 1 hour after the last use. When it is gone, the continuation returns 404 and the whole conversation has to be sent again. The documentation makes clear that the application still owns the history, and the feature is not eligible for Zero Data Retention. It is available on the Claude API, Claude Platform on AWS, Google Cloud and Microsoft Foundry.
In the same release notes page, on October 30, Anthropic announced that fast mode for claude-opus-4-8 is deprecated and ends on November 30, 2026. After that, calls with speed: "fast" on that model return an error; the recommended path is to migrate to Claude Opus 5.5.
For .NET developers: the official C# SDK already ships a thread helper (client.Beta.Messages.Thread) that creates and continues the thread on its own, but it keeps the history only in memory: in ASP.NET Core with several instances, persist the conversation yourself.
Source: Claude Platform Release Notes (Anthropic)
October's Azure Developer CLI brings azd deploy --preview to dry-run a deployment without changing anything
Microsoft combined versions 1.35.0 through 1.37.2 of the Azure Developer CLI in a single post. The most useful addition is azd deploy --preview, which shows what the deployment would do without changing anything in Azure. It covers App Service, Container Apps, Functions, Static Web Apps, AKS and AI endpoints, with JSON output you can use in a pipeline.
Also new: image deployment to Container Apps express environments (only through the image strategy, since express does not support multiple revisions), azd env unset in beta to remove environment keys with confirmation, and azd pipeline config now installs the extensions the infrastructure requires into the workflows. The deploy preview extension APIs became stable in 1.37.0, with breaking changes for anyone writing extensions in Go.
For .NET developers: there is no specific change for .NET or Aspire in this batch, but if you publish .NET APIs with azd you get a cheap check step before the real deployment.
Source: Azure SDK Blog (Microsoft)
Milan Jovanović turns off CI for pull requests and now approves merges with a local signoff
On Saturday, Milan Jovanović explained how he removed cloud CI from the PRs of one of his .NET repositories. A local script runs build, tests and formatting checks, stores the hash of the approved commit and publishes a signoff status with the gh-signoff extension, from Basecamp. A pre-push hook runs that script, and a branch rule requires the status and an up-to-date branch to merge into main.
GitHub Actions still runs, but only after the merge, on a weekly schedule to scan the images for CVEs and on demand. According to him, 833 PRs have been merged this way since June. The text itself lists the limits: the signoff only proves that someone with push permission published it, --no-verify skips the hook, the local environment is not clean, and fork contributors cannot sign, so open-source projects still need cloud CI.
For .NET developers: the idea works for a small team with mutual trust and a .NET repository that builds and tests quickly on the machine; in a large team or an open-source project, CI on the PR remains the safety net.
Source: Milan Jovanović
My take
What really matters this weekend is GitHub's notice. It is not a technical novelty: the risk of pull_request_target has been known for years, but now it has a date, a scheduled dry run and a visible failure. Anyone who maintains a public project should open Insights this week, because the first blocking window falls on a Monday afternoon in Brasília time, in the middle of the workday. The news also connects with Milan's text: fork PRs are exactly the case where neither a local signoff nor the dangerous trigger solves the problem, and isolated CI is still needed.
Claude's message threads are the improvement that will show up most in the daily work of anyone running agents in production, but I would read the feature for what it is: a conversation cache with a 5-minute window, not a database. The history remains the application's responsibility, and the replay path needs to exist from day one. The end of fast mode on Opus 4.8 is a warning not to ignore: if any service still calls that model with speed fast, it breaks on November 30. The azd preview is a welcome convenience, not a reason to switch tools.
Also read
Need help with .NET backend and applied AI? See the service.