The next seven days are not business as usual. Between the npm token migration deadline, fresh GitHub Actions limits, and a Copilot billing change, your CI/CD can either get faster and safer—or freeze and overspend. Let’s get practical about what to change this week, why it matters, and how to ship without drama.
Why this week matters: dates, impact, and what breaks
Two dates are doing the damage. On November 18, 2025, GitHub removes legacy $0 Copilot premium request budgets for enterprise and team accounts created before August 22, 2025. If you’ve never set an explicit policy, premium requests can bill unless you disable paid usage. (docs.github.com)
On November 19, 2025, remaining npm classic tokens are revoked. If any job still injects a classic token for publish or registry auth, expect 401/403 errors and failed releases until you switch to granular access tokens or Trusted Publishing. (github.blog)
Meanwhile, GitHub Actions picked up useful upgrades this month: nested reusable workflows scale from four to ten, total calls per run jump from 20 to 50, M2‑powered macOS runners are generally available, and the Copilot coding agent no longer requires Actions to be enabled. If you maintain iOS/macOS pipelines or heavy orchestration, these are immediate speed and maintainability wins. (github.blog)
npm token migration: the fast, low‑risk path
The primary keyword here is simple: npm token migration. Classic tokens are dead weight by November 19. Granular tokens with write scopes now enforce 2FA by default and carry a maximum 90‑day lifetime. There’s also a new Bypass 2FA option specifically for CI—but it’s off by default, and you should only enable it where absolutely required. (github.blog)
Your three decision paths
Here’s how I guide teams, ranked from most secure to least:
1) Prefer Trusted Publishing (OIDC). If your release jobs already run on GitHub Actions, adopt OIDC‑based publishing to mint short‑lived credentials automatically. This removes long‑lived tokens from secrets and bakes in provenance for public packages. It’s the cleanest long‑term fix, and it eliminates 90‑day rotation toil.
2) Use granular access tokens with least privilege. If you can’t move to OIDC this sprint, create granular tokens scoped to a single org/package, write‑permission only, and keep expirations short. Store them in your CI secrets manager and rotate on a cadence your team can actually meet.
3) As a short bridge, enable Bypass 2FA for a CI‑only granular token. This will keep non‑interactive jobs unblocked while you finish your OIDC rollout—but plan a time‑boxed sunset.
72‑hour cutover checklist
Most orgs can complete migration in three business days if they parallelize:
Day 1: Inventory and blast radius
- Enumerate all publish paths: release workflows, monorepo scripts, container images with baked secrets, and any internal tooling calling npm publish or npm dist-tag. Search repos for NPM_TOKEN, //registry.npmjs.org/, and release job names.
- Identify classic tokens still in use, including those lurking in self‑hosted runners and old environments.
Day 2: Implement the new auth
- For GitHub Actions, wire up Trusted Publishing via OIDC and attach the required permissions on the release workflow. For other CI, create granular tokens with the minimum scopes, shortest practical lifetime, and Bypass 2FA disabled by default.
- Test publish to a private or canary package first. Validate the provenance, tags, and the registry endpoint.
Day 3: Rotate and revoke
- Remove classic tokens from secrets stores and runner images. Revoke them centrally. Update your runbooks with the new rotation cadence for granular tokens where OIDC isn’t yet possible.
- Add a guardrail job that fails a PR if it tries to reintroduce classic tokens or calls a deprecated publish path.
If you need a deeper, hour‑by‑hour plan, we’ve published a detailed Nov 19 cutover plan and a “last‑mile” playbook to flush out stragglers like stale runner images and forgotten service accounts. They’re written to drop straight into your sprint board.
One last nuance: write‑capable granular tokens are capped at a 90‑day maximum lifetime. If you carried longer expirations, they’ve been clipped by policy, so don’t assume your old calendar reminders still apply. (github.blog)
Are GitHub Actions limits changing in November?
Yes, in a good way. Reusable workflow nesting expanded to ten levels and total calls per run increased to 50. For teams with many shared workflows and platform repos, that unlocks flatter YAML, fewer hacks, and clearer ownership maps. (github.blog)
M2 macOS runners are generally available via labels like macos-latest-xlarge, macos-15-xlarge, macos-14-xlarge, and macos-13-xlarge. Expect faster iOS builds and better GPU acceleration—useful for mobile teams and any hardware‑accelerated workloads in CI. (github.blog)
There’s also a subtle but helpful decoupling: Copilot’s coding agent no longer requires GitHub Actions to be enabled on your org. That gives security teams more flexibility to keep automation and AI assistance on separate policy tracks. (github.blog)
How to capitalize on the new limits
- Consolidate duplicated steps into versioned reusable workflows and call them directly instead of copy‑pasting YAML. The higher nesting cap makes it possible to compose small, focused workflows without hitting ceilings.
- For monorepos, treat the platform repo as an internal marketplace: one workflow per capability (build Android, build iOS, publish package, provision test data). Call them from product repos and track adoption with usage metrics.
- For iOS/macOS pipelines, benchmark M2 runners on your largest jobs. Pin labels explicitly for predictability and document your expected runtime deltas so finance understands why runner minutes move.
We’ve curated more tactics in GitHub Actions November 2025: new limits and M2 if you want detailed before/after examples.
How do Copilot premium requests affect my bill?
Copilot shifted to monthly premium request allowances earlier this year for paid plans. Those allowances reset on the first of the month and cover advanced models and features; code completions remain unlimited. Overage is controlled by a policy toggle—enable it to allow paid usage, disable it to block when allowances are exhausted. (github.blog)
On November 18, 2025, GitHub removes account‑level $0 premium request budgets for enterprise and org accounts created before August 22, 2025. After that, the paid usage policy governs whether overages bill. If you haven’t set or reviewed that policy, do it now. (github.blog)
Budget guardrails: a 9‑point checklist
1) Confirm your account creation date and current premium request policy. If you’re older than August 22, 2025 and relied on the default $0 budget, you’re in scope for the November 18 change. (docs.github.com)
2) Decide policy by environment: block overage in dev/test orgs, allow with a cap in production engineering.
3) If enabling paid usage, set a monthly cap that fits your model strategy, not a wish. Start low, observe, iterate.
4) Turn on usage reporting and export by seat. Build a simple weekly report for engineering managers.
5) Disable premium features for roles that don’t need them. It’s okay for some seats to live on completions only.
6) Add alerts at 50%, 80%, and 100% of allowance. Treat 80% as an action trigger, not a FYI.
7) Document who can change the policy and caps. Require a change request for increases.
8) If you have multiple AI tools, standardize on a per‑tool SKU policy and roll up at the org level.
9) Train teams on “premium request” vs “completions.” Misunderstanding here causes half the surprise bills I see. (docs.github.com)
People also ask: quick answers you can paste into Slack
What happens if we miss the npm token migration?
Release jobs that depend on classic tokens will fail to authenticate to the registry. You’ll see publish denials until you switch to granular tokens or Trusted Publishing and remove the legacy tokens from your secrets and runner images. (github.blog)
Do we have to enable Actions to use the Copilot coding agent?
No. As of the November 2025 updates, the Copilot coding agent doesn’t require GitHub Actions to be enabled for your org. (github.blog)
Are M2 macOS runners stable enough for production CI?
They’re GA with explicit labels. Treat them like any other environment change: run A/B benchmarks on your heaviest jobs, pin versions, and watch runtime, cache hit rate, and flake profiles for two weeks before fully switching. (github.blog)
Risk register: the edge cases that bite late
- Stale images and AMIs. Self‑hosted runners or base images might contain classic tokens you forgot existed. Rebuild them and scan environment variables during start‑up.
- Monorepo tooling. Yarn or npm scripts that run publish commands indirectly can bypass your top‑level checks. Audit the script graph.
- Third‑party CI/CD. If you’re not on GitHub Actions, Trusted Publishing might still be possible, but you’ll need provider‑specific OIDC setup. Don’t assume parity—verify claims and issuer configuration.
- Private internal registries. If you proxy npm through Verdaccio or a vendor cache, confirm authentication flows end‑to‑end. A revoked classic token can fail upstream even if the proxy looks healthy.
- Human fallback paths. Developers sometimes publish locally with a classic token during incidents. Lock that down, document the new procedure, and make it easy to do the right thing.
Let’s get practical: a one‑sprint execution plan
Here’s how I’d run this as a short, high‑signal initiative—especially if your team is already busy shipping features.
1) Appoint a cross‑functional “Nov 18–19” lead. Give them 30 minutes with finance and platform engineering to align on risk and budget posture.
2) Pick your npm path (OIDC first, granular token second). Draft a single golden release workflow and fan it out to all publish repos by PR. Include a policy check that fails PRs if classic tokens reappear.
3) Switch iOS/macOS jobs to labeled M2 runners in a staging branch. Measure five runs before/after and share a short write‑up so teams understand the change and the speedup.
4) Review Copilot premium request policy. If you don’t want paid usage, set the policy to “disabled” before November 18. If you’ll allow paid usage, set a cap, alerts, and an owner.
5) Create a rollback plan. For npm, that’s re‑enabling a granular token with a restricted scope if OIDC misbehaves. For Actions, that’s pinning back to previous runner labels if a toolchain hiccups.
6) Communicate once, clearly. A single Slack post with dates, what changes, and who to contact beats scattered DMs. Link to runbooks and a 15‑minute office hours slot.
Zooming out: security, velocity, and cost finally pull in the same direction
If this all feels like whiplash, it’s because we’re closing a chapter on long‑lived credentials and loose governance. Short‑lived credentials via OIDC reduce blast radius, reusable workflow scaling makes maintainability sane at size, and a clear premium request policy turns AI cost from mystery to line item. The trick is threading them together with one playbook instead of three disjointed tasks.
If you want a deeper dive on each component, we’ve written specialized guides: an end‑to‑end last‑mile npm migration playbook for stubborn environments, a primer on avoiding Nov 18 Copilot billing surprises, and a breakdown of the November Actions updates with configuration examples. If you need help wiring any of this for your org, our team can jump in—start with a quick consult.
What to do next
- Before November 18: Set your Copilot premium request policy and caps, or disable paid usage entirely if you’re not ready. Verify alerts and reporting. (github.blog)
- Before November 19: Remove all npm classic tokens, adopt OIDC Trusted Publishing where possible, and fall back to least‑privilege granular tokens with short expiration if you need a bridge. (github.blog)
- This month: Exploit the new Actions limits—extract reusable workflows, adopt M2 macOS runners after a short benchmark, and de‑duplicate pipeline logic. Document the decisions so the next engineer inherits clarity, not guesswork. (github.blog)
