Cursor Origin Hosts Code Repos
@cursor published an August 17, 2026 changelog for Cursor 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. 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.
Don't treat 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. Watch for 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. Don't let 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 Subagents and skills.
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.
Further reading
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.