Cursor Origin Is Live: What the New Git Hosting Platform Actually Does—and Whether It Can Replace GitHub

Introduction

August 17 was an unusually dramatic day for developer infrastructure.

GitHub suffered a major global incident that lasted 7 hours and 47 minutes from the first recorded impact to final resolution. During the incident, developers saw problems across core GitHub.com services, APIs, pull requests, repository content, authentication-related systems, and GitHub Copilot.

At nearly the same time, Cursor began rolling out Origin, its own Git hosting platform.

The timing was almost too perfect for social media.

One side of the developer world was refreshing the GitHub status page. The other was sharing screenshots of Cursor’s new Codebase tab and joking that it was time to move repositories.

The source article describes the moment as Cursor “taking down GitHub overnight.” That makes for an effective headline, but it should not be read literally.

Origin did not cause the outage, and an early-beta hosting product did not erase GitHub’s enormous ecosystem in one day.

What actually happened is more interesting: Cursor moved from being primarily an AI coding environment into the source-control infrastructure layer.

Origin can now host repositories itself. That means the company is no longer satisfied with agents writing code while GitHub remains the default place where that code ultimately lives.

Cursor now wants the repository, the pull request, the agent, and the development workflow to exist in one system.

Cursor’s acquisition by SpaceX had already completed on August
14. Three days later, Origin moved into early beta for paid users.

Cursor’s Version of GitHub Is Now Live

Origin is not merely a cached copy of a GitHub repository inside Cursor.

Cursor describes it as:

a git forge for storing and sharing code

In the current Early Beta, Origin can:

• Create and host repositories.
• Clone repositories with standard Git.
• Push and pull with standard Git.
• Mirror repositories from GitHub.
• Browse and search code in the browser.
• Inspect commit history.
• Open pull requests.
• Review pull requests.
• Comment on pull requests and individual lines.
• Merge pull requests.
• Manage repository access.
• Connect third-party applications.
• Attach Cursor Cloud Agents and Automations.
• Use an Origin-specific CLI.

That is enough to make Origin a real Git hosting product rather than a visualization layer.

The product is still explicitly labeled Early Beta. Cursor’s launch post says it is beginning with the essentials and plans to ship more agent-native features later.

That boundary is important when comparing the beta with the more ambitious Origin vision Cursor demonstrated earlier in the year.

Who Can Use Origin?

Cursor’s current documentation lists Origin code storage for:

Because the rollout is gradual, a paid account may not see Origin immediately. Enterprise organizations can also opt out.

Origin inherits the privacy mode of the namespace owner, meaning teams should review their Cursor privacy and repository-access configuration before placing sensitive code on the service.

Creating a Repository

The basic setup is intentionally familiar.

Step 1: Open Codebase

Go to Cursor’s Codebase workspace:

cursor.com/codebase

Step 2: Create a Repository

Select:

+ New

Choose the repository name.

Cursor then shows the commands needed to install the Origin CLI, clone the repository, or push an existing local project.

Step 3: Choose the Codebase Namespace Carefully

When a user or team creates its first Origin repository, the chosen codebase name becomes part of the repository URL.

The URL follows this general pattern:

https://cursor.com/codebase/{owner}/{repo}

For example:

https://cursor.com/codebase/acme-corp/example-repo

Cursor’s current beta documentation warns that the namespace cannot be renamed during the beta. Choose it deliberately.

Origin Works With Standard Git

One of the most important adoption decisions is that Origin does not require developers to abandon Git itself.

A repository can use familiar operations such as:

git clone
git pull
git push

To open a pull request from a new branch, Cursor’s documentation gives the standard flow:

git checkout -b my-change
git push -u origin my-change

Once the branch is on Origin, the pull request can be created from the web interface.

Cursor Cloud Agents can also create branches, commits, pushes, and pull requests against Origin repositories.

This matters because a Git-compatible forge can be introduced without replacing every local developer tool at once.

Pull Requests Move Into Cursor

Every Origin repository includes pull requests.

The current PR interface exposes four major views:

