Vibe coding

Cursor Origin: Git hosting for the agent era (early beta guide)

We teased Origin in the free-hosting newsletter. Here's the junior-friendly setup: claim a codebase, install the CLI, sync from GitHub, keep GitHub as source of truth — Origin as backup while the beta evolves.

~13 min read

Back in the free hosting for vibe coding (2026) newsletter — Part 3 of Free vibe coding stack — we said we were testing Cursor Origin and that a write-up with what actually works (and what doesn’t) would land here.

Here it is.

This is the early-beta guide I wish I’d had on day one: what Origin is, who can use it, how I set it up (GitHub stays primary), and a junior-friendly walkthrough from Cursor’s docs. No invented demo numbers — just the paths that are documented today.

What is Cursor Origin?

Origin is Cursor’s own git forge — a place to store, share, browse, and review code, the same basic job GitHub / GitLab / Bitbucket do.

Cursor’s framing: a git forge for the agent era. Agents already write a lot of the diffs; Origin is meant to sit next to Cursor’s agents, automations, and PR review instead of living only on a separate host.

In early beta you can:

• Create Origin repositories (including from Cursor agents)
• Clone, push, and pull with standard git
• Mirror a GitHub repository into Origin
• Open, review, and merge pull requests
• Browse and search code at cursor.com/codebase
• Connect automations and cloud agents to Origin repos
• Install the Origin CLI for terminal workflows

Primary docs: cursor.com/docs/origin. Changelog kickoff: Origin Code Hosting (17 Aug 2026).

Short aside: Graphite

Cursor acquired Graphite (deal announced 19 Dec 2025). The Graphite team builds Origin. Graphite’s stacked-PR DNA is useful context — not a promise that every unshipped review feature is live. Cursor’s own changelog says essentials first (repos, PRs, browse, GitHub sync) and agent-native features ship soon. I’ll stick to that wording.

Who it’s for (plans)

Origin code storage is on Pro, Teams, and Enterprise. It is not on Free plans.

Access opens in stages, so you may not see Origin immediately after it becomes available for your plan. Enterprise admins can opt out. Teams on legacy privacy mode need to switch to Privacy Mode first.

If you don’t see a Codebase / Origin entry yet: you’re not doing it wrong — the rollout is staged.

My setup: GitHub primary, Origin as backup

I’ve synced a few of my repos to Origin.

Stance (locked):

1. GitHub stays my primary remote — source of truth for day-to-day work, CI, Issues, and the ecosystem I already use.
2. Origin is backup / mirror while the feature evolves — browse, search, agent workflows, and a second copy if GitHub is having a bad day.
3. I’m excited about what Origin brings next. I’m not ripping GitHub out.

That matches how synced repos work in the docs: GitHub = source of truth, Origin = mirror. Pushes to the Origin HTTPS remote go to GitHub; Origin updates after GitHub accepts the push. PRs sync both ways.

The landscape: GitHub, GitLab, Bitbucket, Origin

Most vibe-coded projects already live on one of three hosts:

Together, GitHub + GitLab + Bitbucket (and now Origin as the new option) cover roughly 99% of the codebases you’ll touch. You don’t need to “pick a religion.” You need a primary remote you trust, plus optional mirrors for backup and agent workflows.

Enable Origin (claim a codebase)

