如果 Cursor 的 Background Agent 在 GitHub 上根本跑不起来，最常见的原因不是模型挂了，而是 GitHub 这一侧的接入条件没满足。Cursor 现在的官方文档写得很直接：Background Agents 和 Bugbot 都依赖 Cursor 的 GitHub App 来克隆仓库、创建分支和推送改动。
也就是说，只要 GitHub App 没装对、没拿到对应仓库权限，或者组织启用了 IP allowlist 却没放行，后台 agent 就算界面上能点，也很容易卡在“读不到仓库”“没有权限推 PR”“评论触发没反应”这些问题上。
现在最容易漏掉的有三层。第一，GitHub App 只装到了账号，没装到目标组织或目标仓库。第二，私有仓库权限不够，agent 能看到 issue 但拿不到代码。第三，组织启用了 IP allowlist，可是没有允许 GitHub Apps 继承预配置列表，或者没把 Cursor 文档里的 IP 手动加入。
正确的排查顺序建议这样走：
1. 到 Cursor 的 GitHub 集成页确认账号确实已经 connect。
2. 到 GitHub 里确认 Cursor App 安装范围包含目标仓库。
3. 如果是私有仓库，看仓库读写权限和 PR 写权限有没有给到。
4. 如果组织开了 IP allowlist，优先启用“Allow access by GitHub Apps”，不行再手动加 IP。
如果你是通过 @cursor 评论触发背景 agent，还要再检查分支保护规则。很多时候 agent 实际已经跑起来了，只是没有权限往目标分支推改动，于是看起来像“完全没动静”。
所以这类问题的判断方式很简单：只要报错集中在克隆、访问仓库、推送提交、写 PR 评论这些环节，优先排 GitHub App 和网络放行，不要先去折腾 Cursor 本地设置。Background Agent 的关键瓶颈，很多时候根本不在编辑器里。
