lolspider / notes
Clipping · 8 分钟

Cursor Origin review: An engineer’s perspective

A detailed review of Cursor Origin, covering Git hosting, GitHub sync, cloud agents, current limitations, and whether it’s worth switching.

appwrite.io Matej Bačo
#clippings#Cursor#coding-agent#agentic#GitHub#git#pull-request#cloud-agent#agent-first#code-review#software-engineering#CI-CD#Appwrite#git-forge

📝 摘要

本文是一位工程师对 Cursor Origin（Cursor 自研的 Git 托管服务）早期 Beta 版本的深度评测。Origin 定位为"面向智能体时代的 Git Forge"，核心卖点是将代码仓库、Cloud Agent 和自动化工作流整合在同一个平台内，而非让 Agent 从外部通过 App 集成调用 Git 平台。文章详细梳理了 Origin 当前支持的功能（HTTPS 仓库操作、PR、GitHub 镜像同步、Cloud Agent、Automations）和明确缺失的部分（公开仓库、原生 CI/CD、Issues、Actions、Secrets 等），并从日常使用体验角度指出了 UI 粗糙、PR 过滤不完善、仓库管理需依赖 CLI 等问题。最终建议：已在 Cursor 中深度开发的小团队可尝试；有成熟 GitHub 自动化的团队应先镜像观望；重度依赖 GitHub 治理生态的团队应等待。

核心概念： Cursor Origin 的真正差异化不在于重建一个 GitHub，而在于让仓库、Agent、自动化和代码审查在同一个平台内原生协作——这是外部集成难以复现的架构优势。

关键技术栈 / 关键要点：

  1. Origin 核心功能 — HTTPS 仓库托管、代码浏览搜索、PR（含 review/comments/merge）、GitHub 双向镜像同步
  2. Cloud Agent 原生集成 — Agent 可直接 clone/branch/commit/push/open PR，Automations 可按计划或源码事件触发 Agent
  3. 当前关键缺失 — 无公开仓库、无原生 CI/CD、无 Issues/Actions/Secrets/Releases/Packages、OAuth2 有限
  4. UX 早期问题 — PR 列表默认只显示自己、缺少标签和过滤、部分仓库管理操作仍需 CLI
  5. 镜像策略 — GitHub 镜像同步代码和 PR，但不同步 Issues/Actions/Secrets，脱离 GitHub 镜像会断裂下游部署链路

关键结论 / 实践建议： 将 Origin 视为有前景的早期 Beta 而非可立即迁移的生产级 Git Forge；评估时保持 GitHub 镜像，避免因脱离镜像而断裂 CI/CD 和部署管线。

Git forges have been a settled question for most engineering teams for over a decade. You pick GitHub, you wire up CI, you write the branch protection rules once, and then you stop thinking about it. So when Cursor shipped Origin, its own code hosting product, the interesting question is not whether it works. It is whether anything about it justifies touching a layer of the stack that has been boring on purpose for years.

Cursor positions Origin as "a git forge for the agentic era": code is now produced faster than the infrastructure around it was designed to handle, so the forge should be where agents live rather than a system they call into from outside.

This review combines Cursor's documented Origin features with my experience using the early beta. I wanted to understand not just what Origin claims to support, but what it actually feels like to use as an engineer, where the workflow works well, and where the product still feels early.

What is Cursor Origin?

Cursor Origin is Cursor's own Git hosting service. It stores repositories, serves code browsing and search at cursor.com/codebase, supports pull requests, and can mirror repositories from GitHub. Cursor lists it as early beta on Pro, Teams, and Enterprise plans, with enterprise admins able to opt out.

The mental model is straightforward. You claim a codebase namespace, which becomes part of every repository URL (cursor.com/codebase/acme-corp). You install the Origin CLI, run origin auth login, and then standard Git operations work over HTTPS against https://origin.cursor.com/{owner}/{repo}.git. Cursor's docs note the CLI is needed for authentication, not for every subsequent Git command.

What Cursor Origin ships in early beta

Here is what Cursor documents as available today, and what it explicitly does not carry over.

Capability Status in early beta
Repositories, clone, push, pull Supported over HTTPS after CLI auth
Code browsing and search Supported at cursor.com/codebase
Pull requests Timeline, commits, checks, file diffs, line comments, reviewers, merge
GitHub mirroring Git history, branches, and tags sync; PRs sync both ways
Third-party apps Vercel preview deployments, Depot and Buildkite for CI
Cloud agents Can clone, branch, commit, push, and open PRs on Origin repos
Automations Trigger cloud agents on schedules or source-control events
GitHub Issues, Actions, secrets Not synced

That last row matters more than it looks. Cursor is explicit that mirroring covers code and pull requests, not the surrounding project management and automation layer.

What Cursor Origin feels like to use

Origin is still very clearly an early beta. The core repository and pull request workflows work, but after using it for a while, there are a number of smaller rough edges that make it feel less mature than the Git tooling developers are used to.

I ran into issues while switching between accounts, including rate limits, and some repository creation flows left old modals open on previous pages. None of these were serious enough to make the product unusable, but they are the kind of details you notice quickly when using Origin day to day.

