GitHub CLI：可选择启用会过期、自动刷新的 OAuth 令牌

2026-10-22

你现在可以在 GitHub CLI 中使用会过期、自动刷新的 OAuth 凭据，这是公开预览的一部分。当你选择启用后，gh 会存储一个会过期的访问令牌以及一个轮换的刷新令牌，并在需要时自动刷新该令牌。你无需重新认证即可保持已认证状态，而泄露的访问令牌会在数小时内变得不可用，而不是无限期有效。

GitHub CLI 公开预览支持会过期、自动刷新的 OAuth 凭据，令牌泄露后的可用窗口从无限期缩短到数小时，官方计划未来将其设为新登录的默认行为。

• GitHub CLI 公开预览支持会过期、自动刷新的 OAuth 凭据，令牌泄露后的可用窗口从无限期缩短到数小时，官方计划未来将其设为新登录的默认行为。
• 原贴提到：You can now use expiring, automatically refreshing OAuth credentials in
• 来源：github.blog

这是什么信号

GitHub CLI 开始支持「会过期 + 自动刷新」的 OAuth 凭据，当前是公开预览、需要显式开启。开启后 gh 同时持有一个短期访问令牌和一个轮换刷新令牌，在后台自动续期，用户日常不需要做任何额外动作。官方还明确说：未来版本会把这一模式变成新登录的默认行为。

所以这不是一个普通的新命令，而是对「开发者机器上长期驻留一个永久令牌」这一默认设定的修正——把「令牌一旦泄露就长期有效」改成「泄露后数小时内失效」。

为什么重要

开发者本地和自动化环境里，长期有效的令牌是最常见也最容易被忽视的暴露面：一次误提交、一次日志打印、一次脚本把 token 写进文件，就可能留下长期可用的凭据。到期令牌把这种风险从「永久」压缩成「小时级」，这是安全模型上的实质变化，而不是体验层的微调。

更关键的是它透露了方向：GitHub 正在把短期凭据推向默认路径，依赖长期令牌的工作流会逐渐从「正常用法」变成「需要特殊处理的例外」。

对谁有价值

• 本机使用 gh 的开发者：开启后基本无感，但安全性上了一个台阶。
• 维护 CI、脚本、内部工具的团队：需要提前排查哪些地方把令牌缓存下来复用。
• 企业环境的管理者：需要关注 GHES 版本对短期凭据的支持差异。
• 正在做 Agent、自动化流水线的人：这类系统大量依赖 gh 取令牌，是受影响的重点人群。

可以怎么行动

1. 先在个人环境试用：用 gh auth login --expiring 登录，或用 gh config set expiring_credentials enabled 全局开启，观察日常是否有摩擦。
2. 如果通过 HTTPS 访问 git，建议执行 gh auth setup-git，让 gh 作为 git 的凭据助手负责刷新，同时把 git 升级到 2.46 或更新版本，避免过期凭据被缓存超期使用。
3. 审计所有 gh auth token 的用法：凡是「取一次、存起来、以后一直用」的脚本都要改成每次实时读取，否则迟早会拿着一个已过期的令牌。
4. 梳理依赖「长期有效令牌」的工作流，这批先不要开，等改造完再切换。
5. 用 gh auth status 确认当前访问令牌的到期状态，把它纳入日常排障清单。

风险与限制

• 这是预览功能，行为细节仍可能变化，不适合在没有回退方案的关键链路上一次性全量铺开。
• 短期令牌会打断「缓存复用」类脚本和扩展，这类破坏往往是静默的——直到某次运行突然 401。
• GHES 3.23 之前不支持签发，开启后会回退到当前的永久令牌行为，版本不齐时各环境表现不一致。
• 旧版 git 仍能工作，但会打印一次性升级提示，长期看是技术债。
• 不开启则完全无变化，向后兼容，所以现在更大的风险是「不知道有这回事」，而不是「被强制改变」。

这条内容的真正价值，不只是“有人发布了一个新功能”，而是它揭示了 github.blog 背后的产品方向、工作流变化或竞争信号。对 OPC 来说，这种信息可以转化成持续追踪的栏目选题。

如果把《GitHub CLI：可选择启用会过期、自动刷新的 OAuth 令牌》放到你的内容系统里，它最大的价值在于帮助读者更快看懂“为什么值得关注”，而不是只看到一条碎片化动态。

• Allison 原帖