Cursor launches Origin to take on GitHub?

Cursor brings over GitHub's core trio, and stuffs Agent into the same page

On August 17, 2026, Anysphere—Cursor's parent company—opened early beta access for Origin, its code hosting service. Repos, PRs, code browsing, and two-way GitHub sync rolled out all at once.

Origin launched with four pieces: repos, PRs, code browsing, and two-way GitHub sync. All paid users can access it; enterprise accounts require an admin to opt in. Creating a new repo starts with clicking the new Codebase tab on the left sidebar; the first time each user creates a repo, they name the entire codebase, and that name gets baked into every repo URL in the format cursor.com/codebase/your-name. The CLI provides the corresponding clone and push commands—push your local code and it lives on Origin.

GitHub repos can be synced into Cursor, sitting alongside self-hosted ones. Repo icons show which are hosted natively by Cursor and which were pulled from GitHub. Sync is a one-way mirror—the source stays on GitHub, pushes still go to GitHub, and the copy in Cursor is a read-only replica that updates in real time. The PR experience is a GitHub clone: timeline, commits, checks, file changes, diffs, comments, and merging are all there. Comments made in Cursor get written back to GitHub; replies on GitHub show up in Cursor within seconds. PR reviews assigned to you on GitHub can be viewed and merged directly in Cursor—no need to switch back to the original platform.

The connective layer underneath is an Agents entry point: code, PRs, and Agent (Agent: an AI assistant that can execute tasks autonomously) are compressed into the same page.

While browsing code, you can ask Cursor directly—it can answer, modify code, update PRs, or push a new branch. The surrounding app ecosystem plugs into Vercel, Depot, and Buildkite—Vercel handles preview deployments for every PR, while Depot and Buildkite run CI. GitHub Actions pipelines continue to work as usual.

Origin turns GitHub into a data foundation

Origin's real pitch is letting an Agent complete the full loop—"read code → edit code → submit PR → see preview"—within a single page.

Cursor replicated GitHub's repo skeleton inside Origin: repos, PRs, code browsing, GitHub sync—the official changelog lists these four as "the essentials." But replication is just surface-level.

Cursor ties every repo to an Agent: open any file in the repo page, ask it questions directly, and it can modify code, push branches, and update PRs. A repo is no longer just a neutral container for human collaboration—it becomes an Agent's workbench.

GitHub sync runs through a two-way channel. Origin pulls a copy of the GitHub repo; browsing, search, and pulls all hit this local replica. Pushes still go back to GitHub, which remains the source of truth.

PRs sync in seconds, both ways—comments you write in Cursor appear instantly on GitHub, and reviews assigned to you on GitHub can be merged directly in Cursor. The permission model carries over verbatim: anyone who can read on GitHub in a synced repo can read in Cursor.

This front-end-on-top, GitHub-in-back design demotes GitHub to a data layer and elevates Cursor's own interface to the default entry point. Developers open cursor.com/codebase/acme-corp every day, not github.com.

Repos, PRs, and Agent coexist in the same tab. Fewer window switches is the small thing; what's being reshaped is *where* code gets modified.

CI (Continuous Integration: automatically running tests and builds on every commit) and deployment are handed off to the ecosystem. Origin's Apps tab already integrates three providers: Vercel, Depot, and Buildkite—Vercel auto-spawns a preview environment for every PR and ships on merge; Depot and Buildkite run GitHub Actions workflows, and Buildkite also runs its own native pipelines. The official line says "with more coming soon," but there's no timeline, and no mention of whether GitHub Actions runners or Codespaces will plug in. Origin itself has no native CI or deployment capability—it outsources that chain to vendors that specialize in it, then packages it as "one-click setup inside Origin."

Each repo's settings page reveals where the design emphasis lies: you can see GitHub sync status, permissions, and which apps are connected; the permission model inherits GitHub's read/write access. Origin opened to all paid plans in early beta on August 17, with enterprise organizations able to opt out through admins. The skeleton came first; Agent-native features are still on the way.

Origin isn't stealing GitHub's cake—it's reshaping the cake pan

On day one, Origin can do everything GitHub already does. But the changelog's opening line reads "designed for agent scale," and the direction is clear—this hosting permission model was never written for humans in the first place.

Most analyses stop here: Cursor finally has its own GitHub. Origin's changelog puts repos, PRs, code browsing, and GitHub sync side by side in the first sentence, followed immediately by "Agent-native features ship soon." What's arrived first are GitHub's existing basics; Agent-native capabilities are still pending. An early beta deliberately shipping the part that looks most like GitHub first—this is groundwork.

Here's the judgment call: Origin's current permission system—read access, write access, PR comments, merging—maps almost one-to-one with GitHub. But from day one, it stuffed an "Ask Cursor questions about code you're browsing" button into every repo page. The Agent can answer, modify code, update PRs, and push branches—four actions in one page. GitHub scatters those four actions across four products: issues, PRs, Actions, and Codespaces. GitHub assumes humans read code, so the UI breaks tasks apart to match human cognitive pacing; Cursor assumes Agents operate code, so the action surface is flattened into a single panel.

