npm Classic Token Shutdown and 2-Hour Session Auth — when and how should I migrate?
Teams still publishing with old npm credentials need to choose between short-lived local sessions, granular tokens, or OIDC after classic tokens were revoked and npm login switched to two-hour session tokens.
Blockers
- capability/npm-classic-tokens — EOL 2025-12-09
- npm login issues a two-hour session token instead of a long-lived token
- requires_version: capability/granular-access-tokens → package/npm-cli
- requires_version: capability/trusted-publishing → package/npm-cli
- requires_version: capability/trusted-publishing → runtime/nodejs
- Lock-in via protocol/oidc
Who this is for
- small-team
- enterprise
- compliance
Candidates
Use "npm login" session auth for local interactive publishing
As of 2026-03-19, this is the default path for local interactive npm publishing after the classic-token shutdown. GitHub's npm changelog states that all npm classic tokens were permanently revoked on December 9, 2025, and that `npm login` now issues a two-hour session token instead of a long-lived token. During that session, 2FA is enforced for publishing operations. The session token does not appear in UI or CLI token lists and expires automatically after two hours.
When to choose
Use this when humans publish manually from a workstation and can complete interactive authentication plus 2FA. It is the simplest replacement for old local classic-token workflows, but only when repeated re-authentication is acceptable.
Tradeoffs
No long-lived local publish token to manage, which reduces exposure. The downside is operational friction because sessions expire after two hours and cannot support unattended publishing.
Cautions
This is not a durable CI/CD credential. GitHub also restored the legacy `/user/org.couchdb.user:` endpoint only temporarily to ease migration, and explicitly warned that its removal is planned; Yarn v1 and v2 users are specifically called out as affected by this transition.
Use granular access tokens for CI/CD when OIDC is unavailable
As of 2026-03-19, granular access tokens are npm's token-based replacement for classic tokens in automation. GitHub's November 5, 2025 npm security update says new write-capable npm tokens enforce 2FA by default, add a Bypass 2FA option for CI/CD, and cap write-capable granular tokens at a 90-day maximum lifetime; existing write tokens expiring after February 3, 2026 were adjusted to that date. npm Docs also state you can create up to 1000 granular tokens per account, each token can cover up to 50 organizations and up to 50 packages/scopes combinations, and access requires npm CLI 5.5.1 or greater.
When to choose
Use this when you need noninteractive publishing but your CI/CD provider cannot use npm trusted publishing. It is the fallback for deployment automation, especially when you need scoped permissions, token revocation, or CIDR/IP restrictions.
Tradeoffs
Granular tokens preserve automation and can be tightly scoped. The cost is token lifecycle management, short write-token expiry, and the security exception created by enabling Bypass 2FA for unattended publishing.
Cautions
npm Docs say Bypass 2FA is false by default and, when enabled, it overrides account-level and package-level 2FA checks. Another blocker is package policy: if a package is set to "Require two-factor authentication and disallow tokens," granular tokens cannot publish regardless of bypass settings.
Use OIDC trusted publishing for supported CI/CD providers
As of 2026-03-19, npm Docs recommend trusted publishing over access tokens for package publishing from CI/CD. Trusted publishing uses OpenID Connect (OIDC) so the workflow authenticates without storing long-lived npm publish tokens, and npm Docs say it requires npm CLI 11.5.1 or later plus Node 22.14.0 or higher. The trusted publishers documentation lists supported hosted providers as GitHub Actions, GitLab CI/CD Pipelines, and CircleCI cloud; self-hosted runners are not currently supported.
When to choose
Use this first for modern hosted CI/CD publishing when your provider is supported and you can meet the Node and npm version floor. It is the best fit for compliance-sensitive or enterprise pipelines because it removes token storage and rotation from the release path.
Tradeoffs
This is the strongest security posture and the least token-management overhead once configured. The tradeoff is platform eligibility: unsupported providers or self-hosted runners still need another path.
Cautions
Provider support is limited to the documented hosted environments, so many bespoke runners cannot use it yet. npm Docs also note that the CLI detects OIDC first and falls back to traditional tokens, so mixed environments should be reviewed carefully to avoid assuming trusted publishing is active everywhere.
Try with your AI agent
$ npm install -g pocketlantern $ pocketlantern init # Restart Claude Code, Cursor, or your MCP client, then ask: # "npm Classic Token Shutdown and 2-Hour Session Auth — when and how should I migrate?"