Cursor Origin 教程：CLI 安装、GitHub 镜像与拉取请求

什么是 Cursor Origin？

Cursor Origin 是一个 Git forge。它托管仓库、镜像 GitHub 项目，并支持拉取请求与代码浏览。Origin 仓库也可与 Cursor 的云端智能体和自动化配合使用。

Cursor Origin 与 GitHub 有何区别？

Origin 并不覆盖 GitHub 的全部功能。目前未见公开仓库的文档，镜像不包含 GitHub Issues、GitHub Actions 工作流和 Actions 机密。GitHub 仍是公共仓库、Issues、Actions 以及第三方应用的更广泛平台，因此当下 Origin 是更窄的服务。

主要区别在于看似熟悉的 Git 工作流之下：Cursor 为智能体带来的分支与提交规模构建了独立的存储层。Cursor 将这一重点称为“智能体规模”（agent scale）：即大量智能体围绕同一仓库进行分支、提交、并创建拉取请求的负载。

为什么 Cursor 要自建 Git 托管？

存储设计解释了为何 Cursor 新建了一个 Git 托管，而非为现有托管再做一层接口。

Cursor 的 关于 Continuity 的工程文章描述了现有 Git 托管通常在多台服务器上保存仓库，并在多数节点达成一致后提交一次推送。Cursor 指出，当系统存在成千上万的短生命周期仓库，或对同一仓库频繁推送时，这种模型成本更高。

Cursor Origin 的 Continuity 存储如何工作？

Continuity（或“Cnt”）是 Origin 背后的存储系统。它在兼容 S3 的对象存储中保存预写日志，作为事实来源。本地磁盘上的 Git 仓库是一个可重建的暖缓存。

Continuity 将 Git 写入以对象形式存储。图片由作者提供。

由于对象日志才是真实记录，Cursor 可以为繁忙仓库增加只读副本，并在需求下降时移除。在 Cursor 的测试中，读取吞吐随着副本数量增加而上升，最高至 100 个副本。系统在标准 S3 上每秒可处理最多 120 次推送，但这些数据尚未经过独立基准验证。

对用户而言，主要影响更直观：繁忙仓库可以提升读取容量，而短生命周期仓库无需在每台服务器上保留永久本地副本。

谁可以访问 Cursor Origin？

Origin 面向 Pro、Teams 与 Enterprise 计划开放，免费计划不包含。访问分阶段逐步开放，因此即便计划符合条件，Codebase 选项卡也可能不会立刻出现。Pro 计划下，您拥有个人命名空间并可认领自己的 codebase 名称。

企业管理员可以为其组织禁用。Cursor 的概览称任何团队成员都能认领首个 codebase 名称，而 Codebase 设置页面则写着需由团队管理员认领。设置前请在团队内确认该权限。

什么是 Cursor Origin CLI？

Origin 提供独立的命令行工具，用于认证、仓库、拉取请求和账户配置。

Cursor Origin CLI 与 Cursor Agent CLI

Origin 的 CLI 是独立的可执行文件 origin，与 Cursor 的 Agent CLI（命令为 agent）不同。

我发现这两个名字很容易混淆，因为 origin 也是 Git 远程的惯用名称。在本文中，“push 到 origin”指 Git 远程，而“运行 origin”指 CLI。

Origin CLI 支持哪些平台？

Cursor 提供了 macOS、Linux 以及通过 WSL 的 Windows 文档。在我测试时，Windows 需要 WSL，因为没有原生安装程序。

如果您在 Windows 上跟做，安装 CLI 前请先打开 Ubuntu 终端。在 PowerShell 中运行安装脚本并不是同一套设置。

Cursor Origin CLI 命令

Cursor Origin CLI 目前有九类命令组。

多数仓库命令会从名为 origin 的 Git 远程读取目标。选项 -R owner/repo 直接设置目标，这在需要对多个仓库运行的脚本中很有用。 ruleset 命令仅显示现有的推送与合并规则；不能修改它们。

如何安装并登录 Cursor Origin CLI

Cursor 通过 shell 脚本分发 CLI，而非包管理器。命令来自 Cursor 的安装页面。

安装 Cursor Origin CLI 的方法

安装基本是一行命令：

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

安装程序将 origin 放在 ~/.local/bin/origin。如果您团队在运行前会审查安装脚本，请先下载脚本，而不是直接管道传给 sh。

