Cursor Origin 上手：把仓库放到它自己的托管上

2026-08-18

如果你已经在用 Cursor 写代码，某天看到 cursor.com/codebase 这个入口，大概率会冒出一个问题：代码不是在 GitHub 上好好的吗，为什么还要再来一个托管？

Origin 是 Cursor 的 git forge（官方文档《Origin》页的原话是 “Cursor’s git forge for storing and sharing code”），用来托管仓库、从 GitHub 同步项目、在浏览器里浏览团队的 Origin 仓库。这篇只讲三件具体的事：怎么把仓库建起来、怎么克隆和推送、仓库 Settings 里到底有哪些分区。

先把最重要的一条放在最前面：官方文档在 Origin 的每一页顶部都挂着同一句声明——Origin 目前处于 early beta。原文列出的 early beta 可用范围是：建仓、用 git 推拉、从 GitHub 镜像、浏览与搜索代码、开启与合并 pull request、与 Cursor 团队共享。这句话不是营销话术的免责尾巴，它直接对应了本文第四节里那几处「现在还不保证」的地方，别跳过。

一、先确认你有没有资格开这个功能

前置条件这一段最容易被跳过，但 Origin 卡人卡得比较靠前，值得逐条对一遍。

计划档位。 官方文档《Origin》页写明：Origin 的代码存储在 Pro、Teams、Enterprise 计划上可用，free 计划不可用。同一段还写了一句容易被忽略的话——访问权限是分阶段开放的（“Access opens in stages”），所以即使你的计划已经覆盖，也可能不会立刻看到 Origin。你要是对着文档一步步做却找不到入口，先把这条排除掉，别急着怀疑自己操作错了。

Privacy Mode。 文档写明 Origin 遵循命名空间所有者（团队或拥有该仓库的个人）的 Privacy Mode。并且有一条硬限制：仍处于 legacy privacy mode 的团队无法启用 Origin，想用就得先切到 Privacy Mode。这条在《Origin》和《Codebase settings》两页里都写了，两处措辞一致，别指望换个入口能绕开。

codebase name 必须先被认领。 这是 Origin 的第一步，也是最容易理解错的一步。文档说：团队用 Origin 之前，得有人先认领一个 codebase name，这个名字就是你的仓库所在的命名空间，也就是 https://cursor.com/codebase/{owner}/{repo} 里的 {owner}。文档写的是任何团队成员都可以在 cursor.com/codebase 通过 Get Started 走认领流程；《Codebase settings》页在描述同一件事时写的是「团队 admin 认领 codebase name 并启用 Origin，非 admin 可以从同一页面申请访问」。两页口径略有出入，你按自己的角色试一次就知道落在哪一边——这种地方我不替官方圆场。认领完成后，admin 才能创建仓库并把仓库访问权分给团队其他人。

镜像 GitHub 的额外前提。 如果你走的是「把 GitHub 上现成的仓库搬过来」这条路，《Mirror a GitHub repository》页另外列了三条：Pro/Teams/Enterprise 计划上有 Origin 访问权的 Cursor 账号、Cursor GitHub app 已连接到拥有该仓库的组织或账号、以及你在那个 GitHub 仓库上得是 admin（这条是启用镜像的必要条件）。

Origin CLI 装在哪个端上。 《Install the CLI》这一页的小节标题逐字是「macOS, Linux and Windows (WSL)」。也就是说，官方文档给出的 Windows 安装路径是 WSL 里的那条 shell 命令；原生 Windows（PowerShell / cmd）下怎么装 Origin CLI，官方文档没有说明这一点。需要提醒的是，别以为「不装 CLI、直接走 HTTPS 克隆」就能绕过去：《Clone, Push & Pull》页写的是第一次 git 操作之前先用 Origin CLI 登录（origin auth login），而且这一步同时会装好 git 的 credential helper；该页的排查建议第一条也是确认你已经登录过。换句话说，官方文档描述的凭据链路是围绕 Origin CLI 展开的，一条完全不经过 CLI 的认证路径，文档里没有说明。Windows 侧要不要上 WSL，得按这个前提来权衡。另外文档特意提醒：Origin CLI（origin）和 Cursor Agent CLI（agent）是两个东西，别混。

二、建仓、克隆、推送

官方文档给了三条建仓路径，我按「不装任何东西」到「让 agent 代劳」的顺序排。

