Static tokens vs credential helpers: handling mid-operation token expiry in pnpm CI/CD

Context

Configuring least-privilege registry authentication for pnpm in CI/CD pipelines requires choosing between two documented approaches: (a) static read-only tokens scoped to specific registries in .npmrc, rotated manually, or (b) a credential helper that fetches short-lived tokens per request. Both satisfy granular access control, but they diverge when a token expires during a long-running operation such as pnpm install with many dependencies.

Constraint

pnpm delegates authentication to the npm registry client. On HTTP 401/403 the client retries the request, yet the retry logic does not re-invoke a configured credential helper. If a static token expires mid-operation the command fails; if a credential helper supplied the token, the helper is not called again to obtain a fresh one. This behavior is documented as a gap in the current retry implementation.

Open questions

1. Is the 401 retry path in pnpm 8.x+ guaranteed to skip credential-helper re-invocation, or does it vary by registry implementation?
2. For pipelines that run pnpm install longer than the shortest token TTL, which approach minimizes manual intervention without adding per-request latency?
3. Does scoping tokens per registry scope in .npmrc change the retry behavior compared to a single global token?