# A deep dive into Cursor Origin > Cursor Origin hosts Git repositories inside Cursor. Learn how its repos, GitHub sync, pull requests, agents, apps, CLI, and early-beta limits work. Author: [Flavio Copes](https://flaviocopes.com/about/) | Published: 2026-08-25 | Topics: [Git](https://flaviocopes.com/tags/git/) | Canonical: https://flaviocopes.com/cursor-origin/ Cursor can now host your code. The new service is called [Cursor Origin](https://cursor.com/changelog/origin-code-hosting). Until now, Cursor worked with code hosted somewhere else. Your repository usually lived on GitHub, GitLab, or Bitbucket. Cursor opened it, understood it, and let its agents make changes. Origin adds the missing piece. Cursor can now store the repository too. At first, this sounds like Cursor built a smaller GitHub. That is partly true. Origin has repositories, code browsing, pull requests, access controls, and integrations. But the more interesting part is where the agents sit. Your code, pull requests, and coding agents can now live in the same system. Let's see how it works, what is available today, and where the limits are. ## What is Cursor Origin? Cursor calls Origin a **Git forge**. A Git forge is a service that hosts Git repositories and adds collaboration tools around them. GitHub, GitLab, Bitbucket, and Gitea are all Git forges. Origin starts with the essentials: - Git repositories - browser-based code browsing and search - branches and commit history - pull requests and code reviews - repository permissions - branch rules and merge protections - GitHub mirroring - cloud agents and automations - deployment and CI integrations - a command-line tool and a REST API Origin launched in early beta on August 17, 2026. Cursor is rolling it out on its paid plans. It is available on Pro, Teams, and Enterprise plans. It is not available on the free plan. Early beta matters here. The main workflow exists, but the product, interface, integrations, and API can still change. Cursor keeps the current feature and setup details in the official [Origin documentation](https://cursor.com/docs/origin). ## Origin does not replace Git Before going further, let's separate Git from Git hosting. **Git** runs on your computer. It tracks files, commits, branches, and merges. **Origin** stores a remote copy of that Git repository. It also gives your team a place to browse code, review changes, and run agents. The relationship looks like this: ```text your project → Git commits → Origin repository → pull requests and agents ``` You still use normal Git commands: ```bash git add . git commit -m "Add the search page" git push ``` Origin works with standard Git over HTTPS. It also supports SSH keys. If Git itself is still new to you, start with my free [Git Course](https://flaviocopes.com/courses/git/). It explains commits, branches, remotes, pushing, pulling, and pull requests. ## There are 2 ways to use Origin You can use Origin in 2 different ways. This is the most important choice in the product. ### Origin can host the repository You can create a new repository directly on Origin. In this case, Origin is the **source of truth**. Your team clones from Origin and pushes changes back to Origin. Pull requests also live on Origin. They are not copied to GitHub. ```mermaid flowchart LR Local["Local Git repository"] <--> Origin["Origin"] Origin <--> Agent["Cursor agent"] Origin --> PR["Origin pull request"] ``` This is the clean Origin-native setup. ### Origin can mirror GitHub You can also connect an existing GitHub repository. Cursor copies its Git history, branches, tags, code, and pull requests into Origin. It then keeps that copy updated. GitHub stays the source of truth. ```mermaid flowchart LR Local["Local Git repository"] <--> GitHub["GitHub"] GitHub <--> Origin["Origin mirror"] Origin <--> Agent["Cursor agent"] ``` You can browse the code and work with pull requests inside Cursor. Pushes still go to GitHub, even when you push through the Origin remote. This is the safest way to test Origin with an existing project. You get the new interface and agent workflow without moving the main repository. ## The Codebase is the home for your repositories Origin repositories live in the new **Codebase** area at [cursor.com/codebase](https://cursor.com/codebase). The first time you open it, Cursor asks you to sync a repository from GitHub. Click **Get Started** to begin. ![Cursor Codebase page with the Get Started button for syncing repositories from GitHub](https://flaviocopes.com/images/cursor-origin/codebase-get-started.png) Cursor then asks you to claim a codebase name. That name becomes part of every repository URL. ![Cursor Codebase setup asking for a unique URL path for the repositories](https://flaviocopes.com/images/cursor-origin/codebase-name.png) For example, a team called `acme` could have this repository: ```text https://cursor.com/codebase/acme/checkout ``` Choose this name carefully. Cursor says you cannot change the namespace during the beta. From the Codebase page, you can create a repository or sync one from GitHub. Origin shows an icon beside each repository. The icon tells you whether Origin hosts it or mirrors it from GitHub. That small detail is useful. Both kinds appear in the same list, but they do not behave in the same way. ## Creating an Origin repository The simplest way to start is through the browser. Open the Codebase page, select **New**, enter the repository name, choose its visibility, and create it. Origin currently offers 2 visibility levels: - **Internal** makes the repository visible to people with access to the team's codebase - **Private** limits it to people granted access directly or through codebase permissions Notice what is missing: public repositories. The current creation flow only documents Internal and Private visibility. That makes Origin suitable for private work and team projects, but not yet a complete home for public open source projects. You can also ask a Cursor agent to create the repository. The agent can install the Origin CLI, sign in, create the repository, add the remote, and push the code. The agent uses your Cursor permissions. It cannot create a repository you are not allowed to create. ## Installing the Origin CLI Origin has its own command-line tool named `origin`. It is separate from the Cursor Agent CLI. The Agent CLI runs a coding agent. The Origin CLI manages repositories, authentication, pull requests, rules, SSH keys, and API requests. Cursor provides this installation command: ```bash curl -fsSL https://downloads.cursor.com/origin/install.sh | sh ``` Then sign in: ```bash origin auth login ``` The login opens a browser and configures a Git credential helper. After that, normal `git push` and `git pull` commands can authenticate with Origin. You can check the current login with: ```bash origin auth status ``` The official [Origin CLI documentation](https://cursor.com/docs/origin/cli) includes installation details and troubleshooting steps. ## Creating and cloning repositories from the terminal You can create a repository without opening the browser: ```bash origin repo create origin-test ``` When you omit a namespace, Origin creates the repository under your account. My account would then clone it like this: ```bash origin repo clone flaviocopes/origin-test ``` Alternatively, use standard Git: ```bash git clone https://origin.cursor.com/flaviocopes/origin-test.git ``` If the project already exists on your computer, add Origin as its remote: ```bash git remote add origin https://origin.cursor.com/flaviocopes/origin-test.git git push -u origin main ``` This is the same remote workflow you already use with GitHub. If you want a short refresher, see [how to add a Git remote](https://flaviocopes.com/git-add-remote/). ## Browsing and searching code Every repository has a **Code** tab. You can browse folders, open files, switch branches, and inspect commit history. Select a commit to see its metadata and changed files. Press `T` to open **Go to file**. You can also use the search field to find files and code matches. This part feels familiar if you already use GitHub. The difference is that an agent is available beside the code. You can ask questions about the file you are reading. The agent can explain the code, follow a call across the repository, make a change, and push a branch. The repository is not just a page an agent can read. It is part of the agent's working environment. ## Pull requests in Origin Origin repositories have pull requests. Push a branch first: ```bash git switch -c add-search git push -u origin add-search ``` Then open a pull request from the browser or the Origin CLI: ```bash origin pr create -t "Add search" --status open ``` The pull request page has 4 main areas: - **Activity** shows comments, reviews, and status changes - **Commits** shows every commit in the change - **Checks** shows CI results for the branch - **Files Changed** shows the diff and inline comments You can request reviewers, comment on lines, approve a change, request changes, inspect merge conflicts, and merge when the review and checks are complete. The CLI covers the same workflow: ```bash origin pr diff origin pr checks origin pr review --approve origin pr merge ``` Most `origin pr` commands detect the repository from the current `origin` Git remote. They also detect the pull request for your current branch when you do not provide a number. This makes the CLI useful for both people and agents. An agent can create, inspect, update, and merge a pull request without scraping a web page. ## How GitHub mirroring works [GitHub mirroring](https://cursor.com/docs/origin/mirror-github) lets you bring an existing project into Origin without moving it. You need: - an Origin-enabled Pro, Teams, or Enterprise plan - the Cursor GitHub app connected to the account or organization - GitHub admin access to the repository you want to mirror Open the Codebase page and start the setup flow. Cursor first shows the GitHub organizations you can access. ![Cursor Origin setup showing the available GitHub organization](https://flaviocopes.com/images/cursor-origin/select-github-organization.png) Open the organization and select the repositories you want to sync. ![Cursor Origin setup with the flaviocopes.com GitHub repository selected](https://flaviocopes.com/images/cursor-origin/select-github-repository.png) Select **Continue**. Origin then shows who will have access to each repository. ![Cursor Origin repository access review before starting the GitHub sync](https://flaviocopes.com/images/cursor-origin/review-repository-access.png) Review this screen before confirming. GitHub permissions and Origin permissions are related, but they are not the same thing. Select **Sync Repo** when everything looks right. Origin starts receiving the repository and marks GitHub as the source. ![Cursor Origin settings showing the flaviocopes.com repository syncing from GitHub](https://flaviocopes.com/images/cursor-origin/github-sync-status.png) Origin then copies the repository and keeps it updated. Here is what currently moves across: | Synced to Origin | Stays on GitHub | | --- | --- | | Git history, branches, and tags | GitHub Issues | | Files and code search | GitHub Actions workflows | | Pull requests, comments, and reviews | GitHub Actions secrets | This is not a complete GitHub backup. The mirror gives Origin the code and pull request workflow. GitHub still owns issues, Actions, secrets, and the main repository. ## Mirrored pull requests sync both ways Pull requests on mirrored repositories appear in both services. You can leave a comment in Origin and see it on GitHub. A reply or reaction added on GitHub appears in Origin within seconds. You can also review and merge a GitHub pull request from Origin. This bidirectional sync is what makes the mirror useful. A team does not need to move every reviewer into Cursor on the first day. Some people can keep working in GitHub. Others can work in Origin. Both sides see the same pull request conversation. ## GitHub remains the source of truth Mirroring does not quietly move ownership to Cursor. If a repository started on GitHub, pushes still go to GitHub. Origin keeps its copy updated from there. You can clone the Origin remote and push to it, but Origin passes that push through to GitHub. This removes a common source of confusion. You do not end up with 2 independent repositories that slowly drift apart. If you later want to move fully to Origin, open the repository settings and select **Detach from GitHub**. Detaching stops the sync and turns the Origin copy into a standalone repository. Origin becomes the source of truth. The original GitHub repository is not changed. From that point forward, the 2 repositories can diverge. ## Agents are part of the repository workflow Origin is not only code storage inside the Cursor website. Cursor cloud agents can work directly against Origin repositories. They can: - clone the repository - create a branch - change files - run the project's checks - commit and push - open a pull request - respond to review feedback You can also ask questions while browsing a repository. The agent has the surrounding code and can move from explanation to implementation. This removes a layer of setup. With a separate code host, Cursor needs permission to connect, clone, push, and update the pull request. With Origin, those operations belong to the same Cursor account and permission system. This does not remove the need for permissions or review. It makes the connection more direct. Cursor says more agent-native features are coming. I would treat that as direction, not as a feature list. The current product already connects agents to repositories and pull requests, but the deeper roadmap has not been defined publicly. ## Automations can react to repository events Cursor Automations can run cloud agents on a schedule or after a source-control event. For an Origin repository, an automation can react to events such as: - a push to `main` or `master` - a pull request being opened - new commits pushed to a pull request The automation can inspect the repository, run a task, make changes, and open or update a pull request. This is where the phrase "designed for agent scale" starts to make sense. One person opening one repository does not need a new Git forge. A team running many agents needs reliable repository access, event triggers, permissions, branches, checks, and review paths. Origin puts those pieces under the same product. ## Deployments and CI Origin launched with integrations for Vercel, Depot, and Buildkite. Connect Vercel from the repository's **Apps** tab. A pull request can get a preview deployment where you test the change and leave comments. Merging can deploy the production version. Depot and Buildkite provide CI for repositories hosted on Origin. Both can run existing GitHub Actions workflows, and Buildkite can run its own pipelines too. There is an important limit for mirrored repositories. Depot and Buildkite work with Origin-hosted repositories. A GitHub mirror keeps its CI on GitHub. Origin's app ecosystem is still small. That is normal for an early beta, but it matters if your project depends on a long list of GitHub Apps. ## Repository permissions and protections Repository settings are split into 4 areas: - General - Permissions - Rules and Protections - Apps Permissions control who can access the repository. Team-wide codebase settings control who can enable Origin, create repositories, and grant access to other members. Origin follows the Privacy Mode of the person or team that owns the namespace. Teams using Cursor's legacy privacy mode must switch to the current Privacy Mode before enabling Origin. Rules and Protections handles branch rules and merge protections. Cursor says this interface is still being redesigned, so names and controls can change during the beta. My advice is to test the permission model before moving an important repository. Create a private test repository, add a teammate, and verify who can browse, push, create pull requests, change rules, and install apps. Do not assume a new forge copies every GitHub permission exactly. ## Origin also has a public API Origin is not limited to the website and CLI. The [Origin REST API](https://cursor.com/docs/api/origin) lets tools work with repositories, commits, checks, pull requests, reviews, and app installations. Origin Apps use a model similar to GitHub Apps: 1. An app signs a short-lived token. 2. It exchanges that token for an installation token. 3. The installation token only accesses approved repositories and scopes. 4. Origin sends signed webhooks when relevant events happen. The `origin api` command can call endpoints that do not yet have a dedicated CLI command. This matters for the future app ecosystem. CI providers, deployment platforms, internal tools, and agents need a stable machine interface. A browser UI is not enough. The API is also in early beta. Cursor tells integration authors to review the current API specification when updating an app. ## Is Origin a GitHub replacement? Not yet for most teams. Origin already covers the core private repository workflow: - host code - clone, push, and pull with Git - browse and search files - review and merge pull requests - control team access - run agents and automations - connect selected deployment and CI services But GitHub is much larger than that core. Origin does not currently mirror GitHub Issues or Actions secrets. Its native app ecosystem is small. The documented creation flow has no public repository option. GitHub also has releases, packages, discussions, projects, security tools, sponsors, social discovery, and a huge integration ecosystem. You can see the larger GitHub surface in my [developer's introduction to GitHub](https://flaviocopes.com/github/). So I would not describe Origin as a complete GitHub replacement today. I would describe it as a new Git hosting path for teams that want Cursor agents closer to their repositories and pull requests. That narrower description is still important. ## How I would use Cursor Origin I would start with a small private project. I publish many self-contained projects in my [software library](https://flaviocopes.com/software/). They include source code, tests, documentation, and instructions for coding agents. One of those repositories would be a good Origin test. I would not move the repository on day one. I would mirror it from GitHub and keep GitHub as the source of truth. Then I would test one complete workflow: 1. Browse the project in Origin and ask the agent how one feature works. 2. Ask a cloud agent to make a small change on a branch. 3. Let it open a pull request. 4. Review the diff and leave one line comment in Origin. 5. Confirm the comment appears on GitHub. 6. Push another commit and verify checks and sync behavior. 7. Merge from Origin and confirm GitHub matches. This test would tell me much more than a feature list. I would check authentication, sync delay, agent setup, permissions, review quality, CI results, and what happens when the agent fails halfway through. I would not move flaviocopes.com to a native Origin repository yet. This site depends on GitHub Actions and Cloudflare Pages. Origin's current native integrations focus on Vercel, Depot, and Buildkite. A GitHub mirror also does not copy Actions secrets. Keeping GitHub as the source of truth would preserve the deployment workflow while still letting me test Origin's agents, code browsing, and pull request interface. Later, if Origin adds the integrations I need and proves reliable, I could detach the mirror. That would be a deliberate migration, not an experiment performed on the main repository. ## When Origin is a good fit Origin is worth testing when: - your team already uses Cursor heavily - most repositories are private - cloud agents create or review many pull requests - you want repository events to trigger Cursor Automations - your deployment and CI tools already integrate with Origin - you want to evaluate it through GitHub mirroring first The GitHub mirror makes the last point easy. You can test the workflow without immediately moving the repository. ## When I would wait I would wait when: - the repository is public open source - the project depends on GitHub Issues, Discussions, Projects, or Releases - many GitHub Apps are part of the workflow - your compliance process has not approved Cursor as a code host - the repository needs a mature and stable API contract - an early-beta failure would stop an important release Origin stores your source code. Treat that as an infrastructure decision, not as an editor preference. Review access, privacy, backups, recovery, audit needs, and exit paths before moving important work. ## The interesting part of Origin The repository host used to sit outside the coding agent. The agent opened a GitHub repository, made a branch, pushed it back, and updated a pull request through an integration. Origin pulls that infrastructure into Cursor. For one developer, this removes a few steps. For a team running many agents, it could become more important. The code host can understand agents as normal participants in the workflow instead of treating them like external bots. Origin is not there yet as a complete GitHub replacement. It does not need to be one on day one. The practical starting point is smaller: mirror one private GitHub repository, keep GitHub as the source of truth, and test a complete agent-to-pull-request workflow. That is how I would evaluate it.