Migrating from GitHub to Cursor Origin

Yes, in the shape Cursor built for the early beta, which is a sync rather than a cut-over. Since August 17, 2026, paid plans (Pro, Teams, Enterprise) can open cursor.com/codebase, claim a codebase name, and choose Sync from GitHub. Origin pulls the repo in and keeps it updated, pull requests sync both ways, and pushes keep going to GitHub, which the docs call the source of truth for anything started there. Detaching later makes the Origin copy standalone. The rest of this page is about what that sync does not carry, because the repository is still the easy part.

A sync has one advantage over a migration, which is that you can run it while the vendor is still building, and undo it from a settings page.

The parts of a host move that cost real time are set by your own setup rather than by the destination, mostly how many things point at the old host and who is allowed to change them. None of that shifts because Origin now has docs; the docs just tell you which rows below you are on the hook 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 isn'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 Depot and Buildkite both advertise running your existing GitHub Actions workflows on an Origin-hosted repo. What stays behind is the vocabulary that makes them run: the events the host fires and the secret store the steps read from, neither of which syncs. Re-wire is the honest word for that work, and the pipeline inventory is the place to start it.

On Origin the repository move is a button rather than a command set, and it is reversible. The generic version below is what it looks like on any host; the Origin-specific version is Sync from GitHub, then Detach from GitHub under the repo's Settings when you are ready for 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 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 is the Apps tab and codebase settings.
5. 5Keep the old host read-only for a while as a fallback before you delete anything. Detaching does not touch the GitHub repo, so it can stay as the fallback.

Steps four and five carry all the risk. Repointing developers is what turns a copy into a migration, so it should wait until something on the new host can run your checks, or you get a day where everyone can push and nobody can merge. Making the old host read-only is the mistake available in both directions. Too early and you cannot back out onto it; too late and pushes keep landing on a repo nobody is watching any more.

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 does not 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 of 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 honest about these before you plan a full cut-over, especially while Origin is an early beta whose docs say the permissions and protection controls 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 marketplace apps you can't easily replace.
• Third-party tools that integrate with GitHub and not yet with Origin.

An early beta is not where you bet your only copy of the company's code, and the sync design means you do not have to. Treat Origin as something to trial on a synced, non-critical repo first, with GitHub still authoritative.

Team size decides which of these actually 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 wired up by people who have since left, and that list is the migration. Almost nobody has it written down, which is the argument for compiling it now instead of during a cutover.

Yes, and it is the default. A synced Origin repo keeps GitHub as the source of record while you browse, search, review and merge on Origin, and the mirror docs say that is the intended shape: mirror when you want Origin's storage, browse and pull requests, and use Cursor Review or BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. Press Enter for the full definition. alone if all you want is automated review comments on GitHub. You get to test review and merge on Origin without moving issues, CI or your team's day-to-day off GitHub.

I would normally tell a team to sequence a host move around the importer: 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 config are documented as staying behind. So the plan has to start from the assumption that the issue tracker and the pipelines stay where they were made, which turns the question into which of those you can afford to leave behind.

A trial also needs a stop condition, and that is the part I see skipped most often. With no date and no written question, a mirror quietly becomes production. The repo is on Origin, people got used to it, and nobody ever decided anything. Pick the date before you start, and pick the single thing you are measuring. For most teams the useful number is how long a change sits between approval and landing, because that is the gap a new host either closes or does not.