Cursor Origin Hosts Code Repos

@cursor published an August 17, 2026 changelog for Cursor, Anysphere's AI code editor, announcing Origin Code Hosting in early beta on all paid plans. The release deals with a very practical gap: code, pull requests, and agents often live in separate places. Origin is Cursor's code-hosting surface for repos, pull requests, code browsing, search, and GitHub sync. The useful takeaway is simple: try it on one low-risk repo first, then decide where an agent-native code host actually helps.

This matters for anyone already shaping Cursor rules, Cursor subagents, and Cursor skills around reviewable IDE workflows. The first version is not a full replacement story. It is Cursor putting the repo closer to the agent, while still letting GitHub remain the source of truth for synced projects.

What Origin adds to Cursor

Origin adds a Codebase tab where Cursor-hosted repos can live. Click +New, name the repo, and Cursor gives you CLI instructions to clone it or push an existing local project. After the push, the code is hosted on Origin.

The naming detail is easy to miss. When you create your first repo, you also name the codebase, and that name becomes part of repo URLs such as cursor.com/codebase/acme-corp. That is a product choice with workflow consequences: repo identity is now visible inside Cursor, not just inside your Git remote.

The trap is treating early beta hosting like a mature migration target. As of August 17, 2026, the changelog describes the essentials: repos, pull requests, code browsing, GitHub sync, and agents in repos. Cursor also says agent-native features are coming soon, which means some of the most interesting parts are still ahead.

How GitHub sync changes the boundary

Origin can also mirror GitHub repos into Cursor. You connect GitHub, pick an org, choose repos to sync, and Cursor pulls them into the Codebase tab. Cursor shows icons next to repo names so you can tell which repos are hosted by Cursor and which came from GitHub.

For synced repos, GitHub stays the source of truth. You can browse, search, and pull from Origin's copy, but pushes keep going to GitHub. That makes Origin more like a working copy with agent context than a hard fork of your current Git host.

This is the part developers will care about first. You can bring an existing repo into the same surface as Cursor's agents without asking everyone to abandon the GitHub workflow on day one. The trap is forgetting the write boundary: if the repo started in GitHub, treat GitHub as canonical unless Cursor documents a different path later.

Pull requests move into the codebase view

Every Origin repo has pull requests. Open one and you can see the timeline, commits, checks, changed files, comments, and merge action. That sounds ordinary until you put it next to the agent surface: the diff and the assistant are no longer separated by browser tabs.

Synced GitHub pull requests sync comments both ways. A comment in Cursor posts to GitHub, and a reaction or reply on GitHub appears back in Cursor within seconds, according to the changelog. Assigned GitHub reviews can also be reviewed and merged from Cursor.

The workflow it replaces is the little dance many of us do all day: read a GitHub PR, copy a file path, ask the editor agent about it, return to the browser, then write the review. Origin makes that loop shorter. The trap is letting shorter loops become shallower review; checks, tests, and human comments still need the same attention.

Agents now sit closer to the repo

The release's bigger story is not that Cursor can store Git objects. It is that code, PRs, and agents now appear in the same place. While browsing a repo, you can ask Cursor questions, have it explain code, make changes, update PRs, or push a branch.

That pairs naturally with the way many readers use Cursor custom agents, Cursor subagents, skills, and repo rules. A security-review subagent is more useful when it can see the PR diff and repo context without the user manually stitching that context together. A migration skill is less brittle when the repo being changed is already the thing being browsed.

There is a good comparison point with cloud execution too. If you followed how Cursor Cloud Agents Get Longer Leashes, Origin feels like another move toward longer-lived, repo-aware agent work. The honest limit is that the changelog does not yet spell out the coming agent-native features, so design around the current primitives, not imagined ones.

Try it safely on one repo

Pick one small repo that has real pull requests but low blast radius. A docs site, internal package, example service, or small tool is perfect. The goal is not to move your software supply chain. The goal is to learn what Origin changes when code hosting, PR review, and Cursor agents share a room.

Use the experiment to write down one habit: which actions belong in Cursor, and which still belong at the GitHub boundary. If your repo already has AGENTS.md or .cursor/rules, keep those constraints visible before asking an agent to touch a branch. For deeper Cursor Workshop material on custom agents, skills, and repo-scoped habits, see the related training topic.

Here is a small repo-scoped rule you can paste into .cursor/rules/origin-pr.mdc and adjust:

---
description: Use when reviewing pull requests hosted or mirrored in Cursor Origin
alwaysApply: false
---

Before merging a pull request:
- Identify whether the repo is Origin-hosted or GitHub-synced.
- If GitHub-synced, treat GitHub as the source of truth for branch state.
- Read the changed files and checks before asking an agent for changes.
- Ask the agent to summarize risk by file, not just summarize the PR.
- Leave review comments on concrete lines when possible.
- Do not merge until tests and required checks are visible and passing.

Use this checklist for the first repo:

• Create or sync one small repo in the Codebase tab.
• Confirm who can read and write it in Cursor.
• Open one pull request and compare the Cursor view with GitHub.
• Leave one non-blocking comment in Cursor and verify it appears in GitHub.
• Reply or react in GitHub and verify it appears back in Cursor.
• Ask Cursor to explain one changed file, then check the answer against the diff.
• Ask for a small branch change only after the review context is clear.
• Write down the one step that became simpler and the one step that still felt safer in GitHub.

Common questions

• Can Origin replace GitHub?

  Not for synced repos, based on the August 17, 2026 changelog. Cursor says pushes keep going to GitHub and GitHub remains the source of truth for anything started there. Origin can host new repos directly, but the early beta announcement focuses on essentials, not a full GitHub replacement claim.

• Do pull request comments sync both ways?

  Yes, for synced repos Cursor says pull request comments sync both ways with GitHub. Comment in Cursor and it posts to GitHub; react or reply on GitHub and it appears in Cursor within seconds. The practical caveat is to test this on a low-risk PR before relying on it for a busy review.

• Where do Cursor agents fit in Origin?

  Agents fit directly inside the repo browsing and PR workflow. Cursor says you can ask questions about code you are browsing, have the agent make changes, update PRs, or push a branch. That makes repo rules, review checklists, and Cursor skills more important, because the agent has a shorter path to changing code.

• Should I sync a production repo first?

  No, start with a small repo that has real review activity and low risk. The feature is in early beta on paid plans as of August 2026, and agent-native features are still described as coming soon. A small repo gives you enough signal without turning the test into infrastructure drama.

• Does this change how I write cursor rules?

  Yes, but only a little at first. Rules should now mention the hosting boundary when it matters: Origin-hosted versus GitHub-synced, review-before-merge expectations, and when an agent may push a branch. Keep the rule short enough that it helps during PR review rather than becoming a policy wall.

Best ways to use this research

• Best for: Cursor users who already review PRs in GitHub and want to understand what Origin changes before moving an important repo.
• Best first artifact: A repo-local .cursor/rules/origin-pr.mdc file that names the review boundary and reminds agents to inspect checks before suggesting a merge.
• Best comparison angle: Compare one synced GitHub PR in Cursor and GitHub side by side, then record which comments, reactions, checks, and branch actions stay consistent.
• Best agent experiment: Ask a Cursor subagent or custom agent to review one changed file for risk, then verify the result against the actual diff and tests.

Further reading

• @cursor — source
• Cursor — Agent
• Cursor — Rules

Next step

Sync or create one small repo in Origin, open a real pull request, and test comment sync before asking an agent to change code. Keep the first experiment boring; the interesting part is seeing where the repo boundary moved.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.