GitHub 于 10 月 2 日宣布，未经验证的 npm trusted publishing 配置会在创建 48 小时后过期。目的是降低信任一个所有权发生变化的仓库或项目名称的风险。
trusted publishing 通过 OpenID Connect（OIDC）把 npm 发布权限与经批准的 CI/CD 工作流绑定，因此无需保存长期有效的 npm 写入令牌。
48 小时适用的范围
新创建的配置处于未验证状态，48 小时从此时开始计算。通过该配置首次发布成功后，配置即被验证并不再适用过期规则。
如果 48 小时先到期，它将无法再授权发布。过期条目仍显示在 trusted publisher 设置中，但不计入每个包的上限。
要获得新的 48 小时，必须重新创建配置，普通编辑不会重新开始计时。更改仓库或项目身份需要新的信任关系，同一个包上的其他有效配置不受影响。
发布会被拒绝的 GitHub Actions 事件
同一公告还包含 GitHub Actions 事件限制。在已有的 pull_request_target 限制之外，npm 现在也拒绝从 issue_comment 事件签发的 trusted publishing 令牌。
受影响的项目被建议把发布迁移到 push、release 或 workflow_dispatch 等允许的事件。
配置文档要求的运行条件
npm 文档要求 npm CLI 11.5.1 及以上和 Node.js 22.14.0 及以上。受支持的环境是 GitHub 托管的 Actions 运行器、GitLab.com 共享运行器和 CircleCI 云，目前尚不支持自托管运行器。
每个包最多可配置 10 个 trusted publisher。在 GitHub Actions 中，组织或用户、仓库、工作流文件名以及可选的环境名称必须完全匹配，工作流还需要 id-token: write 权限。
npm stage publish 始终被允许，使用 npm publish 直接发布的权限需单独选择。npm 在保存配置时不会验证其内容，错误只会在实际发布时暴露。
与首次发布日程对齐的配置顺序
先准备好发布工作流的触发器、运行器和发布权限，再在计划的首次发布前夕创建信任关系，这样的顺序与期限最为契合，也不必为了保住配置而仓促审查。
如果配置已经过期，可在发布准备就绪后重新创建，并确认通过预期的 trusted publishing 路径发布成功。即使使用允许的事件，审查和发布管控仍然必要。
注意事项：既有令牌路径与文档变化
48 小时期限只适用于未经验证的 trusted publisher 配置。只要包设置允许，传统令牌认证仍是一条独立的发布路径。
10 月 6 日核查时 npm 配置文档并未提到过期规则，但 10 月 14 日再次核查时，文档已新增要求在 2 天内完成首次发布的一节。文档要求删除过期配置并重新创建。
变更记录没有说明在公告前创建但尚未验证的配置如何处理。仅凭变更记录无法得知这类配置的实际状态。
npm trusted publisher 不再是提前配好的设置，而是在首次发布前夕创建、并在 48 小时内完成验证的设置。