路径 A：在网页上建空仓库。 《Create an Origin repository》页写的步骤是：在 cursor.com/codebase 里选 New，在 New repo 对话框里填 Repo Name 并选 Internal 或 Private 可见性，然后选 Create Repo。可见性两档的语义文档写得很清楚：Internal 是团队里有该 codebase 访问权的人都能看到；Private 只有被直接授权、或通过 codebase 权限授权的成员能看到。建完之后从仓库里的 Code 入口复制克隆地址。（这里只复述文档给出的操作项名称，界面长什么样、按钮在哪，我们没有依据，不描述。）

拿到地址之后是标准 git，文档给的初始化流程原样抄在这里：

git clone https://origin.cursor.com/{owner}/{repo}.git
cd {repo}
# add your files
git add .
git commit -m "Initial commit"
git push -u origin main

本地已经有项目、只是想加个 remote 的话：

git remote add origin https://origin.cursor.com/{owner}/{repo}.git
git push -u origin main

《Clone, Push & Pull》页还给了一个我觉得挺实用的过渡姿势：评估期间让 GitHub 和 Origin 并行接收推送。

git remote set-url --add --push origin git@github.com:acme/checkout.git
git remote set-url --add --push origin https://origin.cursor.com/acme/checkout.git

上面 acme/checkout 是官方文档里的示例仓库名，换成你自己的。文档同时提醒：想把 GitHub 的完整历史搬进 Origin，别用这种双推的土办法，走镜像。

路径 B：Origin CLI。 安装与登录两条命令，原样照抄：

curl -fsSL https://downloads.cursor.com/origin/install.sh | sh
origin auth login

文档写明安装器把二进制放在 ~/.local/bin/origin。如果 shell 报 command not found: origin，把这个目录加进 PATH——zsh 追加到 ~/.zshrc、bash 追加到 ~/.bashrc，文档两种都给了写法。origin auth login 会走浏览器流程，用有 Origin 访问权的 Cursor 账号完成登录；这一步同时会装好 git 的 credential helper，所以之后对 Origin remote 的 git push、git pull 不用再单独配凭据。登录也可以不走浏览器：origin auth login --api-key <YOUR_API_KEY>，或者设好 CURSOR_API_KEY 环境变量后直接 origin auth login（文档写明设了这个变量就会跳过浏览器流程）。

建仓和删仓：

origin repo create my-project
origin repo delete acme/my-project

文档明确了两者的参数规则：origin repo create 不带斜杠时，仓库建在你账号的命名空间下；origin repo delete 必须给完整的 org/name。命令参考页另外列了 create 的 --default-branch <branch> 选项，并注明服务端默认分支是 main；delete 的 -y, --yes 用来跳过确认提示，在非交互 shell 里是必须的——写 CI 脚本的话这条别漏。

路径 C：让 Cursor agent 建。 文档说可以在 Cursor 里让 agent 把建仓当成任务的一部分：它能装 Origin CLI、登录、建仓、设 remote、推送。关键那句限制也要一并记住：agent 用的是你 Cursor 账号的同一套权限，你自己没有 Origin 代码存储的访问权，agent 也建不成。Cloud Agent 那边文档写的是可以在已有的 Origin 仓库上工作——克隆、开分支、提交、推送、开 pull request。

路径 D：从 GitHub 同步。 在 codebase 首页选 Sync from GitHub 而不是 New，选好 GitHub 组织与仓库后确认。哪些东西会跟过来，文档给了一张明确的对照表：git 历史 / 分支 / 标签、可浏览可搜索的代码、双向同步的 pull request、持续更新会同步；GitHub Issues 和 GitHub Actions 的 workflow 与 secrets 不同步。镜像仓库上推 Origin remote 会透传回 GitHub，GitHub 仍然是 source of truth。

三、仓库 Settings 里有什么

《Settings》页写明：仓库 Settings 包含 General、Permissions、Rules and Protections、Apps 四个分区，作用范围是单个仓库；团队级的设置在 Codebase settings 那边，两者别记混。