修复 Origin CLI “command not found” 错误

如果安装后您的 shell 找不到 origin，请将其目录加入 PATH：

echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.zshrc
source ~/.zshrc

使用 bash 时，将 ~/.zshrc 替换为 ~/.bashrc。每台机器只需设置一次。

检查安装与登录

运行 origin --version 和 origin --help 确认安装，然后使用 origin auth login 打开 Cursor 的浏览器登录流程。

以下是在 WSL 中的验证输出示例：

Origin CLI 版本与帮助输出。图片由作者提供。

在无头环境中，CLI 会打印一个 URL。登录也会配置 Git 的凭据助手，因此 Origin 远程无需单独的 Git 令牌即可使用。随后运行 origin auth status 检查会话。

在无浏览器环境下使用 Cursor API 密钥

用于 CI 或脚本时，可运行 origin auth login --api-key <key>，或在 origin auth login 前设置 CURSOR_API_KEY。请勿将密钥写入提交的文件。CURSOR_AUTH_TOKEN 不同，它需要的是 bearer token。

如何创建、克隆并推送一个 Cursor Origin 仓库

登录后，您可以通过网页或 CLI 创建仓库。推送使用标准 Git 命令。

使用 origin repo create 创建仓库

在 cursor.com/codebase 中，选择 New，输入名称，并选择 Internal 或 Private 可见性。

在 CLI 中，origin repo create my-project 使用您账户的命名空间。若为团队命名空间，请包含所有者，如 origin repo create acme/my-project。可选的 --default-branch 标志可修改服务器默认分支 main。

命令 origin repo clone acme/my-project 会用 CLI 保存的登录信息，通过 HTTPS 克隆仓库。

将您的首次提交推送到 Origin

首次推送后，仓库会出现在 Codebase 中：

仓库已推送并显示在 Codebase 中。视频由作者提供。

对于全新的空仓库，先克隆、添加文件并推送：

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

如果 Git 在 WSL 的 /mnt 下报告 .git/config.lock 权限错误，请改为在 ~ 下克隆。我的测试中这样即可修复。

推送后，打开 Codebase 检查提交是否出现。 Code 选项卡显示文件树与提交历史。按 T 打开 Go to file，或用搜索框检索代码。

将现有 Git 仓库推送到 Origin

如果您已有带历史的项目，先运行 git remote -v。下方命令仅适用于该仓库尚无名为 origin 的远程时：

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

如果 origin 已指向 GitHub，请使用 cursor 等其他远程名称，而不要替换现有 URL。Origin CLI 命令不会从该名称推断仓库，因此运行时需传入 -R owner/repo。

如何在 Cursor Origin 中镜像 GitHub 仓库

镜像会将现有 GitHub 项目复制到 Origin，并保持两项服务互通。

Cursor Origin 的 GitHub 镜像要求

您需要 Origin 访问权限、将 Cursor GitHub 应用连接到拥有该仓库的组织或账户，以及对该仓库的 GitHub 管理员权限。仅写入权限不足以开启镜像。

开始创建 Cursor Origin 的 GitHub 镜像

在 cursor.com/codebase 中选择 Sync from GitHub，选择组织与仓库并确认。CLI 方案是 origin repo create-mirrored owner/repo，详见 Cursor 的镜像文档。

Cursor Origin 会镜像 GitHub 的哪些内容

Origin 镜像 Git 数据，但并不包含所有 GitHub 功能：

GitHub Actions 继续在 GitHub 上运行。Depot 与 Buildkite 集成适用于 Origin 托管的仓库，不适用于镜像副本。

何时由 GitHub 继续作为事实来源

在仓库处于镜像状态时，通过 Origin 的推送会传递至 GitHub。仓库设置下的 Detach from GitHub 会让 Origin 副本独立出来，而不会更改 GitHub 仓库。

如何创建与评审 Cursor Origin 拉取请求

Origin 的拉取请求采用与其他 Git 托管相同的分支、推送与评审流程。我们的拉取请求工作机制指南对该流程做了说明。

创建分支并推送变更

创建并推送工作分支：

git checkout -b my-change
echo "Example change" >> README.md
git add README.md
git commit -m "Add example change"
git push -u origin my-change

Git 的部分已完成；接下来使用 Origin 命令。

使用 Origin CLI 打开拉取请求