• Activity.
• Commits.
• Checks.
• Files Changed.

Reviewers can inspect diffs, comment on lines, leave reviews, request reviewers, and merge after review and CI requirements are satisfied.

The larger product idea is that a developer should not need to move between:

Cursor editor
→ Git hosting website
→ AI assistant
→ CI dashboard
→ back to editor

for every change.

Origin brings repository browsing and PR work into the same Cursor environment in which agents already operate.

About the “Stacked PRs, Merge Queue, and AI Auto-Merge” Claims

The source article presents three especially aggressive Origin features:

1. Stacked pull requests.
2. An agent-oriented merge queue.
3. AI-driven automatic merge-conflict resolution.

Those ideas fit Cursor’s broader agent-scale vision.

However, they should be separated from what the current Early Beta documentation actually promises.

What Is Clearly Shipped Today

Cursor currently documents:

Repositories
Standard Git clone/push/pull
GitHub mirroring
Code browsing/search
Pull requests
Reviews/comments
Checks
Manual merge
Conflict surfacing
Permissions
Apps
Automations
Cloud Agents
Origin CLI

What Is Not Yet Clearly Documented as a Current Origin Beta Feature

Current first-party Origin docs do not list the following as generally available:

Native stacked-PR workflow
Origin merge queue
AI automatic merge-conflict resolution
Origin-specific structured review-state API
Origin as an MCP server

Cursor’s launch language explicitly says additional agent-native features are coming later.

So these should be treated as earlier demonstration concepts, roadmap direction, or features awaiting clearer release documentation—not as capabilities every paid Origin user can rely on today.

GitHub Already Has Stacked PRs and Merge Queues

The comparison also needs a correction on the GitHub side.

GitHub is not limited to one giant human-readable PR list.

GitHub currently documents:

• Stacked pull requests.
• REST APIs for creating and managing stacks.
• GraphQL stack queries.
• Merge queues.
• merge_group workflow events.
• Auto-merge.
• Structured pull-request review decisions through GraphQL.

That does not make GitHub “agent-native” in the same product sense Cursor is pursuing.

But it does mean the technical distinction is not:

GitHub has none of these primitives
vs.
Origin has all of them

The more credible distinction is product philosophy.

Cursor wants repository infrastructure to be directly embedded in an environment where fleets of coding agents are already first-class actors.

GitHub Mirroring Makes the First Move Low-Risk

Origin’s most practical migration feature is not a dramatic replacement switch. It is mirroring.

A team can connect GitHub to Cursor, choose an organization and repository, and create an Origin mirror.

The current documented sync includes:

For a mirrored repository, GitHub initially remains the source of truth.

Pushes through the Origin remote continue to flow to GitHub. Pull requests can be reviewed from Origin while activity syncs back to GitHub.

That makes Origin easier to test because teams do not need to surrender repository authority on day one.

Pull Requests Sync Both Ways

Cursor’s launch post says pull requests on mirrored repositories sync bidirectionally.

The intended behavior is:

Comment in Cursor
→ appears on GitHub

Reply or react on GitHub
→ appears in Cursor

Review assigned on GitHub
→ can be handled from Cursor

Cursor says these updates appear within seconds.

That lets developers evaluate the Origin experience while existing GitHub collaborators continue using GitHub.

This is probably a more realistic migration strategy than immediately moving a critical monorepo to a new beta host.

One Button Can Make Origin the Source of Truth

The strongest migration step is Detach from GitHub.

When a mirrored repository is first created, the relationship is:

GitHub
= source of truth

Origin
= synchronized mirror

Cursor’s repository settings include a Danger Zone action:

Detach from GitHub

After detaching:

Origin
= standalone hosted repository
= source of truth

Pushes to the Origin remote no longer flow to GitHub.

The original GitHub repository is not deleted or modified by the detach action.

That distinction is important.

Detaching changes synchronization behavior; it does not erase the GitHub copy.

What “Source of Truth” Means Here

A codebase can have several clones and mirrors, but development processes usually need one authoritative repository.