Origin's differentiation lands elsewhere: when an AI Agent (an AI program that can execute tasks autonomously) holds the same read, edit, submit, and merge permissions as a human, Git's permission model needs to be rebuilt. The repo is just the place where that happens.

That's also why Origin makes GitHub sync work like "push it over, and the original GitHub repo stays as-is." Anysphere doesn't need to migrate GitHub users; it just needs to give existing Cursor users one more option: host internal projects on Origin, keep open-source projects on GitHub. The early beta is open to all paid plans, except enterprise—and that exclusion order reveals the target audience: dev teams that can't yet deploy a GitHub alternative inside their company, starting with individual paying users and external enterprise projects.

From a moat perspective, GitHub's壁垒 is network effects—open-source projects, third-party integrations, CI (Continuous Integration: automatically running tests and builds after a code push) ecosystem.

Origin's current CI integrations (Vercel, Depot, Buildkite) explicitly state they "run your existing GitHub Actions workflows"—it's not building a new CI ecosystem, it's plugging into the GitHub Actions chain that's already mature.

The Vercel path is especially worth watching: every PR automatically gets a preview deployment you can comment on; merge goes to production. This compresses the GitHub PR review loop from "look at a diff" to "look at a running page"—the cost structure of front-end project reviews gets reshaped.

Origin's pitch is the agent workflow, not the repo

Origin positions itself as "designed for agent scale"—repo hosting is just the foundation; what's valuable is the new workflow where AI modifies code, pushes branches, and merges PRs right in place.

Reading the product order reveals priorities. Repos, PRs, code browsing, and GitHub sync are the "baseline," officially called essentials; agent-native features are tagged "ship soon" and tucked into the final paragraph of the announcement.

The original repo stays on GitHub, Cursor maintains a mirror, and writes only flow back to GitHub. Coexistence lowers the migration barrier—encircle first, harvest later.

The homepage flaunts a SOC 2 Certified badge, but SOC 2 covers enterprise-wide security—the audit granularity of repo-level Agent operations is a different matter. Origin's announcement doesn't mention Agent operation logs, nor any mechanism like "human confirmation required for every branch push."

For enterprises migrating from GitHub, this compliance gap remains open. Code Review and CLI have already spun off into separate product lines; Origin clearly intends to fold these capabilities into a single browser flow: read code, edit code, merge code.

Track consolidation is already underway. GitHub's own Copilot being tightly coupled to repos is a signal in the same direction. By staking out agent-first code hosting with Origin, Cursor opens a second front beyond the editor.

Validation point: when does the "Agent-native features ship soon" line in Origin's announcement turn into concrete features? If end-to-end agent-driven code modification and PR submission launches within 3 months, the positioning holds; if it stays vague, Origin is just a sync mirror layer on top of GitHub.

Another watch item: any movement on self-hosted deployment options. Anysphere's homepage currently lists only SOC 2, with no mention of FedRAMP or self-deployment. Finance and government-sector procurement requires those credentials. "Enterprise org admins can choose not to enable it" is an opt-out for existing customers, not a new deployment model.

GitHub sync's two-way nature is a planted hook: enterprises won't migrate repos immediately; both sides coexist. The "GitHub stays the source of truth" line in Origin's announcement is a status description, not a promise. Anysphere is betting that once agent features mature, users will move more of their daily operations to the Cursor side.

Hands-on checklist: five steps to validate Origin

Origin is open in early beta to all paid tiers; enterprise requires admin opt-in. The steps below have clearly documented entry points in the source material.

Don't rush to move production repos in. In the Codebase tab, follow the UI prompts to create a small repo with a name that doesn't collide with any existing project, push up a toy local project, and run through clone, push, and PR flows to confirm they work. Cursor provides a set of CLI commands at this step—copy them as-is; the URL will look like cursor.com/codebase/your-name.

If you already have GitHub repos, prioritize "sync" over "host." In the Codebase tab, connect GitHub, select an org, pick a few repos to sync in, and verify two things: after editing a file, does the Cursor side update within seconds; does a comment you leave on a PR in Cursor appear on GitHub? The official promise is "second-level" two-way sync—visible to the naked eye.

The third step is connecting an app. The Vercel integration is one click in the Apps tab—every PR gets a preview deployment, and merging auto-deploys to production. For CI, pick either Depot or Buildkite, both of which can run your existing GitHub Actions workflows. With this step done, the shortest "code—Agent—deploy" chain is proven.

The workflow Origin is really selling—"Agent edits for you, PRs auto-open, merges auto-deploy"—has the app extension scaffolding already in place per the source material; the Agent side is still a teaser. Step 4 in the checklist validates current capability; step 5 watches the future it wants to sell you. The gap in between waits for the official release to judge. Team admins should confirm in the backend that nothing is turned off by default.