How to Create a Cursor Origin Repository and Push Code to It

From the codebase home at cursor.com/codebase, select New, name the repo in the New repo dialog, pick Internal or Private, and select Create Repo. That is the whole flow, and Cursor's docs describe it in three steps. Once the empty repo exists, open it and the green Code button gives you the clone URL to push against from your machine.

Before you do that, one fork in the road. The New button creates an empty repository, which is right for a fresh project. If the code already lives on GitHub, the same codebase home has a Sync from GitHub button, and that is the one to press; the docs route existing GitHub repos through the mirror path rather than a manual push, because the sync keeps GitHub as the source of truth and carries pull requests both ways. Creating an empty repo and pushing a GitHub clone into it works, but you lose the sync.

1. 1Open cursor.com/codebase and select New.
2. 2In the New repo dialog, enter a Repo Name and choose Internal or Private visibility.
3. 3Select Create Repo.
4. 4Open the new repo and copy the clone URL from the green Code button.

The visibility choice is the part I would slow down on, because the two words do not mean what they mean on GitHub. Internal means visible to anyone with access to your team's codebase. Private means visible only to members granted access directly or through codebase permissions. There is no public option in the early beta, and team access in general follows your Cursor team and codebase access, so a repo's audience is bounded by the codebase before its own setting applies.

Per-repository settings land after creation, on the repo's own Settings tab: General, Permissions, Rules and Protections, and Apps. Codebase-wide controls, including who may create repositories at all, sit one level up in codebase settings, and it is worth knowing which level you are looking at before you go hunting for a missing permission.

Yes. Cursor's docs say agents can create Origin repositories as part of a task: ask the agent in Cursor to create a repo on Origin and it can install the Origin CLI, sign in, create the repo, set the remote and push. The command underneath is origin repo create, and the docs name that explicitly on the integrations page.

The permission model is the thing to hold onto. Agents use the same permissions as your Cursor account, so an agent can only create a repo if your account has access to Origin code storage, and it inherits whatever your team's codebase permissions allow. There is no separate agent identity on Origin in the beta, at least not one the docs describe, which means an agent asked to create a repo in a codebase you cannot create repos in will fail the same way you would.

Cloud agents are a slightly different case, and the distinction is easy to miss. The create-repository page says cloud agents can work against existing Origin repositories: clone, branch, commit, push and open pull requests. The create step is described for a local agent with the CLI installed. I read that as a current boundary rather than a rule, but it is the boundary the docs draw today, so plan on creating the repo first and handing the cloud agent an existing one.

Origin works with standard git, and the docs are careful to put it that plainly. Open a repo at cursor.com/codebase, select the green Code dropdown, and copy the clone URL from the HTTPS tab. The URL format is fixed: https://origin.cursor.com/{owner}/{repo}.git. Clone it the way you would clone anything else.

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

Credentials are where the Origin CLI comes in, even if you never type another origin command. Install it with Cursor's script and run origin auth login; that signs you in through the browser and, per the command reference, also installs the git credential helper, so git push and git pull against Origin remotes work without further setup. Sign in before your first git operation, then fetch, pull and push as normal.

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

For a brand-new empty repo, the push-your-first-commit sequence is the standard one. Clone the empty repo, add files, commit, push with -u so the upstream is set. If the project already exists locally, skip the clone and add Origin as a remote instead.

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

Pulling is git pull origin main, and there is nothing Origin-specific about it. The CLI also offers origin repo clone, which clones over HTTPS using your saved login, and which I would reach for only when I am already in a terminal session that is using the CLI for something else. Plain git clone with the credential helper in place does the same job.

You can, and the docs show the exact incantation: add both hosts as push URLs on one remote, so a single git push updates both. Fetches keep coming from the first URL. It is a plain git feature, not an Origin one, and it is the quickest way to keep a second copy while you decide whether Origin is where you want to live.

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

The docs add a sentence right after that block which is, I think, the more important one: for complete GitHub history migration, mirroring is recommended. The dual-push trick copies commits you push from this machine from now on. It does not copy pull requests, and it does not copy anything a teammate pushes from a laptop without the second URL configured, because remote configuration lives in each clone's own .git/config. The mirroring page covers what the documented sync carries and what no git command ever will.

So the honest guidance is a bit narrower than the command suggests. Use two push URLs for a repo you created on Origin and want a standing copy of elsewhere, or for a solo trial. Use Sync from GitHub for anything a team already works on, and treat the two-URL setup as a personal convenience rather than a team policy.

The docs list two failure shapes, and between them they cover most of what goes wrong in the first hour. A clone or push that is rejected almost always means the credential helper is not signed in; a command not found after installation means the install location is not on your PATH. Both are one command to fix.

One more thing that reads like a bug and is not. If you configured the credential helper with the --local flag, it applies to that repository's git config only, so a second clone on the same machine will prompt or fail until you sign in there too. The CLI reference lists the global and local variants; global is the default, and for a personal machine it is the one to keep.