That authority determines questions such as:

• Which remote receives new commits?
• Which branch is the canonical main?
• Where are pull requests merged?
• Which repository should deployment pull from?
• Which history is considered authoritative after divergence?

For mirrored Origin repositories, that authority begins on GitHub.

After detachment, Cursor documents Origin as the source of truth for the Origin-hosted repository.

This is the point where Origin stops being a companion interface and becomes the primary Git host for that project.

Origin’s App Ecosystem Starts With Vercel, Depot, and Buildkite

Cursor has also begun connecting Origin to the deployment and CI ecosystem.

Current official integrations include:

Vercel

Connect Vercel from the repository’s Apps tab.

Cursor says each pull request can receive a preview deployment, allowing teams to test and comment before merging.

Depot

Depot can run CI for Origin repositories and can reuse existing GitHub Actions workflows.

Buildkite

Buildkite can also run existing GitHub Actions workflows, in addition to its native pipeline system.

This helps reduce one of the hardest migration costs.

Even when repository storage moves, teams do not want to rewrite their entire CI/CD stack at the same time.

GitHub Actions Files Do Not Automatically Become Origin CI

There is an important nuance.

Cursor’s GitHub mirror documentation says GitHub Actions workflows and secrets are not themselves mirrored into Origin as GitHub platform configuration.

However, third-party Origin integrations such as Depot and Buildkite can execute existing GitHub Actions workflow definitions.

Those statements can coexist:

GitHub Actions platform state
→ not migrated by repository mirroring

Workflow files in the repository
→ can be interpreted by supported CI integrations

Teams should test secrets, permissions, event triggers, caching, deployment credentials, and branch protection before detaching a production repository.

Origin Is Designed to Sit Under Cursor Agents

The larger strategic argument for Origin is agent integration.

Cursor’s Cloud Agents run in isolated cloud virtual machines with full development environments.

They can:

• Clone repositories.
• Create branches.
• Modify code.
• Run builds and tests.
• Commit changes.
• Push branches.
• Open pull requests.
• Continue running while the developer’s laptop is offline.

With Origin, those agents can work directly against repositories hosted by the same platform.

The loop becomes:

Goal
→ Cursor agent
→ Origin repository
→ branch
→ code changes
→ tests
→ pull request
→ review
→ merge

The repository no longer has to be an external service at the center of the agent workflow.

Automations Make the Repository Event-Driven

Origin also integrates with Cursor Automations.

Current documentation lists repository events such as:

• Push to branch.
• Pull request opened.
• Pull request pushed.
• Related PR events.

An automation can wake a cloud agent in response to one of those events.

For example:

New PR opened
→ run a security review agent

Push to main
→ summarize the change

PR updated
→ inspect new commits

This is a concrete piece of the “agent-native” story that is already documented today.

Cursor’s August 19 agent update goes further by allowing Cloud Agents to subscribe to events and continue driving work such as CI fixes and bot feedback until the goal is complete.

What About MCP?

The source article says Origin “natively supports MCP” so agents can drive the forge as easily as an API.

Cursor as a broader product absolutely supports MCP for connecting agents to external tools and data.

However, I did not find a current Origin documentation page that exposes Origin itself as an MCP server for repository operations.

The current Origin integration documentation emphasizes:

Origin CLI
Cloud Agents
Automations
Third-party apps

So the safe wording is:

Cursor’s agent ecosystem supports MCP, while Origin’s current Early Beta documentation does not yet clearly advertise a dedicated Origin MCP interface.

That may change as Cursor ships the additional agent-native features it has promised.

Performance Claims Are Aimed at Agent Scale

Cursor’s earlier Origin demonstrations emphasized throughput numbers that sound excessive for a human development team.

Reported demo figures included:

These figures should still be read as vendor demonstration claims.

Cursor’s current Origin documentation does not publish a full benchmark methodology, production SLA, workload distribution, percentile latency table, or independent validation for those figures.

A production team should test its own workloads before treating stage-demo throughput as guaranteed service capacity.