仓库命令会从名为 origin 的 Git 远程推断目标。运行 origin pr create，或传入 -R owner/repo 直接设置仓库。该命令默认创建草稿；若要直接进入评审，请传入 --status open。

评审 Cursor Origin 拉取请求

CLI 提供 origin pr list、 origin pr view、 origin pr diff 和 origin pr checks。在未配置 CI 应用的情况下，origin pr checks 会打印 No checks reported.，并以代码 1 退出（我的测试如此）。

该退出码在使用 set -e 的 shell 脚本中很重要，因为即便拉取请求本身没问题，一个空的 Checks 选项卡也可能导致脚本中断。

包含四个选项卡的拉取请求评审界面。图片由作者提供。

在网页视图中，每个拉取请求都有四个选项卡：Activity、Commits、Checks 与 Files Changed，并提供评审者请求、行内评论以及合并按钮。网页会显示合并冲突，origin pr status --conflict-status 可在终端报告冲突情况。

终端同样支持 origin pr merge。在 Origin 托管的仓库上创建的拉取请求会保留在 Origin，而在镜像仓库上的活动会回传至 GitHub。

Cursor Origin 的团队访问与仓库权限

Origin 的权限存在于 codebase 与仓库两个层级。

Codebase 设置与仓库设置的区别

Codebase 设置为团队级：谁可以开启 Origin、创建仓库、安装应用。仓库设置作用于单个仓库，涵盖 General、Permissions、Rules 与 Protections，以及 Apps，不过 Cursor 的文档提醒 Permissions 与 Rules 页面正在重构。

如果某位队友可以使用 Origin，但无法打开某个仓库，请先检查该仓库的权限，而非团队级设置。

Internal 与 Private 仓库

受限访问的仓库有两种：

• Internal 仓库对具有 codebase 访问权限的团队成员可见。
• Private 仓库仅对直接授予或通过 codebase 权限授予访问的成员可见。将仓库切换为 private 会保留变更者为管理员。

如何检查 Cursor Origin 仓库访问权限

使用 origin repo list 命令可显示当前账户可见的所有仓库。要查看某个仓库的可访问成员，请打开 Settings，再进入 Permissions。

Cursor Origin 的最佳实践

使用 Origin 时需要特别注意三点：

• 在删除或重新配置仓库前，确认完整的 owner/repo 值并检查其远程设置。

• 在确认目标前避免使用 -y。

• Cursor 的权限页面存在不一致，请在自动化修改访问控制前查阅最新文档。

Cursor Origin 与 GitHub：功能对比

Origin 面向 Cursor 的智能体工作流，而 GitHub 覆盖更广泛的仓库生态。

Git 托管、拉取请求与 CI/CD

不逐条复述，下面是功能划分的简短版：

其中智能体一行需要结合上下文理解。

在智能体工作流上，Cursor Origin 与 GitHub 的对比

两个平台都允许智能体针对仓库工作。Origin 将该闭环保留在 Cursor 之内；GitHub 通过其 Agents 面板与 Copilot 工具（包括已全面可用的 CLI）提供支持。

何时使用 Cursor Origin、GitHub，或两者兼用

• 使用 Origin 当仓库为内部或私有，大多数智能体工作已在 Cursor 内进行，且您的部署或 CI 能通过 Vercel、Depot 或 Buildkite 运行。
• 保留 GitHub 作为主托管，当项目是公开的、Issues 与 Actions 是日常流程的一部分，或团队依赖 GitHub 的应用市场。
• 两者兼用 当您想要 Origin 的代码浏览与智能体工作流，但不迁移来源仓库时。镜像可让推送与拉取请求活动依然绑定 GitHub，同时使相同代码在 Origin 可用。

结语

我从全新 WSL 安装出发，用与 GitHub 相同的分支、提交与推送流程，完成了一个 Origin 拉取请求。CLI 并未改变 Git 的工作方式；Origin 的差异体现在托管、权限与镜像上。

上手之后，我会将 Origin 视为 GitHub 的补充而非完全替代。对于现有仓库，镜像是最务实的切入点，因为 GitHub 仍可作为权威来源。公共项目与重度依赖 Actions 的工作流暂时没有太多迁移理由。

想要延伸阅读，我们的Cursor Automations 指南涵盖了针对现有仓库运行的智能体任务。我们的GitHub 是什么以及如何使用指南则更详细地解释了 GitHub 的工作流程。