Migrating from GitHub to Cursor Origin

Yes, as a sync rather than a cut-over. Since August 17, 2026, plans with Origin access can open cursor.com/codebase, claim a codebase name and choose Sync from GitHub. The mirror docs list Premium or higher, Teams, Enterprise and legacy paid plans, which leaves out Free and Plus. Origin pulls the repo in and keeps it updated, while pushes keep going to GitHub, the source of truth. Detaching later makes the Origin copy standalone.

A sync has one advantage over a migration: you can run it while the vendor is still building, and stop it when you like. The launch changelog says you can disconnect a synced repo at any time.

The repository is the easy part. The parts of a host move that cost real time depend on your own setup, not on the destination: how many things point at the old host, and who is allowed to change them. Origin's docs don't change that. They tell you which rows of the table below you are responsible for.

Git is designed to be portable. Your commit history, branches and tags are the same bytes on any host, so they move without loss. The friction is in everything a host adds around git: the metadata and automation that aren't part of the repo at all.

The CI row looks softer than it is. Workflow files are text inside the repo, so they travel with everything else, and Cursor's changelog says Depot and Buildkite both run existing GitHub Actions workflows on an Origin-hosted repo. What stays behind is what makes those workflows run: the events the host fires and the secret store the steps read from, and neither of them syncs. That work is rewiring, and the pipeline inventory is the place to start it.

Origin also has a CI service of its own, Origin CI, configured in an origin.ci.ts file. So far only Cursor's release notes describe it.

On Origin, the repository move is a button rather than a set of commands, and it leaves the GitHub repo untouched. The steps below show the generic version for any host. The Origin version is Sync from GitHub, then Detach from GitHub in the repo's Settings once you want Origin to become the source of truth.

1. 1Make a full mirror clone of the old repo: git clone --mirror keeps every branch, tag and ref. On Origin, Sync from GitHub at cursor.com/codebase does this and keeps doing it.
2. 2Add the new host as a remote once you have a repo URL there. Origin's is under the green Code button: https://origin.cursor.com/{owner}/{repo}.git, with credentials from origin auth login.
3. 3Push everything with git push --mirror to the new remote. On a synced Origin repo, pushes pass through to GitHub until you detach.
4. 4Repoint each developer's origin remote, and move CI, secrets and integrations over by hand. On Origin, that means the Apps page in codebase settings.
5. 5Keep the old host read-only for a while as a fallback before you delete anything. Detaching doesn't touch the GitHub repo, so it can stay as the fallback.

Steps four and five carry the risk. Repointing developers is what turns a copy into a migration, so wait until something on the new host can run your checks. Otherwise you get a day where everyone can push and nobody can merge. Making the old host read-only can go wrong in both directions. Too early and you can't fall back to it; too late and pushes keep landing on a repo nobody is watching.

The failure to plan for is split brain. Someone's remote still points at GitHub, they push a week of work there, and two branches called main now hold real commits the other doesn't have. Reconciling that is manual by nature, because both sides are legitimate.

So if a push or a check goes wrong mid-cutover, run git remote -v on the machine that produced it before you look at anything else. The answer is usually there, and the alternative is an hour spent debugging a pipeline that was reading the correct repo all along.

Some things are tied to GitHub in ways a host swap can't carry. Be clear about them before you plan a full cut-over, especially while Origin is an early beta whose access and branch-rule settings are still being redesigned.

• Public or open-source projects, where GitHub is also your distribution and discovery, not just storage.
• Anything wired deeply into the GitHub Actions ecosystem, or into GitHub Marketplace apps you would have to replace.
• Third-party tools that integrate with GitHub but aren't in Origin's app marketplace.

Don't bet your only copy of the company's code on an early beta, and the sync design means you don't have to. Trial Origin on a synced, non-critical repo first, with GitHub still authoritative.

Team size decides which of these binds you. A handful of people on two private repos can move in an afternoon and skip every hybrid phase in this guide, because the list of things pointing at the old host is short enough to hold in your head. A few hundred engineers have deploy keys, bots, status checks and dashboards set up by people who have since left, and that list is the migration. If yours isn't written down, compile it now instead of during a cutover.

Yes, and it is the default. A synced Origin repo keeps GitHub as the source of truth while you browse, search and review from Cursor. The mirror docs describe when that fits: mirror when you want Origin's browse, search and cloud agents on your GitHub history. If all you want is automated review comments on GitHub pull requests, they point you to BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. Press Enter for the full definition. instead, which doesn't move storage.

With an importer, you would run it, see what arrived, then decide what to rebuild by hand. Here the sync is the importer, and what arrives is the git history and the pull requests. Issues and CI configuration are documented as staying behind. So plan on the issue tracker and the pipelines staying where they were made, and decide which of them you can afford to leave there.

A trial also needs a stop condition. Without a date and a written question, a mirror quietly becomes production: the repo is on Origin, people got used to it, and nobody decided anything. Pick the date before you start, and pick the one thing you are measuring. A useful number is how long a change sits between approval and landing, because that is the gap a new host either closes or doesn't.