Agents Are Already Creating a Large Share of Cursor’s Own PRs

The argument for agent-scale Git infrastructure is not purely hypothetical.

Cursor said in February that more than 30% of pull requests merged internally were being created by agents operating autonomously in cloud sandboxes.

By June, Cursor’s own engineering post said:

more than 40% of our PRs come from cloud agents

The source article cites an intermediate 35%–40% figure.

The exact percentage has moved over time as agent adoption increased.

The more important trend is clear:

February 2026:
>30%

June 2026:
>40%

Cursor’s internal software-development workflow is already producing enough agent-authored PRs that repository coordination becomes a serious infrastructure concern.

Why Agent-Generated PRs Change the Workflow

Traditional repository workflows assume human pacing.

A developer may:

1. Create one branch.
2. Work for hours.
3. Push several commits.
4. Open a PR.
5. Wait for review.
6. Resolve comments.
7. Merge.

An agent fleet can operate differently.

Ten or one hundred agents may simultaneously:

• Clone the same repository.
• Create branches.
• Modify overlapping files.
• Run CI.
• Push commits.
• Open pull requests.
• Respond to review comments.
• Fix failures.

The bottleneck moves.

Writing the first draft of code may become cheap.

Coordinating, validating, reviewing, and safely merging many simultaneous changes becomes harder.

That is the infrastructure problem Origin is targeting.

GitHub Was Built for Humans—But It Is Also Adapting

The source article contrasts a “2008 GitHub workflow” with an agent-native Origin.

The historical framing is useful, but the current product comparison is more nuanced.

GitHub has continued to add automation primitives including:

• Merge queues.
• Stacked pull requests.
• Copilot coding agents.
• GraphQL and REST APIs.
• Webhooks.
• GitHub Actions.
• Rulesets.
• Automated review and merge features.

So the question is not whether GitHub can automate development.

It clearly can.

The strategic question is whether a platform designed around repositories and human collaboration can adapt as quickly as a platform whose primary product identity is now AI agents doing software work.

Origin is Cursor’s bet that the answer leaves room for a new forge.

The GitHub Outage Made the Launch Look More Dramatic Than It Was

GitHub’s August 17 outage was real and severe.

The official incident ran from:

13:28 UTC
to
21:15 UTC

for a total of:

7 hours 47 minutes

During the event, status updates reported substantial error rates across web/API traffic and repository-content access, while Copilot was also degraded.

The launch coincidence created an irresistible narrative:

GitHub goes down
+
Cursor launches Git hosting
=
Cursor replaces GitHub

That is not what happened operationally.

In fact, Origin’s own GitHub-mirroring path still depends on GitHub when GitHub remains the source of truth.

And Cursor’s broader agents can also depend on external source-control providers.

A GitHub outage is therefore not automatically a demonstration that every Cursor workflow continues unaffected.

The real lesson is about concentration risk: when one source-control platform is deeply embedded in development, a long outage affects far more than repository browsing.

The Microsoft Stock Screenshot Does Not Prove Causality

The source article also places a Microsoft stock screenshot beside the Origin story, showing the shares down roughly 3.2% on the day.

That is an attention-grabbing juxtaposition.

It is not enough to conclude:

Origin launched
→ Microsoft lost more than $100 billion

Large-cap technology stocks move for many reasons.

Without evidence isolating the cause, the stock move should be treated as same-day market context rather than a direct reaction to Origin.

This article therefore does not attribute Microsoft’s market-cap change to the Cursor launch.

Should You Move a Production Repository Today?

For most teams, the answer is:

Not all at once.

Origin is still an Early Beta.

The safer path is to evaluate it gradually.

Step 1: Start With a Non-Critical Repository

Choose:

• An internal tool.
• A prototype.
• A small service.
• A low-risk library.

Do not start with the repository that deploys your entire production platform.

Step 2: Mirror From GitHub First

Keep GitHub as the source of truth.

Evaluate:

• Sync freshness.
• PR behavior.
• Code search.
• Access controls.
• Cursor agent workflows.
• CI integrations.

