泄露的令牌几小时就失效：GitHub CLI 的过期 OAuth 预览，值得现在就试点

一句话先说清：泄露的 gh 令牌，今后几小时就失效

2026 年 10 月 21 日，GitHub 在官方更新日志里宣布：命令行工具 GitHub CLI（gh）从 v2.103.0 开始，提供公开预览版的过期 OAuth 凭证。选择加入之后，gh 不再只存一个永不过期的访问令牌，而是存一对凭证：一个几小时就过期的访问令牌，加一个会轮换的刷新令牌。gh 会在需要的时候自动刷新，你不用反复重新登录；而一旦访问令牌泄露，它会在几小时内自己失效，而不是像今天这样一直有效，直到有人手动发现并吊销。

先把这句话里的限定词讲清楚，因为它们决定了这条新闻的真实分量。第一，这是公开预览，不是默认行为；第二，它是选择加入的，不选就什么都不变；第三，GitHub 明确说了，未来某个版本会把它变成新登录的默认设置。所以这不是一次强制迁移，而是一次提前发给你的准备时间：现在试点的人，是在默认翻转之前把自家脚本和流水线先过一遍；等到默认翻转那天才动手的人，付出的就是同一份工作，外加一份措手不及。

我的判断是：这是今年命令行工具里最值得普通开发者认真对待的一次安全改动，不是因为它用了什么新奇技术，而是因为它修的正是大家最容易忽视的那类风险——一个早就躺在某台机器、某个脚本、某次备份里的旧凭证。凭证泄露的新闻从来不少，真正的区别只在于泄露之后你还有多少时间反应。把“无限期”改成“几小时”，就是把一次事故的窗口从“不知道多久”收窄到“一个下午”。这仍然不是万无一失，但它改变了攻防双方的算术。

这次到底改了什么：两条命令，一个开关

用法本身非常简单，这也是它值得试点的原因之一。单次登录时带上过期标志：gh auth login --expiring。想让以后每一次登录都默认走过期凭证，就改一次配置：gh config set expiring_credentials enabled。之后日常使用没有任何新步骤，gh 会在后台自动刷新凭证。想确认当前凭证的状态，运行 gh auth status，它会告诉你凭证是否可刷新，以及当前访问令牌什么时候过期；v2.103.0 的发布说明还提到，状态里会显示相对剩余时间，也就是“还有几小时过期”这种一眼能看懂的说法，而不是让你自己去算时间戳。

关键在于“选择加入就什么都不变”之外的另一面：不选择加入，也真的什么都不变。GitHub 更新日志写得很直白——如果你不通过标志或配置选择加入，现有登录和手动提供的令牌都会和以前完全一样工作。这意味着试点可以从一台机器开始，不用先说服整个团队，也不用先重构流水线。你可以在自己的笔记本上开过期凭证，跑一周日常命令，确认没有脚本报错，再决定要不要推广到团队的共享机器和自动化账号上。

还有一个细节值得单独拎出来：过期凭证是“向服务器要”来的，不是本地硬造的。gh 发出的是“请给我可刷新的凭证”这个请求，如果服务器不支持，gh 会干净地退回到今天这种不过期令牌，而不是报错罢工。这个退回逻辑对自建用户尤其重要，后面讲版本门槛时会再展开。但它的另一层意思是：--expiring 不是一个保证，而是一个偏好。最终拿到什么样的凭证，取决于服务器支不支持，这一点在判断试点范围时要记在心里，不能假设“开了标志就一定过期”。

为什么是现在：永久令牌配上 Agent 时代，出事成本变了

gh 的 OAuth 令牌长期以来没有过期时间，这在只有人坐在键盘前敲命令的年代，算是个可以接受的折中：令牌丢了，责任人 revoke 掉，再登录一次，事情就过去了。但今天调用 gh 的早就不限于人。写代码的 Agent 会在后台替你跑 gh 查 issue、开 PR、推分支；持续集成跑在共享的 Runner 上；一台团队共用的笔记本可能同时跑着好几个自动化任务。调用方越多，令牌被复制、被缓存、被写进某个日志或备份的路径就越多，而“直到有人发现才失效”这个条件，在自动化环境里恰恰是最难满足的——没有人会每天盯着一台机器的凭证有没有外泄。

更麻烦的是凭证的存放方式。没有系统凭证库的机器上，gh 会把令牌写进纯文本文件。这不是 gh 独有的问题，很多命令行工具都有类似的退路，但它确实意味着：一次信息窃取软件的收获、一次不小心的 dotfiles 备份、一次把家目录打包发给别人的操作，都可能把一个永久有效的 GitHub 身份顺带送出去。过期凭证并不能阻止令牌被偷走，这一点必须诚实地说清楚；它改变的是偷走之后的故事：偷到的是一个几小时后就作废的访问令牌，而不是一张长期通行证。

