[BUG] Repo picker search only filters already-loaded repos, so repos past the pagination boundary appear missing

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

The repository picker at claude.ai/code lazily paginates the repo list, but the search box filters only the subset already fetched into the client. A repo that hasn't been paged in yet is invisible to search, and the empty state then blames the Claude GitHub App.

Searching github.io for my repo venpopov/venpopov.github.io returned "No repos match", plus the hint: "Repo missing? Install the Claude GitHub app in a private repository to access it here."

That hint is wrong on every count in my case. The repo is public, not private. The App is installed on my account with access to all repositories. And per the docs, App installation "is not a session-level access control" — a cloud session can reach any repo the connected account can see, so installing the App could not have been the fix regardless.

After scrolling the list manually to force the remaining pages to load, the exact same query matches the repo immediately. Same account, same query, seconds apart — the only variable is whether the list had been scrolled.

Two separate defects:

1. Search doesn't hit the server. Filtering the locally-cached page makes search strictly less useful than scrolling, which is the opposite of what a search box implies.
2. The empty-state hint asserts a cause that is frequently not the cause, and prescribes a fix that cannot work, sending users to reinstall the GitHub App instead of scrolling.

What Should Happen?

Typing a repository name in the picker should match any repository the connected GitHub account can see, regardless of whether that repo has been paged into the client yet. Either the search should query the full repo set server-side, or the picker should finish loading the complete list before enabling the filter.

When a query genuinely returns nothing, the empty state should not assert that the repo is private and needs the Claude GitHub App installed. That is a guess, and per the docs App installation isn't required for session access anyway.

Error Messages/Logs

Steps to Reproduce

1. Have enough repositories on the connected GitHub account that the picker paginates. Mine stopped loading around repos beginning with c, alphabetically.
2. Open the repo picker at claude.ai/code and, without scrolling, type a substring matching a repo that sorts after that boundary. For me: github.io, for venpopov/venpopov.github.io.
3. Observe: "No repos match", plus "Repo missing? Install the Claude GitHub app in a private repository to access it here." (screenshot attached)
4. Clear the search. Scroll the full list manually. On reaching the boundary, the remaining repos load after a few seconds.
5. Type the same query again. The repo now appears and is selectable. (screenshot attached)

Repo used: venpopov/venpopov.github.io — public, 111 commits, default branch main. Claude GitHub App installed on a personal account with access to all repositories.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.226 (Claude Code)

Platform

Other

Operating System

macOS

Terminal/Shell

Other

Additional Information

This may account for a large share of the existing "repo not visible in the picker despite the GitHub App being installed" reports, most of which are closed as duplicates of a presumed backend repository indexing bug, with users asking for manual index resets: #27155, #57161, #60493, #60637, #65601, #68517, #79353, #12839, #18467, #33875, #54330, #55557, #57850, #34523, #61019, #43692.

Those reports all follow the same shape — open picker, type repo name, see nothing, conclude the repo isn't indexed — which is exactly the symptom this pagination bug produces, and the empty-state hint actively steers the diagnosis toward the GitHub App. Alphabetical ordering means it hits users whose target repo sorts late, which looks random and account-specific from the outside, and explains why reinstalling the App never fixed it for anyone.

I can't tell from outside how many of those are this bug versus a real index problem, but it seems worth checking before more index resets are issued by hand.