This gives you a rollback path.

Step 3: Test Pull-Request Synchronization

Create comments and reviews on both sides.

Verify that:

• Cursor → GitHub sync works.
• GitHub → Cursor sync works.
• Review assignments remain correct.
• Checks display correctly.

Step 4: Rebuild CI Deliberately

If you use Vercel, Depot, or Buildkite, connect them and verify:

• Secrets.
• Required checks.
• Preview deployments.
• Branch rules.
• Deployment gates.

Do not assume GitHub Actions platform state automatically migrated.

Step 5: Test Agents Against Origin

Run Cloud Agents on the mirrored repository.

Measure:

• Clone reliability.
• Push reliability.
• PR creation.
• CI repair loops.
• Permission behavior.
• Long-running task completion.

Step 6: Review Privacy and Access

Check:

• Repository visibility.
• Team permissions.
• Cursor Privacy Mode.
• Organization admin controls.
• External app access.

The repository host becomes part of your security boundary.

Step 7: Detach Only After the Workflow Is Proven

Use:

Settings
→ General
→ Danger Zone
→ Detach from GitHub

only when the team has intentionally decided that Origin should become authoritative.

After detachment, pushes to Origin no longer flow back to GitHub.

When Origin Is Worth Testing Now

Origin is especially interesting if your team already uses Cursor heavily.

Good candidates include teams that:

• Run many Cursor Cloud Agents.
• Generate a high volume of agent-authored PRs.
• Want repository browsing and agent work in one interface.
• Want to experiment with event-driven agent workflows.
• Already use Vercel, Depot, or Buildkite.
• Want a low-friction GitHub mirror before considering migration.

The integration advantage is strongest when Cursor already sits at the center of the engineering workflow.

When GitHub Is Still the Safer Default

GitHub remains the more conservative choice for teams that depend on:

• A mature public open-source ecosystem.
• GitHub Issues.
• GitHub Actions infrastructure.
• Marketplace integrations.
• Existing enterprise governance.
• Complex rulesets.
• Established audit processes.
• Broad external contributor familiarity.
• A large number of integrations not yet available on Origin.

Origin’s Early Beta documentation itself acknowledges that some GitHub-specific platform features do not move with repository mirroring.

A code host is not just Git object storage. It is an ecosystem.

Origin Is Not Yet a Full GitHub Replacement

Today, the most accurate description is:

Origin is a real Git host
+
a GitHub mirror
+
a PR/review surface
+
an agent-integrated repository layer

It is not yet:

a drop-in replacement for every GitHub feature

The distinction matters for migration planning.

A team can already host code entirely on Origin.

That does not mean all of its GitHub Issues, Actions configuration, secrets, marketplace apps, policies, public community workflows, and enterprise processes automatically move with it.

The More Important Competition Is Over the System of Record

The source article’s final argument is stronger than its headline.

Cursor is not merely competing with GitHub for repository storage.

It is competing for the place where software work becomes authoritative.

In the older stack:

Developer
→ IDE
→ GitHub
→ CI
→ deploy

In Cursor’s emerging stack:

Human goal
→ Cursor agent
→ Origin
→ PR
→ automated checks
→ deployment integration

If agents become the main producers of changes, the repository platform that coordinates those agents may become just as strategically important as the editor.

That is why Detach from GitHub matters more than the launch-day jokes.

A mirror is convenient.

A new source of truth is a platform shift.

常见问题

What is Cursor Origin?

Origin is Cursor’s Git hosting and code-sharing platform. In Early Beta it can host repositories, use standard Git clone/push/pull, mirror GitHub repositories, browse and search code, open and merge pull requests, and connect Cursor agents and selected third-party apps.

Is Cursor Origin available for free users?

No. Cursor’s current documentation says Origin code storage is available on Pro, Teams, and Enterprise plans and is not available on free plans. Rollout is staged, so some eligible users may receive access later than others.

Can Origin replace GitHub completely?

