Cursor can now host your code. Today we’re launching Origin in early beta.
Origin is a git forge built for agent scale. Create a repo, push with git, and your code lives next to the agents and pull requests that work on it. We’re starting with the essentials: repos, browsing, PRs, and GitHub sync, with more agent-native features coming soon.
What’s new:
Repos Cursor hosts: Open the Codebase tab, click New, and push with the Origin CLI or standard git. Clone, browse, and search your team’s Origin repos in the browser.
Bring your GitHub repos: Connect GitHub, pick what to sync, and those repos sit alongside the ones Cursor hosts. Synced copies update in real time. Pushes still go to GitHub, which stays the source of truth for anything started there.
Pull requests in the same place: Every repo has PRs (timeline, commits, checks, files changed, comments, and merge). On synced repos, review is two-way: comment in Cursor and it posts to GitHub; replies on GitHub show up in Cursor within seconds.
Agents on the repo: Ask Cursor about the code you’re browsing. It can answer, make changes, update PRs, or push a branch. Cloud agents can clone, branch, commit, and open PRs against Origin remotes.
Apps on the repo: Connect Vercel, Depot, or Buildkite from a repo’s Apps tab. Vercel gives every PR a preview deployment. Depot and Buildkite run your existing GitHub Actions workflows, and Buildkite also runs its native pipelines.
Before your team can use Origin, someone has to claim a codebase name at cursor.com/codebase. Admins can disable Origin from the dashboard at any time.
Origin is in early beta and rolling out today to Pro, Teams, and Enterprise on paid plans. It is not available on free plans, and access opens in stages, so you may not see it immediately. Enterprise admins can opt out. Claim a codebase name and create your first repo.
We’d love to hear what you host first. If you hit an issue, please email [email protected] or post in Bug Reports, so we can track and address it properly.
Congrats on the launch. Real question, not a pitch: “cloud agents can clone, branch, commit, and open PRs against Origin remotes” plus “more agent-native features coming soon” — as PR volume scales toward agent pace, is there (or is there planned to be) any hook point for an independent check before a PR actually merges, separate from CI/checks passing? I mean specifically a judgment call on the change itself (is this particular diff sound, not just “did the build pass”) rather than a deterministic policy gate.
Asking because that’s the exact gap between “authorized to merge” and “this specific merge is actually a good idea” that gets harder to catch by eye once agents are opening/merging PRs at a pace no human reviews each one. Not asking you to build anything specific — just curious whether that’s on the “agent-native features coming soon” roadmap or intentionally out of scope for Origin’s own surface (e.g. left to whatever CI/Buildkite/Depot integration a team wires up).
@Colin, somehow the Agent Panel in Origin can’t be used and instead showing this. My repo should’ve been already integrated with GitHub in the Integrations page, and also already able to be used in Cloud Agent.
Can we rethink the need for origin cli as the wrapper for authentication? SSH key pairs work fine and don’t require moving a 100mb bun binary that breaks on non-standard systems.
Bugbot’s the right category, thanks – semantic judgment call on the diff rather than a fixed rule, which is exactly the shape I was asking about.
One narrow thing I’d genuinely want to know: does a Bugbot finding leave anything checkable after the fact, independent of Cursor’s own UI/history? Concretely – if someone needed to confirm months later “Bugbot really reviewed commit X and said Y,” is that verifiable from something portable (a signature, a hash, an exportable record), or does it live only as a PR comment inside Cursor/GitHub state that could in principle be edited or just isn’t there anymore if the PR gets deleted?
Asking because that’s the specific gap invinoveritas (a review layer I run) tries to close – not the judgment call itself, which Bugbot clearly already does well, but making the resulting verdict a signed, portable artifact a third party can check without trusting the platform that issued it.
This looks like a good way to avoid GitHub downtime. One thing that isn’t clear is how I start a new agent using Origin as the … origin? Once I sync a repo from GitHub is that automatic? Or will future GitHub downtime still affect my ability to use Cloud agents?
Edit: Ok I see a bar at the bottom of each repo to start an agent from that repo, I just couldn’t find my Codebase repos in the regular New agent repo list.
Curious if I’m running into an issue, or if it’s something our team admin needs to do on his end.
He synced some of our org’s repos to Origin, but when I log in as a team member, it’s wanting me to choose repos to sync, and when I go into our org, it’s saying all repos need an admin to sync, including the repos that my team admin has already synced?
@Colin So I essentially cannot get into Origin at all due to this, and man I’ve been so excited ever since it was announced.
For anyone else running into this: when a repo is synced from GitHub, it inherits its visibility from GitHub — so a private GitHub repo comes into Cursor as a Private repo, visible only to the person who synced it (plus anyone granted access). Other team members will just see an empty codebase asking them to pick repos to sync.
To share a synced repo with your whole team, whoever synced it (or a repo admin) can open the repo at cursor.com/codebase → Settings → Permissions and change Visibility to Internal, or grant specific people access from that same tab. More on this in the repository settings docs.
Been running Origin on Windows this week and wanted to put four setup snags in one place, since none of them point at the actual cause.
1. Having WSL installed isn’t the same as having a usable distro. Docker Desktop’s WSL entries show up in wsl -l -v and look like you’re set. A docker-desktop entry isn’t something you can work in.
2. Repos under /mnt/c don’t store Linux ownership or mode bits by default, so git throws chmod ... Operation not permitted errors on writes that aren’t real permission changes. Fix is adding [automount] / options = "metadata" to /etc/wsl.conf, then wsl --shutdown.
3. Fresh WSL means no git identity, so the first commit fails with “Author identity unknown.”
4. The CLI installs to ~/.local/bin, which isn’t on PATH in a fresh Ubuntu. The installer prints an export line, but it doesn’t survive closing the terminal.
None of these are Origin bugs exactly. They’re the seams between Origin requiring WSL and WSL’s own defaults. But since the CLI docs send Windows users straight to WSL, a short note on the install page would save people a few hours.
@thisisjaymehta Repos that use submodules do work with Origin: you can push them, sync them from GitHub, and submodule pointer updates show up in diffs and pull requests.
A few surfaces are still catching up though. The web code browser doesn’t yet let you click into a submodule, pull request review shows submodule updates as a simple placeholder rather than a detailed view, and cloud agents don’t automatically pull submodule contents when they clone a repo.
If you ran into something specific, let me know what you hit and I’ll dig in.