当然，严谨一点还要补半句：刷新令牌本身仍然是一把钥匙。过期凭证的设计是把风险从“一个永不过期的秘密”转移到“一个会轮换的秘密”上，而不是把秘密变没了。轮换机制让旧的刷新令牌在轮换后失效，这比静态秘密强得多，但它仍然要求你保管好存放凭证的那台机器和那个凭证库。把过期凭证理解成“从此不用管凭证安全”，那就读反了这条新闻；正确的理解是“凭证安全的容错空间变大了”，而不是“凭证安全本身消失了”。

两把钥匙是怎么配合的：短命的那个干活，轮换的那个续命

这套机制可以打一个简单的比方：访问令牌是一张当天有效的临时门禁卡，刷新令牌是放在保险柜里的续卡凭证。gh 每天干活时刷的都是临时卡，临时卡过期了，gh 自己拿续卡凭证去换一张新的，不用你重新去前台登记。这个比方里有两个要点值得注意。第一，续卡是自动的，这是它和“每隔几小时手动重新登录”那种折磨人的方案的根本区别；如果过期凭证要求你不断重新认证，那它在实际工作中根本推行不下去。第二，续卡凭证会轮换，每次续卡之后，上一张续卡凭证就作废了，这样即使续卡凭证泄露，攻击者能用的窗口也被压缩了。

这个设计还有一个附带的好处：它让“凭证状态”变成了一件可以检查的事情。以前的永久令牌没有什么状态好查，能用就是能用，不能用就是被吊销了。过期凭证引入了“什么时候过期”“能不能刷新”这两个可观测的维度，gh auth status 就是把它们摆到台面上的工具。对管理多台机器的人来说，这意味着排查问题时多了一个抓手：某台机器的 gh 突然不能用了，先看状态里写的是“凭证过期且无法刷新”还是“根本没走过期凭证”，定位方向立刻就不一样了。

但也别把自动刷新想得太神奇。自动刷新只在 gh 自己调用的时候发生，它解决的是“gh 自己用的凭证”这个问题，而不是“所有拿到过这个令牌的程序”都能自动续命。这一点直接引出下面最重要的一节：到底什么会在切换后断掉。

会断掉的第一批东西：所有把令牌缓存起来再用的脚本

GitHub 更新日志里专门用一段话警告了这件事，v2.103.0 的发布说明也用了“重要”来标出同一条：过期访问令牌不应该被缓存。任何运行 gh auth token 然后把输出存下来、之后反复使用的脚本或扩展，最终都会握着一个过期的令牌。正确的做法改起来其实不难，就是把“取一次、存起来、到处用”改成“每次需要时现取”：每次调用 gh auth token 都会在需要时刷新，拿到的是当下有效的令牌。这个改动是机械的，但前提是你得先找到那些脚本。包装器、上传脚本、聊天机器人、定时任务、被遗忘的个人小工具，都是藏匿点。试点之前先 grep 一遍，比试点之后到处救火便宜得多。

有两类令牌明确不受影响，这也是试点时可以放心的部分。第一类是手动提供的令牌：用 gh auth login --with-token 交进去的经典个人访问令牌（PAT），更新日志说它和以前完全一样工作。第二类是环境变量令牌：v2.103.0 发布说明明确写了，通过 GH_TOKEN 或 GITHUB_TOKEN 提供的令牌永远不会被刷新。这意味着 CI 里用环境变量认证的那条路，不会因为你在某台开发机上开了过期凭证就突然变卦；反过来也意味着，环境变量这条路的安全模型没有因为这次更新而自动变好，它仍然是“令牌有效期有多长，风险窗口就有多长”，需要另外用轮换策略去管。

所以一个务实的试点顺序是这样的：先在个人机器上开过期凭证，跑日常命令；再去翻自己的脚本和扩展，凡是缓存 gh auth token 输出的一律改成现取；最后才考虑把配置推广到团队的共享环境。而真正依赖长期有效令牌的工作流——比如某个离线很久才跑一次、又没法交互式重新登录的任务——GitHub 的建议是先别给它开过期凭证。预览的意义就在于允许这种“分批走”，而不是逼所有人在同一天切换。

Git 与自建版的两道门槛：先升级，再谈过期

