GitHub repository missing in Cloudflare Pages or Workers? Check access

Why teammates can see different repositories

On November 10, 2026, Cloudflare announced that the Workers Builds and Pages repository picker now follows the authorizing GitHub user. Previously, the list followed app installations linked to the Cloudflare account and could include repositories that the person could not actually access. The change makes the list reflect the current user.

Two members of the same Cloudflare account may therefore see different accounts, organizations and repositories. That difference alone does not establish that a repository was deleted, a project build failed or Cloudflare is experiencing an outage. Start by identifying the GitHub user in use.

What user authorization and app installation each control

User authorization lets the Cloudflare Workers & Pages app identify the current GitHub user. App installation determines which repositories it can access under a repository owner’s account or organization. These are separate steps, shown under Authorized GitHub Apps and Installed GitHub Apps respectively in GitHub settings.

When you first connect a repository, Cloudflare redirects you to GitHub to authorize the app when needed. Each person does this once, even if a teammate has already connected GitHub to the same Cloudflare account. The announcement says no extra action is needed if you have already authorized the app. If it is not installed on any account or organization you can access, an authorized person also needs to install it in the appropriate place.

Which accounts appear—and which are explicitly excluded

The account list can show your own GitHub account, and organizations where you can access at least one repository, when the app is installed there. Within those accounts or organizations, you only see repositories you can access. Seeing an organization name does not give you access to all of its repositories.

Other users’ personal GitHub accounts are no longer listed, even if they have shared a repository with you. In a hypothetical example, Alex invites Blake to collaborate on a repository owned by Alex’s personal account. Blake should still not expect Alex’s personal account in Blake’s Cloudflare picker. Reauthorizing or broadening installation scope cannot be promised to remove this exclusion. The announcement provides no universal migration procedure for that ownership scenario.

Check a missing repository in this order

First, confirm your GitHub user, the repository’s actual owner and whether you can access it on GitHub. If another person’s personal account owns it, apply the explicit exclusion above before repeating the same authorization attempt.

Second, check whether you have authorized Cloudflare Workers & Pages and whether the app is installed on the owning personal account or organization. If your own account or an organization is absent, the documented entry is Add GitHub account while connecting a repository. Adding an organization installation requires an owner or an appropriate role, such as GitHub Apps Manager. Ordinary membership alone does not establish installation permission.

Third, check the target repository against the app installation’s repository selection. Cloudflare recommends limiting access to repositories you intend to build; Only select repositories provides that scope. Your own repository access also limits the picker. Verify both layers, then handle missing access through the organization’s permission process instead of opening every repository by default.

This is a diagnostic sequence based on public rules. No account, authorization, installation or project was changed for this article, and no organization’s actual policy was tested. Record the user, repository owner, where the item is missing and the permissions already checked so an administrator can assess the problem.

Existing projects keep building; removing access affects new builds

Cloudflare explicitly says already connected projects are unaffected by the picker change and keep building. Treat a missing new connection target separately from the status of an existing project. The announcement cannot replace checking that project’s actual build result.

Workers and Pages share the same GitHub App. The integration guides say removing its access disables new builds for connected Workers and Pages projects using those repositories, while previous deployments remain hosted. For a picker problem, finish the identity and access checks first. If removal is necessary, an authorized administrator should assess connected projects in both products.

These sources announce no new fees, country eligibility list or deadline requiring every project to reconnect. They also do not establish applicable GitHub Enterprise Server versions. Check the actual product, repository ownership and organization permissions. Changing a network exit cannot replace GitHub authorization or app-installation permission.