cursor 连 bitbucket 怎么配 双角色与 IP 放行
Bitbucket Cloud 公测接入：个人 OAuth、workspace 装 Cursor app、身份分工与 Data Center 只开 Bugbot 的差异。
团队代码在 Bitbucket 上，cursor 连 bitbucket 怎么配要先分清 Cloud 还是 Data Center：Cloud 公测同时支持 Cloud Agents 和 Bugbot；Data Center 只接 Bugbot，且要 Teams 或 Enterprise。漏装 workspace 级 Cursor app，个人账号连上了也看不到 Bugbot 以 Cursor 名义评论。
Bitbucket Cloud 两段式接入
官方文档把 Cloud 安装拆成两个角色、两条线，缺一不可。仓库必须在 bitbucket.org 上，Server 或 Data Center 域名不能走 Cloud 这条 OAuth 流程。
第一段：每个要用 Cloud Agent 或从 Cursor 开 PR 的开发者，在 Integrations 点 Bitbucket Connect，走 OAuth 授权，dashboard 显示 Connected。Cursor 用个人身份 clone、推分支、建 PR；PR 作者显示为你本人，不是 Cursor app。官方要求每个会启动 Cloud Agent 或从 Cursor 开 PR 的人各自连接 Bitbucket 账号，不能只有管理员连了、其他人裸跑 Agent。
第二段：Bitbucket workspace 管理员在 dashboard 选 Install Cursor app，装到 workspace；再在 Bitbucket workspace settings → Forge Apps → Cursor 里点 Connect to Cursor，由 Cursor team 管理员选要绑定的团队。Bugbot 摘要评论、行内评论、build status，以及 Cloud Agent 在 PR 上的进度评论，都走 Cursor app 身份。
装完 app 后 Bitbucket 通知 Cursor 可能要等几分钟；找不到 workspace 时先等再重试 Connect to Cursor。若一人兼两角色，可以连续做完 1–6 步；若 Bitbucket 管理员和 Cursor team 管理员是两个人，中间要交接「app 已装、等你 link team」的状态，避免误判为集成坏了。
身份分工一张表
排错时最常混的是「我个人连上了，为什么评论不像 Cursor」：
| 动作 | Bitbucket 侧身份 |
|---|---|
| Bugbot 摘要、行内评论、build status | Cursor app |
| Cloud Agent PR 进度评论 | Cursor app |
| clone、推分支、提交、开 PR | 已连接的个人账号 |
个人 OAuth alone 不够 app 评论。对照 Cursor Bugbot 怎么开 在 Automations 里按仓库启用；Automations 总流程见 Cursor Automations 怎么用。Bugbot check 在 Bitbucket 上 key 为 cursor-bugbot，结论仍是 success / neutral / failure 三类，和 GitHub 上 Cursor Bugbot check 语义对齐。
权限范围包括 Account、Repositories、Pull requests、Pull request write、Webhooks。Disconnect 也分两层：Disconnect account 只卸个人 OAuth；Disconnect Cursor app 只 unlink workspace，app 可能仍留在 Bitbucket，要 workspace 管理员在 Bitbucket 侧卸载才彻底停事件。
Bitbucket Data Center 另一条路
Data Center 需要 Cursor Teams 或 Enterprise，仅支持 Bugbot，Cloud Agents 不支持。前置：Cursor team 管理员、专用 service account、该账号的 HTTP access token、对目标仓库的 repository admin。Service account 负责读仓库与 PR、管 webhook、发 Bugbot 评论和 build status。
注册步骤：Integrations → Advanced → Bitbucket Data Center，填 clone URL 里的 Hostname；API 与 clone 不同 host 时再填 External Host；粘贴 Service Account Token → Register；再到 Bugbot Automations 按仓库打开。Unregister 实例后记得在 Bitbucket 撤销 token。
网络要求与 Cursor 连接自建 GitLab 同类：Cursor 要 HTTPS 访问你的实例，实例也要能 outbound 调 Cursor webhook。推荐 inbound allowlist 三个 IP：
184.73.225.134
3.209.66.12
52.44.113.131
无公网 inbound 的 Enterprise 客户可走 AWS PrivateLink、Cloudflare Tunnel 或反向代理隧道，需与 Cursor 侧对接；Google Private Service Connect 目前文档写明不支持。Load balancer 或 API 主机名与 clone 主机名不一致时，注册阶段就要填 External Host，否则 Cursor 列表仓库时会打到错误 endpoint。
Service account 令牌要有足够权限管理 webhooks；若 token 只读，Bugbot 可能能拉 diff 但收不到 PR 事件，表现为「手动 bugbot run 有评论、自动从不触发」。Disconnect Data Center 实例后务必在 Bitbucket 撤销 token，否则 orphaned webhook 仍指向 Cursor 已删的注册信息。
Cloud 与 Data Center 能力对照
| 场景 | Bitbucket Cloud | Bitbucket Data Center |
|---|---|---|
| Cloud Agents | 支持（公测） | 不支持 |
| Bugbot | 支持 | 支持（Teams/Enterprise） |
| 个人 OAuth + workspace app | 需要双角色 | 用 service account 注册 |
| 仓库域名 | bitbucket.org | 自建 hostname |
GitLab 自建是 Premium/Ultimate + Cursor Teams 另一套 OAuth 字段；Bitbucket Cloud 则强调 workspace Forge app。混平台团队别用 GitLab 文档里的 Redirect URI 去填 Bitbucket。Automations 里源码托管触发器对 Bitbucket 只覆盖 Cloud；Data Center 仓库只能指望 Bugbot 与手动 review，不能配「PR 评论触发 Cloud Agent」那类自动化。
排错顺序
Cloud Agent 访问不了仓库：先确认个人 Bitbucket 已 Connect，用户对 repo 有读写，且仓库在 bitbucket.org Cloud 上。Symptom 常是 agent 能列 repo 但 push 403，多半是个人账号缺 write 或 branch restriction。
Bugbot 评论不出现 Cursor 身份：查 workspace 是否装 app 且已 link Cursor team。只有个人 Connected、Forge app 未 link，PR 上可能完全没有 Bot 评论，或只有你自己 OAuth 发的内容。
装 app 却 link 不上 team：link 要 Cursor team 管理员，装 app 要 Bitbucket workspace 管理员；Bitbucket 用户必须能访问被 link 的 workspace。
Data Center 列不出仓库：查 token 是否有效、service account 是否有权、Cursor 能否 HTTPS 打到 hostname 或 External Host。Corporate proxy 拦截 outbound webhook 时，Bugbot 能注册但永远收不到 PR 事件。
Bugbot 开不了 DC 仓库：确认 team 管理员、实例已注册且 token 在、service account 对该 repo 是 admin。Repository admin 是 Bitbucket 侧要求，不是 Cursor 侧可降级选项。
Cloud 侧 PR 自动化若要用 Automations，触发器里的「源码托管」事件要求已接 Bitbucket Cloud；Data Center 仓库只能走 Bugbot 或人工 review。团队从 GitHub 迁到 Bitbucket 时，记得重新走双角色安装：GitHub 的 OAuth 与 Bitbucket Forge app 不互通，dashboard 里两个集成要分别绿勾。IP allowlist 三个地址与 GitLab Self-Hosted 文档相同，网络组可以一次性放行给 Cursor 集成用，减少重复工单。
公测阶段 Bitbucket Cloud 集成能力以文档为准；若你同时用 GitLab 与 Bitbucket，两套 identity 表不要混记：GitLab Bugbot 评论走 GitLab 应用身份，Bitbucket 走 Forge Cursor app。Cloud Agent 在 Bitbucket PR 上的进度评论同样依赖 workspace app，个人 Connected 只能保证 git 操作，不能代替 app 发 Bot 评论。
Permissions 表里 Account 用于识别 OAuth 用户，Repositories 用于 list/clone/read，Pull requests 读 diff 元数据，Pull request write 建 PR 和评论，Webhooks 收事件。缺 write 时 symptom 是 agent 能读不能推；缺 webhook 时 Automations 与 Bugbot 自动触发都不工作，但手动 cursor review 有时仍可用取决于平台缓存。
Bitbucket Cloud 公测功能与 GitHub 参照实现相比，Automations 触发器条目更少，文档已写明 Bitbucket 只支持 Cloud 域名。迁移期若 PR 同时 mirror 到 GitHub，应在 Cursor 里分别接好两套集成，不要假设 Bitbucket 连接会自动继承 GitHub 的 Bugbot 仓库列表。Data Center 团队若未来需要 Cloud Agent，只能换 Cloud 托管或改用 GitHub/GitLab，当前文档没有 DC Cloud Agent 路线图。Forge app 卸载后若 dashboard 仍显示 linked，在 Bitbucket workspace settings 里确认 Cursor app 已移除，再让 Cursor team admin 执行 Disconnect Cursor app，必要时等几分钟同步。