Before anyone on the team can use Origin, someone claims a codebase name — the namespace your repos live under ({owner} in https://cursor.com/codebase/{owner}/{repo}).

During the beta you can’t change that namespace after it’s claimed. Choose carefully.

1. Open cursor.com/codebase
2. Select Get Started and follow the setup flow
3. Admins can disable Origin later from the dashboard if needed

After enablement, the codebase home lists repos. Icons show whether a repo is Origin-hosted or synced from GitHub.

Install the Origin CLI + auth

The Origin CLI (origin) is separate from the Cursor Agent CLI (agent).

macOS, Linux, and Windows (WSL):

curl -fsSL https://downloads.cursor.com/origin/install.sh | sh

The installer puts the binary at ~/.local/bin/origin. If your shell says command not found: origin, add that directory to your PATH.

zsh:

echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.zshrc
source ~/.zshrc

bash:

echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc

Verify and sign in:

origin --version
origin auth login

Complete the browser flow with the Cursor account that has Origin access. Signing in also sets up the git credential helper, so git push / git pull against Origin remotes work without extra token juggling.

Useful CLI bits:

origin repo create my-project
origin update

origin repo create without a slash creates the repo in your account’s namespace. Agents can drive the same commands.

Docs: Install the Origin CLI.

Sync from GitHub (recommended for existing work)

If the code already lives on GitHub, don’t recreate it empty — mirror it.

Prerequisites

• Cursor account with Origin access (Pro / Teams / Enterprise)
• Cursor GitHub app connected to the org or account that owns the repo
• GitHub admin on the repository you want to sync

Steps

1. Open cursor.com/codebase
2. Select Sync from GitHub
3. Choose the GitHub organization and repository
4. Confirm the sync

When it finishes, open the Origin copy to browse files and history. Sync status lives under Settings → General. Synced repos show Origin as the mirror and GitHub as the source.

What syncs vs what doesn’t

Workflow files may still be in the git tree. They do not run on Origin as GitHub Actions. Issues and CI configuration stay on GitHub.

Docs: Mirror a GitHub repository.

Create an Origin-native repo (alternative)

Use this when the project does not already live on GitHub, or you explicitly want Origin as source of truth.

From cursor.com/codebase:

1. Select New
2. Enter a Repo Name and choose Internal or Private
3. Select Create Repo
4. Copy the clone URL from the green Code button

Push your first commit:

git clone https://origin.cursor.com/{owner}/{repo}.git
cd {repo}
# add your files
git add .
git commit -m "Initial commit"
git push -u origin main

Or attach a remote to an existing local project:

cd your-project
git remote add origin https://origin.cursor.com/{owner}/{repo}.git
git push -u origin main

You can also ask a Cursor agent to create an Origin repo as part of a task — it can install the CLI, sign in, create, set the remote, and push (same permissions as your account).

Docs: Create an Origin repository.

Push, pull, clone, PRs, browse

Clone URL form (HTTPS):

https://origin.cursor.com/{owner}/{repo}.git

Example:

git clone https://origin.cursor.com/acme/checkout.git

On a mirrored GitHub repo, that same URL is the remote you use — but GitHub stays source of truth. git push to this remote goes to GitHub; Origin mirrors after.

Browse and search: cursor.com/codebase.

Pull requests: every repo has PRs. On synced repos, PRs sync both ways — comment in Cursor and it posts to GitHub; replies on GitHub show up in Cursor.

Optional: dual-push remote (advanced)

While you evaluate, you can keep GitHub and Origin in parallel with push URLs:

git remote set-url --add --push origin https://github.com/acme/checkout.git
git remote set-url --add --push origin https://origin.cursor.com/acme/checkout.git

For a full history copy from GitHub into Origin, prefer the Sync from GitHub UI over hand-rolled remotes.

Docs: Clone, Push & Pull.

When GitHub is unavailable (backup angle)

On a mirrored repo, docs describe keeping work on the Origin copy with origin/* branches and origin push local:

git branch origin/my-state HEAD
origin push local

That path writes Origin-only refs under origin/…. It is not a substitute for git push origin when you want a normal GitHub PR. Reads of an already-synced repo may still work over the HTTPS clone URL; Git LFS batch does not fail over. Use this carefully as a backup / keep-coding path, not as your default daily workflow.

What does NOT sync (honest beta)

Worth repeating so nobody gets surprised mid-migration:

• Issues stay on GitHub
• Actions workflows and secrets stay on GitHub (files in the repo ≠ runners on Origin)
• Branch protections as GitHub settings don’t come over as a full Settings clone
• Branches named origin or origin/… on GitHub are skipped on purpose (so they can’t overwrite Origin-only workspace branches)

Apps already called out in the Origin Code Hosting changelog: Vercel, Depot, and Buildkite, with more coming. Third-party explainers note Depot/Buildkite as Origin-hosted-oriented — always re-check Cursor’s Integrations docs for the current matrix.

Detach anytime: Settings → General → Detach from GitHub (Danger Zone). That stops sync and makes the Origin copy standalone; your GitHub repo is not deleted.

Cloud agents + Origin (light)

Origin works with Cursor Automations and cloud agents:

• Point an automation at an Origin repo the same way you would at connected GitHub / GitLab
• Cloud agents can clone, branch, commit, and push
• On an Origin-hosted repo they open Origin PRs
• On a mirrored GitHub repo they open GitHub PRs

Local agents can create Origin repos via the CLI. Docs: Origin integrations.

What I’d do

1. If you’re on Pro / Teams / Enterprise and Origin is visible, try it on a non-critical repo first.
2. Prefer Sync from GitHub for existing work — keep GitHub as source of truth.
3. Send feedback to hi@cursor.com (Cursor asks for any and all feedback in the docs).
4. Keep your primary forge (GitHub / GitLab / Bitbucket) until Origin’s beta gaps (Issues, Actions, protections, ecosystem) match how you actually ship.

I’ll keep watching what ships next — especially agent-native review — and update when the product moves. For now: mirror, don’t migrate your whole life.