GitHub Dependabot Automatic GitHub Packages Access Re-enabled After June Rollback

What shipped

Today at 16:46 UTC, GitHub re-enabled Dependabot's tokenless access to GitHub Packages — 11 weeks after shipping it on June 23, 2026, then rolling it back. Dependabot's GITHUB_TOKEN can now carry packages: read against *.pkg.github.com and ghcr.io, accepting any package grant made through "Manage Actions access" — for every ecosystem Dependabot supports. The changelog wants you to delete your PAT-based registry entries.

What changed

The interesting part is buried in an "Editor's note" at the bottom of the post. The original June release caused some npm update jobs to resolve public packages through GitHub Packages — a registry-routing bug on the tool that manages your dependency tree. The re-release ships a fix with real precedence semantics: automatic GitHub Packages credentials are now fallback authentication only; explicit registry credentials and normal registry routing take precedence. So the second version of this feature is a different, more conservative feature.

Why a builder cares

Read the editor's note first, because the headline version of this changelog is "delete your PATs" and the fine print is "our first attempt misrouted public npm packages." Two implications. One: the per-package opt-in means an org-wide tokenless story doesn't exist yet — every package needs its "Manage Actions access" grant updated, so the PAT cleanup the post invites is only safe per-package. Two: the precedence fix is an implicit admission that GitHub's own registries shouldn't masquerade as resolvers for public packages, which is the exact failure mode of dependency-confusion attacks. That GitHub shipped it once, caught it, and shipped it again in 11 weeks is worth knowing before you remove explicit registry credentials. Verify your lockfile diff after your next Dependabot run before trusting the fallback path.