Cursor GitHub 集成连接及权限配置教程

很多人在Cursor里点了GitHub连接，回到团队那边却找不到仓库，这事儿的常见原因真不是按钮坏了，大概率是管理员角色没配对、仓库授权范围没选对，或是组织网络限制少开了一项。顺着公开的设置路径走通，Cursor的Cloud Agents和Bugbot才能在你授权的仓库范围里干活；要是你没有组织管理权限，就把需要开的选项发给对应管理员确认，千万别拿自己的个人账号替整个组织授权。

适用范围：这套操作是给用GitHub.com的Cursor团队准备的，仅限Web端。开始之前得备好三样东西：一个Cursor管理员账号、一位GitHub组织管理员，还有打算开放给Cursor用的仓库清单。要是你用的是GitHub Enterprise Server、私有网络，或是组织有自己的安全策略，都有额外要求，别直接照搬GitHub.com的默认步骤。

先确认两个管理员角色都在场

入口位置：Cursor仪表盘的Integrations页面，还有GitHub组织的设置页面。主要动作：先确认当前操作的人，既能管Cursor团队的集成，又能给目标GitHub组织安装、配置GitHub App。

成功标志：在Cursor的GitHub项目旁边能看到Connect或者Manage Connection，同时GitHub组织也允许当前账号管理应用。失败处理：要是Cursor这边找不到连接入口，先去补团队管理员权限；要是GitHub那边只能看个人设置，就换组织管理员来做安装步骤，别硬着头皮继续选仓库。

这张图里GitHub.com标签下面，先列了两个管理员的必备条件，后面才是Integrations、连接按钮和仓库选择的内容。这个顺序可不能搞反：能看到GitHub App页面，不代表你当前的账号有权限替组织安装。

从 Cursor Integrations 发起 GitHub 连接

入口位置：打开Cursor Dashboard，进入Integrations页面，在GitHub项目旁边找到Connect；要是之前已经连过，这个入口就叫Manage Connection。主要动作：点这个入口，浏览器就会跳转到GitHub的应用授权流程。

成功标志：页面会跳到GitHub上的Cursor应用安装或配置界面，还能看到目标组织的选择项。失败处理：要是页面老是跳回Integrations，先看看你浏览器当前登的GitHub账号是不是属于目标组织，再确认下组织有没有限制第三方应用安装；别反复点击，搞出一堆没完成的授权会话。

在 GitHub 页面核对应用身份

入口位置：从Cursor跳过去的GitHub App页面，或是GitHub上公开的Cursor应用详情页。主要动作：核对清楚：应用名叫Cursor，类型是GitHub App，开发者标识也对应Cursor，没问题了再进入组织与仓库范围选择页面。

成功标志：名称、应用类型、开发者信息都对得上，页面上的用途说明也和云端智能体的工作内容匹配。失败处理：要是名字相似但开发者不对、页面是个人OAuth授权的，或是来源查不清楚，立刻停下来，别提交组织权限，退回去重新从Cursor Integrations入口进入。

这张图只是用来核对公开应用身份的，上面没显示任何私有组织、仓库选择或是授权结果，所以不能拿它证明某个团队已经接入。

选择全部仓库或指定仓库

入口位置：GitHub上的Cursor App安装配置页，在目标组织下面找到Repository access选项。主要动作：根据团队的边界选All repositories或是Only select repositories；对权限比较敏感的组织，优先从指定仓库开始，先选一个方便验证的小范围仓库。

成功标志：GitHub的配置页上清楚列着授权的组织与仓库范围，保存之后浏览器能跳回Cursor。失败处理：要是目标仓库不在列表里，先确认它是不是属于当前组织、当前账号有没有管理权，还有组织策略是不是禁止安装；别为了让列表里出现仓库，就乱选不相关的组织。

授权前读懂 GitHub App 权限

入口位置：GitHub安装确认页的权限说明，还有Cursor GitHub集成页面的Permissions区域。主要动作：一项一项对着核对：仓库访问、PR、Issues、检查与状态、Actions与工作流、Administration、自定义仓库角色、组织自定义属性，确认这些权限都和计划启用的Cloud Agents或是Bugbot功能对得上。

成功标志：管理员能说清每一项权限的具体用途，而且确认授权范围没超出团队计划接入的仓库。失败处理：要是搞不清某权限的用途，先暂停安装，找安全负责人核对组织政策；要是团队只打算测试一个仓库，就先缩小仓库范围，别想都不想就授权整个组织。

这张图里能看到Repository access、PR、Issues、Checks and statuses这四类权限和各自的用途。往下看同一张权限表，还能看到工作流、分支保护相关的管理信息、自定义仓库角色和组织自定义属性；这些都是功能边界说明，不是已经对某个仓库执行过操作的记录。