General：镜像仓库在这里能看到 Sync Status（Origin 是 mirror、GitHub 是 source，并带一个指向源仓库的链接）；在 Origin 上直接建的仓库不显示同步状态。这一节下面还有 Danger Zone → Detach from GitHub：停止与 GitHub 的同步，把 Origin 这份变成独立的 Origin 托管仓库，Origin 成为 source of truth，之后推到 Origin remote 的内容不再流向 GitHub；文档写明你的 GitHub 仓库本身不受影响。
Permissions：用来查看谁能访问这个仓库。可见性是建仓时选的；文档补了一条细节——当一个仓库被切成 Private 时，做这个变更的人会自动保留 admin 访问权。
Rules and Protections：配置该仓库的分支规则与合并保护。
Apps：把第三方工具接到这个仓库。early beta 期文档列出的可连接对象是 Vercel（关联账号后，推送可触发部署、pull request 可获得预览环境）、Depot 与 Buildkite（在 Origin 托管仓库上跑 CI）。仓库的 Apps 分区显示的是「本仓库装了哪些」，真正的安装与管理入口是 codebase 级的 Apps 设置。

四、边界：这几处 beta 期明确受限

整个 Origin 是 early beta，文档每一页顶部都标了，还留了反馈邮箱。
Permissions 与 Rules and Protections 的界面正在重新设计，《Settings》页原话是标签与布局在 early beta 期间可能变化；《Codebase settings》页也写了 Permissions 里的具体控制项可能改。所以本文里这两处我只写分区叫什么、管什么，不写更细的操作序列——写了下个月大概率就对不上。
Rules and Protections 的可用控制项在 beta 期可能扩展，也就是说你现在看到的不是最终形态。
Depot 与 Buildkite 只在 Origin 托管的仓库上工作，不支持从 GitHub 镜像来的仓库，镜像仓库的 CI 继续留在 GitHub。这条是本文里最容易踩的一处：如果你的迁移动机是「把 CI 也搬过来」，那镜像这条路直接就不成立。
镜像不带 Issues 和 GitHub Actions 的 workflow 与 secrets，同上，得自己重建。
admin 可以随时从 dashboard 关掉团队的 Origin，这是文档明写的。
关于 SSH：命令参考页里有 origin ssh-key add / list / delete 这一组命令，用来管理挂在 Origin 账号上的 SSH 公钥；但《Clone, Push & Pull》页描述克隆入口时只写了 HTTPS 和 Origin CLI 两个 tab。这两处放在一起看是有落差的，SSH 形式的克隆地址长什么样、怎么用，官方文档没有说明这一点，我不替它补。
原生 Windows（非 WSL）下 Origin CLI 的安装方式，同样是官方文档没有说明这一点。

五、配完怎么验证

按代价从低到高排，前三条不动任何仓库状态：

origin --version
origin auth status
origin repo list

--version 显示已安装版本（文档把它列在全局选项里）；auth status 显示当前的认证方式与账号——clone 或 push 失败时，《Clone, Push & Pull》页给的第一处排查建议就是确认你已经用 origin auth login 登录过；repo list 列出你账号能访问的仓库，--namespace <namespace> 可以只看一个命名空间。

想确认某个仓库的关键字段，view 支持只输出你点名的字段：

origin repo view acme/checkout --json org,name,defaultBranch

org,name,defaultBranch 是文档里给的示例字段组合。以上命令均为按官方文档中的参数语义组合的示例，未经实测，以官方文档与 --help 的实际输出为准；origin --help、origin repo --help、origin repo create --help 三级 help 都可用。

再往下：origin ruleset list 列出该仓库配置的 rulesets（分合并时与推送时两类），origin ruleset view <id> 看单条，ID 由 list 打印。真正的端到端验证还是那条 git push -u origin main——推成功说明凭据、remote、权限三件事同时对了。镜像仓库则去 Settings → General 看 Sync Status；如果浏览到的内容看着陈旧，文档给的排查顺序是：确认 GitHub app 仍有访问权、确认你在源仓库上是 GitHub admin、重新跑一次 Sync from GitHub 或查看同步状态。

最后一句提醒：本文里的命令、选项与设置分区，都是按官方文档某一天的快照整理的。该产品迭代频繁，尤其 Origin 还挂着 early beta 的牌子，请以官方文档最新内容为准，动手前先用 --help 对一遍实际输出。

本文依据 Cursor 官方文档（cursor.com/docs 与 cursor.com/help）于 2026-08-18 的公开内容整理。该产品闭源，本文只复述官方文档写明的机制，不推断其内部实现； 我们没有对文中涉及的功能做过实测，因此不涉及界面外观、操作手感与运行速度的任何描述。该产品迭代频繁，文中涉及的设置项与命令随版本变动，请以官方文档最新内容为准。本文不涉及订阅价格、额度与模型清单，相关信息请以官方定价与模型说明页为准。

安全与合规相关做法请结合自身环境评估，本文不构成安全方案建议。