On August 14, SpaceX closed its acquisition of Anysphere. Sixty billion dollars, all in stock, Cursor turned into a fully controlled subsidiary. On August 17, Cursor launched Origin: repository hosting, pull requests, code browsing, bidirectional sync with GitHub. Three days.
I want to be careful about what that interval means and what it doesn’t. It doesn’t mean SpaceX ordered a code hosting product into existence over a weekend. Origin has been in development since December 2025, when Anysphere bought Graphite — the stacked pull requests company founded by Merrill Lutsky, Greg Foster, and Tomas Reimers — for what Axios reported as “way over” its last valuation of $290 million. Reimers is the one who posted the launch on Hacker News, and identified himself plainly in the thread: “I am one of the developers on Origin, and I was one of the founders of Graphite.” Origin is that acquisition going to production eight months later, on a roadmap that predated the SpaceX deal.
What the three days do mean is that the question I left open in June now has an answer, and it arrived faster than I expected.
When I wrote about the acquisition deal in June, I closed with something deliberately understated: if it would cost you to articulate what it would take to move your team off Cursor, it’s worth knowing that independently of who owns the company. At that point it was a question about an editor. Editors are the easiest things to abandon in a stack. You export your settings, install something else, your team complains for two weeks.
Origin is a different category of commitment. A forge holds your source of truth. And the company you’re asking to hold it changed hands seventy-two hours before asking you to.
What Origin really is
Origin is in early beta on Pro, Teams, and Enterprise plans — the documentation is explicit that “it is not available on free plans” — and reaches everyone except enterprise organizations whose admins have opted out of participation. The changelog headline is five words: “Cursor can now host your code.”
You have repositories, pull requests with the full timeline of commits, checks and diffs, code browsing and search on cursor.com/codebase, clone/push/pull with standard git, an Origin CLI, and per-repository settings. You can mirror a GitHub repository inside Origin, and for repositories that were born on GitHub, GitHub remains the source of truth; access permissions replicate GitHub’s. Comments on synced pull requests propagate in both directions in seconds. And, of course, your agents end up alongside all of that: the promise is that code, PRs, and agents finally share direction.
What you don’t have is almost everything that makes a forge a forge. No native CI. The app extensions are Vercel for preview deployments, plus Depot and Buildkite, and what those two do is run the GitHub Actions workflows you already have. No issue tracker. No self-hosting. No documented export path. The most upvoted objection in the Hacker News thread said it with less diplomacy than I would use: “Origin doesn’t even support actions. They are doing the easiest part of git hosting and no mention of anything that actually makes Github what it is.” Cursor’s own changelog says agent-native features are coming soon, which is both an honest admission of what’s missing and a statement of where they think the differentiator lies.
The decision isn’t whether to use Origin
Here’s the distinction nobody’s making, and it’s the one that determines your risk: mirroring is not the same as originating.
If you mirror a GitHub repository inside Origin, GitHub remains the authority. You have a second copy, your permissions still come from GitHub, and if Origin disappoints you, you stop mirroring. The cost of being wrong is close to zero. That’s something reasonable to try this month.
If you create a repository in Origin — something agents can now do on their own, according to the documentation — you have a repository whose only home is a product in early beta, with no documented export path and no second copy. There’s nothing sinister in that; it’s simply a different bet, and it’s one you can make without wanting to, one repo at a time, without anyone having decided it.
Write the policy before you enable it. Mirror, don’t originate, until the export story exists. That single sentence is most of the governance this needs.
The namespace is a one-way door
This is the finding that surprised me most, and it’s right there in the documentation.
To enable Origin, your team claims a namespace: the {owner} of https://cursor.com/codebase/{owner}/{repo}. The docs say two things about it, separated by a paragraph. First: “You can’t change or update your namespace after it’s claimed.” Second: any team member can claim it.
So the public, permanent, and unchangeable identity of your organization’s code hosting can be set by whoever clicks first. Admins can disable Origin entirely; the documentation offers no rename. For a company whose repository URLs can end up in documentation, in CI configuration, in onboarding guides, and in vendor contracts, that default isn’t trivial. It costs nothing to do it right and can’t be fixed afterward.
If you’re on Teams or Enterprise, claim the namespace yourself, today, as a deliberate administrative act, even if you don’t plan to use Origin this quarter. Holding it is free. Losing it on a Friday afternoon because a developer with good intentions got to it first doesn’t recover.
A related detail: teams with legacy privacy settings need to update that configuration before Origin is available. Understand what that update changes for the rest of your tooling before you do it to unlock a beta feature.
What does “Privacy Mode” mean when the product is storage
The Origin documentation has a section called Privacy, and it’s a single sentence: “Origin follows the Privacy Mode of the namespace owner: the team or the individual who owns the repo.”
That sentence is carrying a lot of weight, and I don’t think it can sustain it.
Cursor’s own data use page defines Privacy Mode in terms of things that don’t persist. Plain text code uploaded to calculate embeddings “ceases to exist after the life of the request.” Cached file contents are “temporary, never permanently stored, and never used as training data when privacy mode is enabled.” Customer data isn’t used for training, and Cursor declares it maintains zero data retention agreements with its model providers.
Each of those guarantees is built on the premise that your code passes through Cursor and doesn’t stay. The whole function of Origin is that your code stays. They’re not contradictory — a hosted repository obviously gets stored, and nobody claims otherwise — but it does mean that “Origin respects your Privacy Mode” doesn’t tell you anything about what you actually need to know. What’s the retention policy for a hosted repository? What happens to it when you cancel? What subprocessors touch it at rest? Is it excluded from the same classifiers and pipelines that Privacy Mode governs for transient code?
I didn’t find those answers in the changelog, the Origin docs, the data use page, or the Hacker News thread. It’s not an accusation; the documentation of an early beta is incomplete by definition. It’s a reason to ask before you migrate, and to get the answer in writing instead of inferring it from a product that was designed for a different data lifecycle.
How I’d think about it
I resisted the risk narrative in June and I’m going to resist it now. Origin’s strategic logic is solid and, frankly, it came late: if agents are going to open pull requests, review them, and push branches, having the code and the agent in the same system eliminates real friction. The bidirectional sync of PRs with GitHub is a genuinely well-chosen on-ramp: it lets you get the benefit without the commitment. That’s mature product thinking, not a land grab.
But a forge is the most expensive thing to change in your stack, and the right time to think about it is before you’re inside, not after. Ownership changed on the 14th. The product shipped on the 17th. Your switching cost stopped being a hypothetical exercise: it’s a number you can calculate, and this is the month to calculate it.
The checklist
Before enabling Origin for a team:
- Claim your namespace as an admin decision. It can’t be renamed and any team member can claim it.
- Write a mirror-only policy and define who’s allowed to create repositories that are born in Origin. Remember that agents can create them too.
- Ask Cursor, in writing, what Privacy Mode covers for a repository hosted there: retention, deletion on cancellation, processors at rest.
- Review what changes when you update the legacy privacy settings for the rest of your Cursor deployment before you do it.
- If you’re Enterprise, decide opt-out deliberately, before the rollout catches you and not after.
- Inventory your CI. Origin has no CI of its own; Depot and Buildkite run your existing GitHub Actions. Every workflow you move is a workflow you’d have to rewrite to go back.
None of these things takes a week. All are cheaper now than in six months.
Are you going to mirror any repos in Origin this month, or would you rather wait for the export path to appear? I’m especially interested in how teams that already have Cursor approved by security are seeing it.