Cloudflare Pages / Workers 看不到 GitHub 仓库？先查授权与安装

为什么同一 Cloudflare 团队看到不同仓库

2026 年 11 月 10 日，Cloudflare 宣布 Workers Builds 和 Pages 的仓库选择器改为依据授权的 GitHub 用户显示内容。过去列表依据连接到 Cloudflare 账号的应用安装，可能显示本人实际无法访问的仓库；这次变化让列表对应到当前用户。

因此，两位成员属于同一个 Cloudflare 账号，也可能看到不同的账号、组织和仓库。这本身不足以证明仓库被删除、项目构建失败或 Cloudflare 服务中断，先确认正在使用哪个 GitHub 身份。

用户授权和应用安装分别决定什么

用户授权让 Cloudflare Workers & Pages 应用识别当前 GitHub 用户；应用安装决定它可访问哪个仓库所有者账号或组织中的仓库。两步分开进行，也分别出现在 GitHub 设置的 Authorized GitHub Apps 与 Installed GitHub Apps 中。

首次连接仓库时，Cloudflare 会在需要时跳转 GitHub，请你完成本人授权。每个人需做一次，即使同一 Cloudflare 团队的其他成员已经连接过 GitHub；如果本人此前已授权，公告说无需额外操作。若应用尚未安装到任何你可访问的账号或组织，还需由有权限的人完成相应安装。

哪些账号会出现，哪些明确不再列出

账号列表可显示已安装应用的本人 GitHub 账号，以及已安装应用、且本人至少有一个仓库访问权的组织。选择这些账号或组织后，只会看到自己可访问的仓库，不能把组织名称出现理解为拥有其全部仓库权限。

他人的个人 GitHub 账号不再列出，即使对方把某个仓库的访问权共享给你。作为假设例子，甲邀请乙协作甲个人账号下的仓库，乙仍不能据此期待在自己的 Cloudflare 选择器里看到甲的个人账号。这里不能承诺重新授权或扩大安装范围就会取消该排除规则；公告也没有提供针对这种所有权场景的通用迁移流程。

看不到目标仓库，按这个顺序检查

第一步，核对本人 GitHub 用户、目标仓库实际所有者，以及自己能否在 GitHub 访问该仓库。若所有者是他人的个人账号，先按上面的明确排除规则判断，不要反复尝试同一授权操作。

第二步，确认自己是否已授权 Cloudflare Workers & Pages，以及该应用是否安装在仓库所属的本人账号或组织。本人账号或组织没有出现时，官方入口是连接仓库时的 Add GitHub account；向组织添加安装需要组织所有者或适当角色，例如 GitHub Apps Manager，普通成员身份本身不足以证明可安装。

第三步，在已安装应用的仓库范围内核对目标仓库。Cloudflare 建议只开放实际需要构建的仓库，可用 Only select repositories 选择范围；仓库列表还受本人访问权限制。把这两层都核清后，再按组织权限流程处理缺失项，不要为找到一个仓库默认开放全部仓库。

以上是依据公开规则整理的排查顺序，本文没有操作任何账号、授权、安装或项目，也没有验证某个组织的实际策略。记录用户身份、仓库所有者、缺失位置和已核对的权限，通常比只写“看不到仓库”更便于管理员判断。

已有项目继续构建，卸载却会影响新构建

Cloudflare 明确说明，已经连接的项目不受这次仓库列表变化影响，会继续构建。因此，选择器找不到某个新目标与已有项目的构建状态应分开核实；公告不能代替查看某个项目的实际构建结果。

Workers 与 Pages 共用同一个 GitHub App。官方文档说明，移除应用访问权会停止相关仓库所连接的 Workers 和 Pages 项目的新构建，之前的部署仍继续托管。若只是排查列表变化，先完成上述身份与权限检查；确需卸载时，应由有权限的管理员评估两个产品的关联项目。

这些来源没有宣布新的费用、国家资格名单或要求所有项目重新连接的截止日，也没有确认 GitHub Enterprise Server 的适用版本。按实际产品、仓库所有权与组织权限判断，不能用切换网络出口代替 GitHub 授权或安装权限。