Cursor Origin vs GitHub: Mirror Repositories Without Two Sources of Truth

Cursor Origin vs GitHub: mirror repositories without creating two sources of truth

Quick answer

Cursor launched Origin Code Hosting in early beta on August 17, 2026. Origin is a Git forge inside Cursor: it can host repositories, browse and search code, open and merge pull requests, connect agents, and mirror existing GitHub repositories.

For an existing production repository, start with a GitHub mirror, not a storage migration. Cursor's current contract is unusually clear: GitHub remains the source of truth; Origin receives the history, branches, tags, code, and two-way pull-request activity; pushes to the Origin remote pass through to GitHub. GitHub Issues, Actions configuration, and secrets do not move. Test that contract with a disposable repository before allowing agents or teammates to write. Treat Detach from GitHub as a later migration decision because it converts the Origin copy into an independent Origin-hosted repository.

Who this is for

This guide is for independent developers and small teams evaluating Cursor agents while GitHub already owns their repositories, CI, releases, and access workflows. It is especially useful if you want Origin's browser, PR, and agent surfaces without disrupting a working GitHub deployment pipeline.

Origin is currently staged across Pro, Teams, and Enterprise plans and is not available on the free plan. Early-beta labels, UI names, and controls may change. If your immediate need is reviewing agent work from a phone rather than changing Git storage, the Cursor iPad PR review checklist is the smaller rollout.

Choose one authority model

Lane	Authoritative store	What Origin does	Use it when	Main gate
Stay on GitHub	GitHub	Nothing; use existing Cursor integrations only	You only need review or Bugbot comments	No storage change
Mirror GitHub	GitHub	Mirrors Git data and PRs; Origin pushes pass through to GitHub	You want Origin browsing and agents with reversible adoption	Every write is visible on GitHub
Native Origin repo	Origin	Hosts Git, PRs, permissions, apps, and agent workflows	A new or isolated project can accept beta infrastructure	CI, backup, access, and export are proven
Detach a mirror	Origin after detach	Stops GitHub sync and makes the copy independent	You intentionally migrate authority	A signed cutover and recovery record exists

Do not combine these lanes casually. Configuring a local repository to push independently to both hosts can create two accepted writes with different failure states. Origin's supported mirror is safer because GitHub remains explicit authority until you detach.

A seven-step mirror trial

1. Write the invariant before connecting anything

Use one sentence that every operator can test:

Until an approved detach event, GitHub is authoritative for commits, branches,
pull requests, CI, releases, issues, and recovery; Origin is a synchronized surface.

Name an owner, a test repository, a start and end time, and a stop condition. Do not begin with the repository that deploys billing, authentication, or production infrastructure.

2. Inventory what does and does not cross the mirror

Cursor documents Git history, branches, tags, browsable code, and pull requests as included. GitHub Issues, Actions workflows as an execution surface, and secrets are not copied into equivalent Origin services. The workflow files remain in Git history, but the GitHub Actions configuration and secrets stay on GitHub.

Record which system owns checks, required statuses, releases, webhooks, deploy keys, package publishing, issue automation, and incident recovery. If a required dependency has no tested Origin path, keep that responsibility on GitHub instead of pretending the mirror migrated it.

3. Capture a GitHub baseline

Before sync, save non-secret evidence for the default branch SHA, branch and tag counts, open PR count, required checks, and the latest successful deployment. A minimal local baseline is:

git remote -v
git rev-parse HEAD
git branch --all
git tag --list

The Cursor GitHub app must be connected, and the person enabling the mirror needs GitHub admin access to the source repository. Connect only the disposable repository first; avoid granting an entire organization when a narrower selection is available.

4. Check namespace, privacy, and access before code

Origin follows the Privacy Mode of the namespace owner. A team must claim a codebase name, and admins can later manage repositories and access. For each test user, write the expected result before testing: admin, writer, reader, and no access.

Verify both an Internal repository, which is visible to eligible members of the Cursor team, and a Private repository, which requires direct or inherited permission. Also test removal: revoke the user's GitHub or Cursor access and measure how quickly both surfaces stop working. Agent access is still access; review the same tool and content boundaries used for Cursor Google Workspace plugins.

5. Run read and write canaries