Origin can become the source of truth for a repository after you detach it from GitHub, but it is not currently a feature-for-feature replacement for the entire GitHub platform. GitHub Issues, GitHub Actions platform configuration, secrets, and many ecosystem integrations do not automatically migrate.

Does Cursor Origin support GitHub synchronization?

Yes. Origin can mirror GitHub repositories, including Git history, branches, tags, browseable code, and bidirectionally synchronized pull requests. While the repository remains mirrored, GitHub stays the source of truth and pushes through Origin flow back to GitHub.

What does “Detach from GitHub” do?

It stops GitHub synchronization and converts the Origin mirror into a standalone Origin-hosted repository. Origin becomes the source of truth, and future pushes to the Origin remote no longer flow to GitHub; the existing GitHub repository is left intact.

Does Origin already support stacked PRs and an AI merge queue?

Cursor’s current Early Beta documentation does not list a native stacked-PR workflow or Origin merge queue as generally available features. The launch says additional agent-native functionality is coming soon, so earlier demo or roadmap claims should not be confused with the currently documented beta.

Does Origin automatically resolve merge conflicts with AI?

Current Origin pull-request documentation says Origin surfaces merge conflicts so users can resolve them before merging. Earlier public coverage of Cursor’s Compile demonstration described AI-powered conflict-resolution ideas, but that should not be treated as a documented Early Beta guarantee.

Did Cursor launch Origin because GitHub went down?

No evidence shows that. Cursor began its Origin rollout on August 17, the same day GitHub suffered a major outage, creating a highly visible coincidence. Origin had already been announced and demonstrated earlier, so the outage did not create the product overnight.

相关工具

• Cursor Origin: Cursor’s official Git hosting, repository, PR, GitHub mirroring, and agent-integration documentation.
• Origin CLI: Cursor’s command-line interface for Origin repository workflows.
• Cursor Cloud Agents: Cloud-hosted coding agents that can work directly against Origin repositories.
• Cursor Automations: Event-driven and scheduled agent workflows that can react to Origin repository activity.
• Git: The distributed version-control system used by both GitHub and Origin.
• GitHub: The established Git hosting and collaboration platform that Origin can mirror and synchronize with.
• Vercel: A deployment platform that Origin can connect to for pull-request preview deployments.
• Buildkite: A CI/CD platform integrated with Origin and capable of running existing GitHub Actions workflows.

Related Links

• Cursor: Origin Code Hosting: Official August 17 launch announcement and current Early Beta scope.
• Mirror a GitHub Repository: Official documentation for GitHub synchronization, what does and does not sync, and detaching.
• Origin Pull Requests: Official PR workflow, reviews, checks, conflicts, and mirrored GitHub PR behavior.
• Origin Integrations: Official documentation for Automations, Cloud Agents, Vercel, Depot, and Buildkite.
• Cursor: Cloud Agents Lessons: Cursor’s own report that more than 40% of its internal PRs were coming from Cloud Agents by June 2026.
• GitHub Merge Queue Documentation: Official GitHub documentation showing that merge queues are already supported.
• GitHub Stacked Pull Requests: Official GitHub documentation for stacked PRs and their integration with merge queues.

Summary

Cursor Origin is now a real Git hosting platform, not merely a GitHub browser inside Cursor. Its Early Beta can host repositories, use standard Git, mirror GitHub, synchronize pull requests in both directions, browse code, manage reviews, connect CI/deployment apps, and let Cursor agents operate against Origin-hosted repositories.

The source article overstates several agent-native features as already deployed. Current first-party documentation does not yet list native stacked PRs, an Origin merge queue, automatic AI conflict resolution, or an Origin MCP server as generally available Early Beta features. Cursor itself says more agent-native functionality is still coming.

GitHub’s August 17 outage gave Origin an unusually dramatic launch moment, but it did not mean GitHub was replaced overnight. For most teams, the sensible path is to mirror a non-critical repository first, test synchronization and CI, and detach only after Origin has proved it can safely become the source of truth.

The real competitive shift is not that Cursor “killed GitHub”; it is that Cursor now wants to own the repository layer where AI agents create, review, and ship software.