Table of Contents
You finish building a feature in Claude Code. The diff reads +2,148 −14, the branch is main, and all that is left is to press "Create PR" — and then a red banner appears at the top of the screen:
⚠ Invalid request
Could not check the pull request status.
This information may be out of date.
The annoying part is that the "Create PR" button is still right there, yet you can no longer tell what the current PR state is — whether it has not been created, is already open, or has been merged. Out of nowhere, and unrelated to your code changes, only "what this branch looks like on GitHub right now" becomes invisible.
Here is the bottom line: in most cases this is not a fatal error. Claude Code fetches PR state from GitHub through the GitHub CLI (gh), and when that query fails, this red banner appears. The cause is one of three things — gh is not installed, authentication does not go through, or the connection dropped for a moment — or this branch simply has no PR yet / has not been pushed to the remote. This article walks through the mechanism as written in the official docs and CHANGELOG, the 6 root causes, the diagnostic order, a command cheat sheet, and how to prevent a recurrence.
"Could not check PR status" at a glance
— Claude Code asked GitHub for the state; that one request failed
The essence: not "a code problem" but "a communication/authentication problem with GitHub."
Your work (code generation, commits) can usually continue. There is no need to rush into a new session.
1. What this error is actually saying
Read plainly, it says: "I could not check what state the pull request for this branch is in on GitHub right now, so the information shown on screen may be out of date."
What matters is understanding that two things have NOT happened. First, your code and your diff are not broken — the +2,148 −14 of changes are still right there in your working tree. Second, it does not say "PR creation failed." This is a read-side warning: "As a precursor to creating a PR, I tried to read the current PR state (not created / open / merged / closed) and failed."
In other words, this banner is a "could not sync" type of message, and it is usually temporary. My take: when you see this red banner, the first thing to suspect is not "your code" but "the connection state with GitHub" — specifically these three: whether authentication has expired, whether the network is reachable, and whether this branch is even in a state where a PR could exist (pushed to the remote).
2. Background: how Claude Code sees your PR
PR state (not created / open / merged / closed) lives only on GitHub's servers. Claude Code queries GitHub each time and reflects the answer in the badge and buttons on screen. The query path is spelled out in Anthropic's desktop app documentation and the Claude Code CHANGELOG, and both rely on the GitHub CLI (gh) (checked against the originals on September 30, 2026).
| Where | How PR state is fetched | Source |
|---|---|---|
| Desktop app, Code tab ("Create PR" and the CI status bar) | Polls check results with gh / requires gh to be installed and authenticated (if it is missing, Desktop prompts you to install it the first time you try to create a PR) | Desktop docs, "Monitor pull request status" |
| Terminal (CLI), PR badge in the prompt footer | Normally gh pr view / on Bedrock, Vertex, and Foundry, or with telemetry off, it calls the GitHub API directly with the token from gh auth token, GH_TOKEN, or GITHUB_TOKEN | CHANGELOG 2.1.251 |
| How often that badge checks | Checks less often while the PR is unchanged / a push or a gh pr command refreshes it right away / the re-check on terminal refocus is skipped if the last check is under a minute old | CHANGELOG 2.1.248, 2.1.247 |
So PR state can be fetched only when four things line up: "gh is installed, gh is authenticated, the network is reachable, and the branch and its PR exist on the remote." If any one is missing, you get the red banner. Also note that with the default browser login, gh stores its token in the system credential store, and falls back to a plain-text file only when that store is unavailable (gh auth status shows where; GitHub CLI manual, gh auth login).
What the official docs do not say
The details of how often the desktop app polls, and which failures produce "Invalid request", are not in the official documentation as of September 30, 2026. The diagnosis in this article rests on what the table above does document (whether gh is present, authenticated, and connected).
3. Why it happens — 6 root causes
The paths that lead to "could not check PR status" can be grouped into roughly 6. Checking them from the top down is the quickest route.
6 reasons PR state cannot be fetched
gh is not installedgh to be installed and authenticated (official). If gh --version fails, it is not installed. Get it from cli.github.com.gh is not logged in, or its token has been revoked. GitHub automatically revokes a token that has not been used for a year, and a PAT expires on the date set when it was created (GitHub Docs). gh auth status tells you.main), it is the same as the base, so no PR can be opened from it.gh auth login, repo, read:org, and gist are granted from the start (the official minimum). Permissions run short when you pass a PAT via --with-token or GH_TOKEN. A fine-grained PAT reaches only the repositories you allowed.gh, auth, and the network are all alive, it usually clears after a short wait and retry.
Causes 1–5 are configuration/state problems (fix them and they will not recur).
Cause 6 is transient. Starting with Causes 1–2 (gh present and authenticated) and Cause 3 (push/PR existence) is the fastest path.
4. Fix it now — the diagnostic order
When the red banner appears, work through 4 steps from the top down. STEP 1 and STEP 2 cover Causes 1–3.
The order to diagnose in
gh and authgh --version to see whether gh is installed, and gh auth status to check auth. If something is wrong, it exits with code 1 and says why. Re-login with gh auth login.git push -u origin <branch>, then confirm whether a PR exists with gh pr view or gh pr status. If none, just create one.gh auth refresh restores the minimum scopes.
The rule: "Suspect the GitHub connection before you suspect the code."
STEP 1's gh auth status is the single fastest move toward the real cause.
One more thing: even when this banner appears, your local commits and working tree are safe. There is no need to rush into git reset or to discard your session. Fix the connection first, then press "Create PR" again. If you still cannot create it from the GUI, run gh pr create in a terminal to create the PR without going through Claude Code's UI. If the branch has not been pushed yet, gh pr create asks where to push it (GitHub CLI manual).
5. Command cheat sheet
Here are the commands used for diagnosis. Run them top to bottom and you will naturally narrow down which CAUSE applies.
| Purpose | Command | What to look at |
|---|---|---|
Is gh installed? | gh --version | Does a version print (if not, install from cli.github.com) |
| Is auth alive? | gh auth status | Does "Logged in to github.com" appear / exit code 1 if there is a problem |
| Re-login | gh auth login | Browser auth by default (grants repo, read:org, gist) |
| Restore scopes | gh auth refresh | Brings the minimum scopes (repo, read:org, gist) back |
| Check remote config | git remote -v | Does origin point to the correct GitHub repo |
| Push the branch | git push -u origin <branch> | Satisfies the prerequisite for a PR to exist |
| PR for the current branch | gh pr view | Same method as the terminal PR badge / if this fails, so does the badge |
| PR list and state | gh pr status | Is there a PR for the current branch / open vs merged |
| Create PR via CLI | gh pr create | Create directly without the GUI (workaround) |
| Connectivity check | gh api rate_limit | A response means the connection is OK / check remaining for rate limits |
If gh auth status returns "Logged in" and gh pr view responds normally, then it is most likely just Claude Code's display being stale. Update to the latest version and restart, and the badge will re-sync correctly.
6. Can you ignore "may be out of date"?
The line "this information may be out of date" means different things in different situations. You want to distinguish when it can be ignored from when it needs action.
✅ Safe to ignore (harmless)
gh auth statusis fine- other Git/push operations go through fine
- it clears after a short wait / retry
- the PR badge just looks stale for a moment
→ Just a sync delay / cache. Keep working.
⚠ Needs action (real)
gh auth statussays "not logged in"- both push and pull fail
- it will not clear no matter how often you retry
- pressing "Create PR" does not progress
→ A real auth/connection problem. Fix it with STEP 1–3.
The deciding test is, again, a single gh auth status. If that is green (Logged in) and other Git operations go through, you can leave the banner alone. Conversely, if auth is down, then operations beyond PRs (push, fetching reviews, etc.) will sooner or later fail too, so it is wise to fix it on the spot.
7. Recurrence-prevention checklist
A practical checklist so the same red banner does not keep bothering you.
① On a new machine, install gh and finish gh auth login before creating PRs in Claude Code. ② Build a habit of occasionally checking gh auth status (GitHub revokes a token unused for a year, and a PAT expires on the date set at creation). ③ If you use a PAT, create a classic one with repo, read:org, and gist, or include the target repository in a fine-grained PAT. ④ Do not leave stale tokens in the GH_TOKEN / GITHUB_TOKEN environment variables (they take precedence over the stored login; GitHub CLI manual). ⑤ When you start work on a new branch, git push -u origin <branch> early. ⑥ On a corporate network (proxy/VPN), verify connectivity once with gh api rate_limit. ⑦ Keep Claude Code up to date — as the CHANGELOG shows, the way the PR badge is fetched has changed several times. ⑧ If the GUI is persistently unstable, switch PR creation to gh pr create.
Summary
Claude Code's "Could not check the pull request status. This information may be out of date" indicates not a code defect, but that the query to GitHub (which officially relies on the gh CLI) did not go through. It is usually a harmless sync delay, but behind it can hide a missing gh, expired auth, an un-pushed branch / missing PR, a network issue, or PAT permissions.
The fastest way to diagnose: ① check gh and auth with gh --version and gh auth status, ② check the push and PR existence with git push + gh pr view, ③ inspect connectivity and permissions, ④ if all is fine, wait and retry plus update to the latest version. When you truly cannot create it from the GUI, just create it directly with gh pr create. "Suspect the GitHub connection before you suspect the code" — remember that, and this red banner will no longer scare you.
Related reading: What is GitHub Copilot, What is the Claude Agent SDK, Claude Code's thinking blocks 400 error, and the Claude Code / Cursor deploy workflow.
FAQ
Q. If this error appears, will my code or diff be lost?
A. No. This is a communication-side warning that "the PR state could not be read"; it has zero effect on your local commits, working tree, or diff (such as +2,148 −14). There is no need to rush into git reset or to discard your session.
Q. What should I check first?
A. gh auth status. That single command tells you whether your GitHub authentication is alive. If you see "Logged in," auth is fine — it is usually transient, so wait and retry. If not, re-login with gh auth login and most cases are resolved.
Q. Can I leave "this information may be out of date" alone?
A. If both auth and the network are alive, yes. It is often just a sync delay / cache and clears after a short wait or retry. But if gh auth status says "not logged in," or even push fails, that is a real problem — fix it.
Q. "Create PR" will not go through no matter how many times I try.
A. Run gh pr create directly from the terminal, bypassing the GUI; that lets you create the PR itself. If it still fails, check whether the branch is on the remote with git push -u origin <branch>, and whether origin points to the correct repo with git remote -v.
Q. It happens often on my corporate network. Why?
A. A proxy, VPN, or firewall is likely blocking traffic to api.github.com. Check whether gh api rate_limit responds; if it does not, you need a network-side allowance (adding GitHub domains to the allowlist). Temporarily turning off the VPN to isolate the issue also helps.
Q. The PR badge under the terminal prompt stays stale.
A. According to the CHANGELOG, the badge checks less often while the PR is unchanged, and a push or a gh pr command refreshes it right away (2.1.248). If it does not update, check whether gh pr view works in your terminal. On Bedrock, Vertex, or Foundry, or with telemetry off, it calls the API directly with the token from gh auth token, GH_TOKEN, or GITHUB_TOKEN instead of gh pr view (2.1.251), so make sure that token is valid.
Q. gh auth status looks fine, but PR state still cannot be fetched.
A. Suspect the scope of the token actually in use. A fine-grained PAT reaches only the repositories you allowed, so a valid login can still fail to read PRs in the target repository. Also, when the GH_TOKEN or GITHUB_TOKEN environment variable is set, gh uses it in preference to the stored login (GitHub CLI manual). Check that no unintended token is set.
Related Claude Code errors: Claude Code errors reference, Unable to connect, 529 Overloaded / 500.