目录
你在 Claude Code 里刚刚完成了一个功能。差异显示 +2,148 −14，分支是 main，剩下要做的只是按一下“Create PR”——这时屏幕顶部却弹出了一条红色横幅：
⚠ 无效的请求
无法检查拉取请求的状态。
此信息可能已过期。恼人的地方在于，“Create PR”按钮明明还在那里，可你却再也看不出当前 PR 处于什么状态了——它是还没创建、已经打开、还是已合并。莫名其妙地、与你的代码改动毫无关系地，只有“这个分支此刻在 GitHub 上是什么样子”这件事变得不可见了。
先说结论：大多数情况下这不是致命错误。Claude Code 通过 GitHub CLI（gh）向 GitHub 获取 PR 状态，这次查询失败时就会出现这条红色横幅。原因要么是 gh 没有安装、认证没通过、连接一时中断三者之一，要么是 这个分支根本还没有 PR / 还没推送到远程。本文依据官方文档和 CHANGELOG 梳理其机制、6 个根本原因、排查顺序、命令速查表以及如何防止再次发生。
一眼看懂“无法检查 PR 状态”
— Claude Code 向 GitHub 询问状态，而那一次请求失败了
本质：这不是“代码问题”，而是“与 GitHub 的通信/认证问题”。
你的工作（代码生成、提交）通常都可以继续，没必要急着开新会话。
1. 这个报错到底在说什么
直白地理解，它的意思是：“我现在无法确认这个分支的拉取请求在 GitHub 上处于什么状态，所以屏幕上显示的信息可能已经过期了。”
关键是要明白有两件事并没有发生。第一，你的代码和差异并没有损坏——+2,148 −14 的改动仍然完好地保留在你的工作区里。第二，它并没有说“PR 创建失败”。这是一条读取侧的警告：“作为创建 PR 之前的一个步骤，我尝试读取当前的 PR 状态（未创建 / 打开 / 已合并 / 已关闭），结果失败了。”
换句话说，这条横幅是一种“无法同步”类型的提示，而且通常是暂时性的。我的看法是：当你看到这条红色横幅时，首先要怀疑的不是“你的代码”，而是“与 GitHub 的连接状态”——具体来说就是这三点：认证是否已过期、网络是否可达，以及这个分支是否处于一个可能存在 PR 的状态（已推送到远程）。
2. 背景：Claude Code 是如何查看你的 PR 的
PR 的状态（未创建 / 已打开 / 已合并 / 已关闭）只存在于 GitHub 服务器上。Claude Code 每次都向 GitHub 查询，再把结果反映到屏幕上的徽标和按钮上。查询的途径写在 Anthropic 的桌面应用文档和 Claude Code 的 CHANGELOG 里，两者都依赖 GitHub CLI（gh）（2026 年 9 月 30 日对照原文确认）。
| 位置 | 获取 PR 状态的方式 | 出处 |
|---|---|---|
| 桌面应用的 Code 标签页（“Create PR”和 CI 状态栏） | 用 gh 定期获取检查结果 / 前提是 gh 已安装且已认证（没有安装时，第一次尝试创建 PR 会提示安装） | 桌面应用文档“Monitor pull request status” |
| 终端版（CLI）输入框下方的 PR 徽标 | 通常用 gh pr view / 在 Bedrock、Vertex、Foundry 上或关闭遥测时，改用 gh auth token、GH_TOKEN 或 GITHUB_TOKEN 的令牌直接调用 GitHub API | CHANGELOG 2.1.251 |
| 该徽标的检查频率 | PR 没有变化时减少检查次数 / 推送或执行 gh pr 命令会立即刷新 / 回到终端时，若距上次检查不到 1 分钟则跳过 | CHANGELOG 2.1.248、2.1.247 |
也就是说，只有 “gh 已安装、gh 已认证、网络可达、远程存在对应分支和 PR”这 4 个条件都满足，才能取到 PR 状态。缺任何一个，就会出现开头的红色横幅。另外，在默认的浏览器登录下，gh 会把令牌保存在 系统的凭据存储中，只有在无法使用时才写入明文文件（保存位置可用 gh auth status 查看；GitHub CLI 手册 gh auth login）。
官方文档没有写的内容
桌面应用多久查询一次、哪些失败会显示“无效的请求”等细节，截至 2026 年 9 月 30 日的官方文档中没有写明。本文的排查依据的是 上表中有文档记载的部分（gh 是否存在、是否已认证、是否连通）。
3. 为什么会发生——6 个根本原因
导致“无法检查 PR 状态”的路径大致可归为 6 类。从上往下逐一确认最快。
取不到 PR 状态的 6 个原因
ghmain），它与比较基准相同，无法从它创建 PR。gh auth login 时，repo、read:org、gist 一开始就会授予（官方规定的最低范围）。权限不够通常发生在 通过 --with-token 或 GH_TOKEN 传入 PAT 时。fine-grained PAT 只能访问你授权的仓库。gh、认证和网络都正常，通常 稍等片刻再重试就会消失。
原因 1–5 是 配置 / 状态问题（修好后不会再犯）。
原因 6 是 临时性的。先从原因 1–2（gh 是否存在及认证）和原因 3（推送 / PR 是否存在）查起最快。
4. 立即修复——排查顺序
出现红色横幅时，从上往下按 4 个步骤排查。STEP 1 和 STEP 2 就能确认原因 1–3。
排查的顺序
gh 和认证gh --version 确认 gh 是否已安装，用 gh auth status 检查认证。有问题时会以退出码 1 结束并给出原因。用 gh auth login 重新登录。git push -u origin <branch> 推送到远程，再用 gh pr view 或 gh pr status 确认 PR 是否存在。没有的话创建即可。gh auth refresh 恢复最低权限范围。
铁律：“先怀疑与 GitHub 的连接，再怀疑代码。”
STEP 1 的 gh auth status 是最快接近真正原因的一步。
补充一点：即使出现这条横幅，本地的提交和工作树也安然无恙。没有必要急着 git reset 或丢弃会话。先修好连接，再重新按“Create PR”。如果仍无法通过界面创建，可以在终端运行 gh pr create，不经过 Claude Code 的界面直接创建 PR。如果分支还没推送，gh pr create 会询问要推送到哪里（GitHub CLI 手册）。
5. 命令速查表
下面汇总排查用的命令。从上往下依次执行，自然就能缩小到是哪个原因。
| 目的 | 命令 | 看什么 |
|---|---|---|
gh 是否已安装 | gh --version | 是否输出版本号（没有就从 cli.github.com 安装） |
| 认证是否有效 | gh auth status | 是否出现“Logged in to github.com” / 有问题时退出码为 1 |
| 重新登录 | gh auth login | 默认是浏览器认证（授予 repo、read:org、gist） |
| 恢复权限范围 | gh auth refresh | 把最低权限范围（repo、read:org、gist）补齐 |
| 确认远程设置 | git remote -v | origin 是否指向正确的 GitHub 仓库 |
| 推送分支 | git push -u origin <branch> | 满足 PR 能够存在的前提 |
| 当前分支的 PR | gh pr view | 与终端版 PR 徽标的获取方式相同 / 这里失败的话徽标也取不到 |
| PR 列表与状态 | gh pr status | 当前分支是否有 PR / open 还是 merged |
| 用 CLI 创建 PR | gh pr create | 不经过界面直接创建（绕过办法） |
| 连通性检查 | gh api rate_limit | 有响应即连接正常 / 用 remaining 查看速率限制 |
如果 gh auth status 返回“Logged in”，并且 gh pr view 正常响应，那么很可能只是 Claude Code 这边的显示过时了。更新到最新版并重启，徽标就会重新正确同步。
6. “信息可能已过期”可以忽略吗
“此信息可能已过期”这句话在不同情况下含义不同。你需要分清什么时候可以忽略，什么时候必须采取行动。
✅ 可以忽略（无害）
gh auth status正常- 其他 Git/push 操作都能正常通过
- 稍等片刻 / 重试后就消失了
- 只是 PR 徽标短暂地显示成了旧状态
→ 只是同步延迟 / 缓存。继续工作即可。
⚠ 需要处理（真实问题）
gh auth status显示“未登录”- push 和 pull 都失败
- 无论重试多少次都消除不了
- 按“Create PR”毫无进展
→ 这是真正的认证/连接问题。用 STEP 1–3 修复它。
决定性的判断依据，再说一次，就是一条 gh auth status。如果它是绿色的（Logged in），而且其他 Git 操作都能通过，那你就可以不去管这条横幅。反过来，如果认证已经失效，那么除了 PR 之外的操作（push、获取评审等）迟早也会失败，所以当场修好它才明智。
7. 防止再次发生的清单
一份实用的清单，让同一条红色横幅不再反复打扰你。
① 在新电脑上，先 安装 gh 并完成 gh auth login，再用 Claude Code 创建 PR。② 养成 偶尔检查 gh auth status 的习惯（GitHub 会吊销一年未使用的令牌，PAT 会在创建时设定的日期到期）。③ 使用 PAT 时，classic 令牌要 带上 repo、read:org、gist，fine-grained PAT 则要把目标仓库加入授权范围。④ 不要在环境变量 GH_TOKEN / GITHUB_TOKEN 里留下旧令牌（它们优先于已保存的登录；GitHub CLI 手册）。⑤ 在新分支上开始工作后，尽早 git push -u origin <branch>。⑥ 在公司网络（代理 / VPN）下，用 gh api rate_limit 先确认一次连通性。⑦ 让 Claude Code 保持最新——从 CHANGELOG 可以看到，PR 徽标的获取方式已经改过多次。⑧ 如果界面始终不稳定，就改用 gh pr create 创建 PR。
总结
Claude Code 的“无法检查拉取请求的状态。此信息可能已过期”表明的不是代码缺陷，而是向 GitHub 发起的查询（官方以 gh CLI 为前提）没有打通。它通常只是无害的同步延迟，但背后也可能隐藏着未安装 gh、认证过期、分支未推送 / 缺少 PR、网络问题，或 PAT 权限不足。
最快的排查方法：① 用 gh --version 和 gh auth status 确认 gh 与认证，② 用 git push + gh pr view 确认推送与 PR 是否存在，③ 检查连通性与权限，④ 都没问题就等待重试并更新到最新版。实在无法通过界面创建时，直接用 gh pr create 创建即可。“先怀疑与 GitHub 的连接，再怀疑代码”——记住这一点，这条红色横幅就不再可怕。
延伸阅读：什么是 GitHub Copilot、什么是 Claude Agent SDK、Claude Code 的思考块 400 错误，以及 Claude Code / Cursor 的部署工作流。
FAQ
Q. 出现这个错误，我的代码或差异会丢失吗？
A. 不会。这是通信侧的警告，表示“无法读取 PR 状态”；它对你的本地提交、工作区或差异（比如 +2,148 −14）没有任何影响。没必要急着执行 git reset 或丢弃会话。
Q. 我应该先检查什么？
A. gh auth status。这一条命令就能告诉你 GitHub 认证是否仍然有效。如果看到“Logged in”，说明认证没问题——通常是临时性的，等一会儿再重试即可。如果没有，就用 gh auth login 重新登录，大多数情况就能解决。
Q. “此信息可能已过期”可以不管它吗？
A. 如果认证和网络都正常，可以。它往往只是同步延迟 / 缓存，稍等或重试后就会消失。但如果 gh auth status 显示“未登录”，或者连 push 都失败，那就是真正的问题——去修好它。
Q. 无论试多少次，“Create PR”都通不过。
A. 绕过 GUI，直接从终端运行 gh pr create，这样你就能创建出 PR 本身。如果仍然失败，用 git push -u origin <branch> 检查分支是否在远程上，并用 git remote -v 检查 origin 是否指向正确的仓库。
Q. 在公司网络下经常出现，为什么？
A. 很可能是代理、VPN 或防火墙阻断了到 api.github.com 的流量。检查 gh api rate_limit 是否有响应；如果没有，就需要在网络侧放行（把 GitHub 的域名加入允许列表）。临时关闭 VPN 来隔离问题也很有帮助。
Q. 终端输入框下方的 PR 徽标一直是旧的。
A. 根据 CHANGELOG，这个徽标 在 PR 没有变化时会减少检查次数，推送或执行 gh pr 命令会立即刷新（2.1.248）。如果不刷新，请确认 gh pr view 在你的终端里能否正常执行。在 Bedrock、Vertex、Foundry 上或关闭遥测时，它不用 gh pr view，而是用 gh auth token、GH_TOKEN 或 GITHUB_TOKEN 的令牌直接调用 API（2.1.251），所以要确认该令牌有效。
Q. gh auth status 正常，却仍然取不到 PR 状态。
A. 请怀疑 实际使用的令牌的访问范围。fine-grained PAT 只能访问你授权的仓库，所以即使登录有效，也可能读不到目标仓库的 PR。另外，如果设置了环境变量 GH_TOKEN 或 GITHUB_TOKEN，gh 会 优先使用它，而不是已保存的登录（GitHub CLI 手册）。请确认没有混入不该用的令牌。
相关的 Claude Code 错误：Claude Code 错误大全、Unable to connect、529 Overloaded / 500。
