Cursor Origin Access: The Waitlist Is Over, Here's How to Get In

Through the plan you already pay for. The waitlist form at cursor.com/origin was replaced on August 17, 2026 by the line "Early beta now available on all paid plans," and Cursor's docs describe a short setup rather than a queue. There is no questionnaire and no invite code to hunt for, but there is one irreversible choice in the flow, so read the steps before you click through them.

1. 1Open cursor.com/codebase signed in to a Pro, Teams or Enterprise account and select Get Started. Free plans do not qualify.
2. 2Claim a codebase name. It becomes the namespace every repo lives under (cursor.com/codebase/{owner}/{repo}) and during the beta it cannot be changed once claimed. On a team, any member can claim it; admins then grant repo access from codebase settings.
3. 3Create a repo with New, or bring one over with Sync from GitHub. The docs' clone URL is https://origin.cursor.com/{owner}/{repo}.git, and the Origin CLI (origin auth login) sets up the git credential helper so push and pull work.

Read the second step literally, because it is the only part Cursor says you cannot undo. Everything else in the beta is reversible from a settings page: a synced repo can be detached, a repo can be deleted, Origin itself can be disabled for the team from the dashboard. The namespace is the exception, and it is the first thing you are asked for.

Who claims it is worth a minute's thought on a team, and nothing published settles it. Any member can, and the name is the one that will sit in every URL the company's code lives at. I'd have the person who owns the GitHub org do it, for a reason that has more to do with org charts than with Cursor. The name that matches your existing org is the one nobody has to ask about later, and the person with the authority to pick it is the person who will otherwise be asked to rename it.

More than the phrase "early beta" usually implies, and less than the June demo promised. Here is the honest ledger, from the docs.

Of those rows, the missing agent-native layer is the one that changes plans. The usual beta playbook has the headline feature somewhere in it: you get in early, you form a view on the thing that made you sign up, and you turn up at general availability already decided. Here the headline feature is the part that has not shipped, so an internal commitment along the lines of "we will have evaluated Origin's review model by Q4" rests on docs that describe ordinary pull requests.

The asymmetry still favors getting in. It costs a few minutes, a synced repo leaves GitHub authoritative, and it means forming a view on the hosting basics from real use rather than from a write-up two days after the next changelog entry.

Three documented reasons, and none of them is a bug. The docs say access opens in stages, "so you may not see Origin immediately after it becomes available for your plan." The changelog adds that enterprise orgs whose admins opt out are excluded. And teams on legacy privacy mode cannot enable Origin at all until they switch to Privacy ModeCursor's setting that guarantees code data is not used for training by Cursor or its model providers, and that an admin can enforce org-wide; data-retention terms are a separate, contractual layer. Press Enter for the full definition., because Origin follows the Privacy Mode of the namespace owner.

How much good asking does depends on what kind of customer you already are. A five-person team on individual plans has nobody to ask and the staged rollout to wait on. An org with an enterprise contract and a named account manager can find out in one message whether an admin opted out, and that is a question worth asking before anyone files a support ticket about a missing tab. Neither path moves you up a queue, because there is no queue; both just tell you which of the three reasons applies.

Meanwhile, demand for Origin was commercially valuable enough during the waitlist months that other companies intercepted it, and those pages are still live, which makes it worth knowing exactly which page is real.

Cursor's own line on third-party sellers is the closest published rule to borrow here: the pricing page states that subscriptions are sold only through cursor.com and that no resellers or third-party sellers are authorized. Origin has no separate price, so no page can legitimately charge you for access to it. A request for payment is enough to close the tab, and a request to log in to your git host is the worse of the two, since a payment can be disputed later and a granted token cannot un-read whatever it already read.

The waitlist ran from the June 16, 2026 Compile announcement until the early beta shipped on August 17, and Cursor never published invite waves or a rollout order for it; the beta simply opened to paid plans. Third-party coverage of the announcement had reported that Origin would be "available this fall," and no fall date, or any date, ever appeared on cursor.com itself. The beta landed a month before the reported season, which is the usual lesson about reported dates run in the unusual direction. The status tracker carries the full timeline and the signals for general availability, which is the next date nobody has published.

If you signed up to the waitlist, nothing published says that address is used for anything now. Access is a property of your plan, not your signup, so the email you registered with is irrelevant unless it happens to be the one your paid Cursor account sits on.

The first week is usable time, and the teams that get a real evaluation out of it will be the ones that treat it as a migration-readiness exercise rather than a tour. Migrating from GitHub to Origin covers the full playbook; here is the short version to run now.

1. 1Inventory what is tied to your current host: issues, CI pipelines, webhooks, secrets, permissions. The docs say the sync carries history and pull requests and nothing else on that list; the list is the actual migration.
2. 2Sync one trial repo from GitHub rather than pushing a fresh one. You get Origin's browse, search and pull requests on real history while GitHub stays the source of truth, and Detach from GitHub is there if you decide to go further.
3. 3Pick that repo carefully: active enough to generate real review traffic, non-critical enough that an early beta can hold it.
4. 4Get used to small, stacked changes. Graphite's gt CLI works against GitHub today, and stacked diffs are the review model Origin's team built, even though the beta's pull requests do not ship native stacks yet.
5. 5Keep automated review where it is. BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. Press Enter for the full definition. runs on GitHub and GitLab now, and the mirror docs say to use Bugbot or Cursor Review alone if review comments are all you want.

Run those in order, because the first one sizes everything after it. The inventory tells you whether this is a morning's work or a project: eight pipelines and a couple of webhooks is a different situation from sixty of each, and the trial-repo choice depends on knowing which one you are in. The sync comes second for a duller reason. It takes minutes, and you would rather find out how the pull-request sync behaves on a repo nobody is waiting on than during the week you are trying to evaluate a host.

Most of the risk sits in step three. A repo that matters too much never gets used, because nobody puts the quarter's release on an early beta, and a quiet one produces too little review to say anything about the part Origin is meant to change. Both mistakes leave you at the end of the week with nothing to decide on. Pick the repo before you claim the namespace, while nothing is riding on the choice.

Steps four and five are the odd pair, because they are the only two that would have paid off before access arrived and still pay off now. Stacked changes through Graphite's gt CLI and BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. Press Enter for the full definition. on pull requests both run against GitHub today. A team that adopts them is reviewing differently next week rather than next quarter, so if you only have appetite for two of the five, take those two and let the inventory wait until there is a reason to run it.

Team size changes which of the five pay off. On a two-person team the pipeline audit is the part to drop, since the setup is one repo and a CI file. The sync earns its minutes at any size, because what a small team still gets wrong is assuming a mirror behaves like the original without ever watching it.

Do those five and the week of access becomes something you can decide on.