返回 Cursor 配置仓库功能

入口位置：在GitHub上保存好安装范围之后，回到Cursor Dashboard的Integrations页面，再进入GitHub连接管理页。主要动作：给刚授权的仓库开启团队需要的Cloud Agents或是Bugbot功能，同时核对仓库是不是在可配置范围内。

成功标志：在Cursor的GitHub连接里能选到目标仓库，对应的功能开关或是配置项都能正常保存。失败处理：要是GitHub显示已安装但Cursor里还是没有仓库，先回到Manage Connection检查仓库选择有没有保存，再确认是不是装对了组织；要是仓库能看到但功能用不了，就核对权限表和组织策略。

有 IP 允许列表时先开通托管出站访问

入口位置：先在Cursor这边申请给团队开通托管出站访问，再进入GitHub组织的Security与IP allow list页面。主要动作：开通之后启用Allow access by GitHub Apps，让已安装的Cursor App继承官方维护的地址范围。

成功标志：GitHub组织的IP allow list里允许GitHub Apps访问，Cursor发起的仓库请求不会再被网络规则拦截。失败处理：还没开通Cursor侧的能力时，别先去改GitHub的开关；开关启用后还是被拒绝，再对照Cursor页面列出的出站IP和组织列表，检查是不是还叠加了IdP或是私有网络限制。

图里的黄色提示框是前置条件，下面三步才是GitHub组织里的操作路径。要是跳过前置开通步骤，只打开Allow access by GitHub Apps，网络限制还是可能挡住仓库访问。

需要更严格隔离时设置受保护 Git 范围

入口位置：Cursor GitHub集成的Protected Git scopes配置页，还有对应GitHub组织的管理设置页。主要动作：把指定的GitHub组织绑定到正确的Cursor组织上，让仓库访问只落在预期的团队边界内。

成功标志：绑定关系里显示的是对应的Cursor组织与GitHub组织，团队只能在授权边界内看到仓库。失败处理：要是组织名称相近或是管理员身份不确定，别乱点保存；要是看不到绑定入口，先确认自己有没有GitHub组织所有者或是管理员权限，再检查Cursor的团队权限。

连接异常时按症状回查

入口位置：Cursor GitHub集成页面的Troubleshooting区域。主要动作：只展开和当前症状对得上的那一项：智能体无法访问仓库、PR权限被拒绝，或是应用在GitHub设置中不可见。

成功标志：能把问题归到仓库范围、权限策略或是应用可见性其中一类，还能找到对应的组织与连接设置。失败处理：要是仓库访问失败，先查Manage Connection里的仓库范围；要是PR被拒绝，就查分支保护、必需检查和写入权限；要是应用看不到，就确认你看的是组织设置，而且当前账号有管理应用的权限。

这张图里的三个折叠项，刚好对应访问、PR和应用可见性三类问题。先按症状选一项来查，能避免你一上来就同时改仓库范围、网络和分支保护，到最后反而说不清是哪处设置起了作用。

不再使用时从 Cursor 断开连接

入口位置：Cursor Dashboard的Integrations页面，进入GitHub连接管理页。主要动作：点击Disconnect account，然后按照团队的变更流程确认确实不需要这个连接了。

成功标志：GitHub集成回到未连接状态，Cursor不会再列出原连接的仓库相关功能。失败处理：要是断开之后GitHub组织里还显示这个应用，就分别核对Cursor的连接状态和GitHub App的安装状态；得等组织管理员确认好影响范围之后，再决定要不要在GitHub侧移除应用，免得误伤其他团队。

交给团队使用前核对这些状态

• Cursor管理员和GitHub组织管理员的职责，已经分别确认清楚。
• 连接是从Cursor Dashboard的Integrations发起的，GitHub App的名称和开发者身份都核对一致。
• 仓库范围明确选了全部仓库或是指定仓库，没把无关仓库一并开放。
• 仓库访问、PR、Issues、检查与状态、工作流和组织元数据这些权限，都有对应的业务用途。
• 回到Cursor之后能看到目标仓库，而且计划启用的Cloud Agents或是Bugbot配置都能正常保存。
• 启用IP允许列表的组织，已经先开通托管出站访问，再设置了Allow access by GitHub Apps。
• 受保护Git范围绑定的是正确的Cursor组织和GitHub组织。
• 仓库访问、PR权限和应用可见性问题，都是按对应入口分别排查的，没有同时修改多类设置。
• 五张页面截图都能正常加载，而且每张只承担一个主要证明点。