Use a branch containing a harmless sentinel file. Require all of these observations:

• Origin shows the same default branch, commit SHA, tags, and history as GitHub;
• a branch pushed to the Origin remote appears on GitHub with the same SHA;
• a PR opened in Origin appears on GitHub;
• one comment and one reply round-trip in both directions;
• a GitHub-assigned review is visible and actionable in Origin;
• merging through Origin updates GitHub and triggers the existing GitHub checks and deployment path;
• an Origin browse or search result never presents a stale commit as current without a visible sync warning.

Capture timestamps and IDs. “It appeared eventually” is not an acceptance criterion for a deployment-critical repository.

6. Exercise the failure boundary

Disconnect the test GitHub app or remove its repository access, then attempt one fetch and one push. The expected result is a visible sync failure with no accepted write existing only on Origin. Reconnect and prove convergence to the same SHA.

Also test a failing GitHub check, a closed PR, a force-push policy rejection, and a user whose access was removed. Origin is early beta; failure evidence is more useful than a clean happy-path demo.

7. End with an explicit decision

Choose one terminal state:

• Keep mirror: GitHub stays authoritative; schedule periodic SHA, PR, and access checks.
• Disable trial: remove the mirror or integration using the documented settings and confirm GitHub is unchanged.
• Plan a native Origin migration: create a separate change plan for CI, backups, permissions, packages, issues, releases, and export. Do not use Detach as an exploratory click.

Cursor documents that detaching stops synchronization and makes the Origin copy standalone while leaving the GitHub repository untouched. That creates two independent repositories immediately. Only detach inside a cutover window with writes frozen and one declared destination.

Decision tree

Do you only need Cursor review or Bugbot on GitHub?
  yes -> stay on GitHub; do not add a mirror
  no  -> continue

Is the repository already production-critical on GitHub?
  yes -> mirror a disposable sibling first; keep GitHub authoritative
  no  -> compare a native Origin repo with a GitHub mirror

Did SHA, PR, access, CI, disconnect, and recovery canaries all pass?
  no  -> stop writes, keep GitHub authority, record the failed boundary
  yes -> keep the mirror and review it periodically

Are you intentionally moving authority to Origin?
  no  -> never detach
  yes -> freeze writes, approve a full migration plan, then detach once

Common mistakes

• Calling Origin a GitHub replacement before testing the beta's missing issue, CI, secret, release, and recovery responsibilities.
• Assuming mirrored GitHub Actions workflows mean Actions configuration or secrets moved to Origin.
• Letting developers configure ad hoc dual-push remotes and accepting partial success.
• Testing only repository visibility, not revocation and agent access.
• Treating a two-way PR UI as proof that every check, webhook, app, and permission is equivalent.
• Clicking Detach to “see what happens” and accidentally creating a second source of truth.

Copyable rollout record

date / owner / Cursor plan / Origin beta state:
test repo / GitHub org / codebase namespace:
authority invariant / write-freeze rule:
baseline SHA / branches / tags / PRs / required checks:
privacy mode / Internal-or-Private / access matrix:
Origin-to-GitHub push SHA / PR and comment round-trip:
CI and deployment result / issue and secret ownership:
disconnect result / stale-read signal / convergence time:
detach rehearsal performed on disposable repo: yes | no
decision: stay GitHub | keep mirror | disable | migration plan
next review / rollback owner:

FAQ

Is Cursor Origin a full GitHub replacement?

Not in the current early-beta contract. It already covers Git storage, browsing, search, pull requests, permissions, apps, and agent workflows, but mirrored GitHub Issues, Actions configuration, and secrets do not become Origin equivalents. Evaluate the responsibilities your repository actually needs.

If I push to a mirrored Origin repository, where does the commit go?

Cursor says pushes to a synced repository pass through to GitHub, which remains the source of truth. Prove that with matching SHAs before using the path for real work.

Can I stop mirroring later?

Yes, but the meaning matters. Detach stops sync and converts the Origin copy into a standalone repository; GitHub is not changed. That is a source-of-truth migration, not a harmless pause.

Sources

• Cursor Origin Code Hosting announcement
• Cursor Origin overview
• Mirror a GitHub repository
• Origin clone, push, and pull
• Origin repository settings

Originally published on IndieSeek.