如果你用 HTTPS 方式让 git 走 gh 的认证，这里有两件配套的事要做。第一，把 gh 设为 git 的凭证助手：gh auth setup-git。这样 git 在需要凭证时问 gh 要，gh 会给它一个新鲜的、会刷新的凭证，整个 HTTPS 克隆和推送流程就不用你操心过期问题。第二，把 git 升级到 2.46 或更新版本。这个版本让 gh 可以把凭证标记为过期凭证，从而不被缓存到过期之后；更新日志说，旧版本 git 也能工作，但会打印一次升级建议。听起来只是个建议，但背后的风险是真实的：一个会把凭证缓存起来的旧助手，完全可能在过期之后还把旧令牌递出去，让“过期”这个设计在 git 这条路上打了折扣。所以这一条别当成可选项，尤其是在 Agent 频繁克隆仓库的机器上。

自建版用户要看的版本号是 GitHub Enterprise Server 3.23。过期令牌在 github.com 和 ghe.com 上今天就能用，自建版从 3.23 开始发放；更早的版本上选择加入会干净地退回到今天的不过期行为，不会报错，也不会假装自己已经过期了。这个“干净退回”值得肯定，因为它避免了最糟糕的那种失败模式：表面上开了过期，实际上还是永久令牌，而你却以为自己已经安全了。但它也带来一个管理上的要求：如果你在混合环境里推行过期凭证，得先分清哪些服务器已经到了 3.23，哪些还在退回模式，否则同一套配置在不同服务器上的实际安全效果是不一样的。

把这两道门槛放在一起看，结论其实很简单：过期凭证不是一个“开个开关就完事”的功能，它是一次小型的认证卫生清理。升级 git、设好凭证助手、确认服务器版本，这三件事做完，过期凭证的好处才能完整兑现；跳过它们，好处就会在某条具体的链路上漏掉。

我的判断：现在试点，是因为默认翻转的那天不会等你

GitHub 已经把话说在前面了：过期凭证今天是选择加入，未来某个版本会变成新登录的默认设置。这句话的潜台词是，现在的预览期就是留给你的迁移窗口。窗口期做试点的成本是一台机器、一次脚本排查；默认翻转之后再做的成本，是所有没排查过的脚本在同一时间出问题。两者做的是同一件事，价格完全不同。这就是我建议“现在就试点”的全部理由，不需要任何更宏大的论证。

但试点也要有试点的方法。我的建议是分三步走：第一步，在个人机器上开过期凭证，跑一周，确认日常命令、git 操作、常用扩展都没有异常；第二步，排查脚本和扩展，把缓存令牌的改成现取，把依赖长期令牌的工作流单独列出来、暂缓切换；第三步，定一个团队内推广的时间点，并且把 git 2.46 和 GHES 3.23 这两个版本条件写进推广清单里。做完这三步，默认翻转对你来说就只是一次无感的默认设置变化，而不是一次紧急排障。

最后回到价值本身。过期凭证不会消灭凭证泄露，也不会替代轮换、最小权限和审计这些基本功。它的价值在于把一次泄露的后果从“无限期”收窄到“几小时”，并且用自动刷新把这个收窄做得不打扰日常工作。安全领域里很多改进都是这种性质：不解决所有问题，但把最坏情况的上限往下拉了一大截。对于每天都在用 gh 的人来说，这样的改进值得在预览期就认真对待，而不是等到它变成默认设置的那天，才发现自家脚本里还藏着一个缓存令牌的老习惯。

再补一句：预览期的真正价值，是暴露你自己的清单

很多团队在评估这类预览功能时，会先问“它稳不稳”，再问“我们要不要上”。但对过期凭证来说，顺序其实应该反过来：先用它照一照自家的现状，再决定推广节奏。因为一旦你在试点机上开了过期凭证，那些平时藏得很好的问题会自己浮出水面——某个半年没人动过的定时脚本突然报错，某个扩展在过期后拿着旧令牌反复重试，某台共享机器上的 git 因为版本太旧而打印升级提示。这些报错看起来是麻烦，实际上是预览期送给你的免费清单：它们平时也在，只不过以前被永久令牌掩盖住了。

从这个角度看，GitHub 把这次更新做成“选择加入、干净退回、未来再变默认”的三段式，是相当克制的做法。它没有逼任何人在同一天切换，也没有让不支持的服务器假装支持，而是把决定权和时间都留给了用户。用户这边对应的做法，也应该是同样克制的：先在一台机器上验证，再排查脚本，最后定推广时间。安全改进最怕的不是动作慢，而是动作大：一次全量切换带来的排障，往往比它要解决的风险本身更伤团队的信任。预览期的存在，就是为了让你不用付出这个代价。