Does Cursor Origin Have CI/CD? What We Know About Checks

Nothing is published. The page at cursor.com/origin is a waitlist, a tagline calling Origin a git forge for the agent era, and one line of positioning about code moving faster than infrastructure. There is no feature list, no docs, and nothing that says how checks, pipelines or runners will work. Every specific claim about CI on Origin comes from coverage of the June 16, 2026 Compile demo, not from Cursor.

That absence deserves a page of its own because CI is where a forge migration actually costs. A repository transfers in minutes; the pipeline around it is what you rebuild. So the useful move today is to be precise about what has been shown, what has only been reported, and what nobody has said at all.

Coverage of the demo describes three CI-adjacent pieces. Merge queues that land changes through a controlled pipeline, keeping CI green when several agents target the same repository at once. Automated handling of failed CI runs, where Origin reportedly fixes the failure rather than just reporting it. And stacked pull requests with a visible dependency graph, inherited from the Graphite team that builds Origin.

The merge-queue pitch is the one aimed most directly at agent workloads. Two changes that each pass CI alone can fail when combined, and with parallel agents that combination happens constantly. A queue validates each change against the latest target branch plus everything already queued ahead of it, which is exactly the failure mode agents multiply.

Because almost none of it lives in git. Your workflow files travel with the repository, but everything that executes them belongs to the host: the event system that triggers runs, the runners that execute them, the secrets they read and the protection rules that make their results binding. Move the repo and the YAML arrives dead on the other side.

One baseline is worth holding onto: merge queues are not exotic. GitHub's own docs describe a merge queue that automates merges into a busy branch and checks each pull request against the latest target plus the queue ahead of it. Origin pitching a queue is table stakes; the open question is the checks system underneath it, and that is the part with no published answer.

You can do the expensive thinking before Origin ships anything. An afternoon of inventory tells you what a move to any forge would cost, and it doubles as documentation your team probably owes itself anyway.

1. 1List every workflow, what triggers it, and which repos share it. Reusable workflows and org-level templates are easy to forget.
2. 2Flag every marketplace action you depend on. Each one resolves from GitHub's ecosystem and needs a replacement or a vendored copy elsewhere.
3. 3Count self-hosted runners and what they can reach: build caches, internal networks, signing keys. Re-provisioning these is infrastructure work, not config.
4. 4Export branch protection rules and required status checks per repo. These are host settings and vanish on transfer.
5. 5Map secrets and deploy credentials to the workflows that consume them, so re-entry is a checklist rather than an archaeology project.

Sort yourself by how deep your Actions usage runs. If your CI is a lint job and a test suite, the execution layer is thin and a forge trial costs little; you could evaluate Origin's review and merge on a mirrored repo the week it opens. If you run self-hosted runners, marketplace actions and deploy pipelines with compliance gates, the CI documentation is your gating item, not the git hosting.

Most forges let external CI report status back through an API, which is how GitLab repos run on Jenkins and how half the industry ran before Actions existed. Whether Origin exposes a checks API for that pattern is unpublished. If it does, teams keep their existing CI and adopt Origin for review; if it does not, the migration is all-or-nothing. That single detail changes the decision more than any demo claim, which is a good reason to withhold judgment until Cursor documents it.