The bigger limitation for me is how much repository management still happens outside the UI. For basic tasks such as creating a README, creating or deleting a branch, or editing files, I often need to use an agent, the Origin CLI, or Git directly rather than managing everything from the web interface.

The pull request experience also feels unfinished in places. Things developers are used to seeing at a glance, such as the number of open pull requests or labels directly in the PR list, are missing. Origin also defaults the pull request view to my own PRs, which means agent-created PRs or PRs opened by teammates are not immediately visible without changing the filter.

Individually, these are small issues. Together, they make Origin feel more like a functional early forge than a finished replacement for the Git platforms engineering teams already use.

Where Cursor Origin still feels early

Some of Origin's limitations are expected for an early beta, but they matter if you are evaluating it as your primary Git forge.

  • No public repositories. Origin repositories are currently private, which means open source projects cannot make Origin their public home.
  • No built-in CI/CD platform. Origin supports app integrations such as Depot and Buildkite, but there is no native equivalent to a full CI/CD system like GitHub Actions.
  • The platform surface is still small. Features developers may expect from a mature Git platform, including Discussions, Insights, Projects, Releases, Issues, and Packages, are not part of Origin today.
  • Repository management is limited in the UI. Some basic operations still require Git, the CLI, or an agent rather than being available directly through the interface.
  • The integration surface has gaps. OAuth2 support is limited, and some installation APIs are missing write operations. Git can work around several of these limitations, but actions such as repository deletion expose gaps that cannot always be avoided that way.
  • The UX still needs polish. Pull request discovery, filtering, labels, and other small workflow details do not yet have the depth developers are accustomed to from mature Git platforms.

None of these make Origin unusable. They do make it clear that the product is still at the beginning of its lifecycle.

What Cursor Origin gets right: agents and repositories in one place

The strongest argument for Origin is not the code browser. It is that Cursor's cloud agents can operate on Origin repositories natively, cloning, branching, committing, pushing, and opening pull requests, and that automations can trigger those agents on schedules or source-control events like a push or PR.

That is a meaningful architectural difference from connecting an agent to an external forge through an app integration. When the agent, repository, and review surface live within the same platform, there is less integration plumbing between those parts of the workflow. If you already run parallel agents in Cursor, that tighter integration could become one of Origin's strongest advantages.

Origin already supports agentic workflows through Cloud Agents and Automations. Cursor says additional agent-native features are still coming.

That is also where I think Origin has the most room to become interesting. As a Git forge by itself, much of what Origin does already exists elsewhere. The opportunity is in what happens when the repository, agents, automations, and review workflow are designed as one system rather than connected through integrations.

Build fast, scale faster

Backend infrastructure and web hosting built for developers who ship.

  • Start for free
  • Open source
  • Support for over 13 SDKs
  • Managed cloud solution

Start project

Should you switch to Cursor Origin? An engineer's verdict

Here is the nuanced read, split by who is asking.

Try it now if you are an individual developer or a small team already doing most development inside Cursor, without years of accumulated GitHub automation. The cost of experimenting is relatively low, the mirror lets you evaluate Origin without immediately moving your source of truth, and you are the audience the beta is shaped around.

Mirror, but do not move, if you have a working GitHub setup with real automation. Point Origin at one active repository, use it for browsing and review, and let pushes keep flowing to GitHub. You get a genuine read on the product without betting your release process on a beta.

Wait if your workflow depends heavily on GitHub-specific governance, CODEOWNERS, merge queues, GitHub Issues, or a large ecosystem of internal and third-party integrations. Origin is still in early beta, and teams with years of policy and automation around GitHub should verify that their requirements are covered before moving their primary repositories.

My impression after using Origin is that the Git hosting itself is not revolutionary yet. Most of the core concepts are familiar, and several parts of the experience are still less complete than what developers expect from mature Git platforms.

That does not make Origin uninteresting. The bet is clearly bigger than rebuilding GitHub inside Cursor. If Cursor can make repositories, agents, automations, and code review work together in ways that are difficult to reproduce with separate tools, Origin could become meaningfully different.

For now, I would treat it as an interesting early beta rather than a Git forge I would immediately move an established engineering workflow onto.

Where your backend fits when your git forge changes

Anything downstream of your repository is coupled to whichever forge is authoritative, so check this before you experiment.

Appwrite Sites supports deploy from Git against a GitHub repository, creating a deployment on every push to your production branch and preview deployments on other branches. While an Origin repository is mirrored, pushes pass through to GitHub, so those deployments keep working unchanged. Detaching from GitHub is what breaks that connection, which is a concrete reason to keep the mirror in place while you evaluate.

The forge-agnostic path is the Appwrite CLI, which deploys Sites and Functions from any CI system. Depot and Buildkite both run existing GitHub Actions workflows, so an Appwrite CLI deploy step keeps working regardless of where the repository lives.

Building with Cursor and Appwrite

Whether or not you move code hosting, the agent side of Cursor is where the day-to-day gain is, and that gain depends on the agent knowing your backend. The Appwrite Cursor plugin bundles Appwrite Skills and MCP servers so agents generate correct SDK calls instead of inventing methods, which matters a great deal more when an agent is opening pull requests on its own.

Set it up with the Cursor integration guide, then let your agents build against real Auth, Databases, and Functions. Create a free Appwrite project and point Cursor at it.

Resources

返回 Clippings