Cursor Origin Codebase Settings, Apps and Automations Explained

Origin has two settings surfaces, and the docs draw the line between them in one sentence: codebase settings apply across your team's Origin repos, not to a single repository. You open them from the codebase home, and they are separate from the Settings tab inside any one repo. Per-repository sync status, permissions and rules live on that repo tab; who may use Origin at all, and which apps are installed for the team, live at the codebase level.

It helps to know why the split exists. A codebase on Origin is the namespace a team admin claimed when enabling Origin, and every repo URL lives under it. Controls that govern the namespace, membership and app installs are naturally codebase-wide. Controls that govern one repo's branches, protections and collaborators are naturally per-repo. The confusing cases are the ones that appear on both, such as Permissions and Apps, and the rule there is that the codebase level grants the capability and the repo level shows or scopes it.

If you are looking for a setting and cannot find it, the quickest test is to ask whether the thing you want to change could sensibly differ between two repos in the same team. Branch rules can, so they are on the repo. Whether Origin is enabled cannot, so it is on the codebase.

Team-level permissions control who can use Origin for your codebase, which the docs unpack as two questions: who can access repos under your claimed codebase name, and how Origin relates to your Cursor team membership. The enabling step belongs to a team admin, and everything else follows from it.

1. 1A team admin claims the codebase name and enables Origin. Non-admins can request access from the same page.
2. 2Once Origin is enabled, admins can create repositories and use Permissions to grant access, including repository creation, to other members.
3. 3Admins can disable Origin for the team at any time from the dashboard.

The privacy-mode rule is the one that catches established teams. Teams on legacy privacy mode cannot enable Origin; the docs say to switch to Privacy ModeCursor's setting that guarantees code data is not used for training by Cursor or its model providers, and that an admin can enforce org-wide; data-retention terms are a separate, contractual layer. Press Enter for the full definition. first if you want access. That is a team-wide setting change with its own consequences, so it is worth reading Cursor's privacy page before flipping it, and it is a decision for whoever owns the team's data policy rather than whoever wants to try Origin this afternoon.

Repository creation being a grantable permission is a detail I like, because it means an admin can keep the namespace tidy without being the only person who can start a project. Grant creation to leads, keep the default narrow, and revisit it once the team has a naming habit.

Apps, under codebase settings and also at cursor.com/codebase/settings/apps, is where you install and manage apps for your codebase. The docs describe two kinds. Third-party apps such as Vercel, Depot and Buildkite are installed here, and the repo-level Apps tab then shows which of them are active on a given repository. Internal apps are for API access: create one for your team, then use its credentials and the installation flow to call the Origin API.

The authentication model is stated in one line and it is the GitHub Apps model in all but name: apps authenticate with app JWTs and installation access tokens. Base URL, scopes, webhooks and the endpoint reference live on the Origin API page, which this article does not restate. If you want to poke at the API before writing an app, the Origin CLI has an origin api command that makes authenticated requests with your own login, and that is a cheaper first experiment than registering an internal app.

Three named third-party apps is a short list, and I would read it as the beta's list rather than the product's ceiling. What the docs do not say is whether a marketplace or a self-service app registration for outside vendors exists; internal apps are the only documented way to build your own today.

Yes, and the docs frame it as no different from GitHub or GitLab. Origin works with Cursor AutomationsA cloud agent set to run on a schedule or an event trigger; each one is a trigger plus an instruction plus the tools it may use. Press Enter for the full definition. and cloud agents so agents can review, change and push code on your Origin repos. An automation runs cloud agents on a schedule or when source-control events fire, and you point one at an Origin repository the same way you would at a connected GitHub or GitLab repo.

• Push to branch, for example a push to main or master.
• Pull request opened, Pull request pushed, and related PR events.

Those are the common triggers the integrations page lists for Origin repos; billing, permission scopes and the full trigger list are on the Automations docs. You create automations from cursor.com/automations, from the Agents WindowCursor's surface listing your agent runs; open a run to read its diff and search transcripts from the command palette. Press Enter for the full definition., or with the /automate skill, choose the Origin repository or a multi-repo environment that includes it, set the trigger and the prompt, then save and activate.

Cloud agents outside an automation can work against Origin repositories too: clone, branch, commit, push and open pull requests. You attach one to an Origin repo from your team's codebase the same way you attach one to other connected source control, and the agent uses your Cursor account's Origin access. A local agent in Cursor can go one step earlier and create the repository, through the Origin CLI; the create-repository page covers that flow and the permission it depends on.

The part that matters for governance is that none of this introduces a new identity. An automation or a cloud agent on Origin acts with the Origin access of the account that set it up, so the Permissions decisions from the section above are also your agent-access decisions. A narrow grant for a person is a narrow grant for their agents.

Open a repository at cursor.com/codebase and the Code tab is where you read it: browse files, search code and inspect commit history. The repository header carries Pull requests and Settings tabs alongside Code, and the green Code button opens HTTPS and Origin CLI clone setup from the same place.

It is a small page in the docs and it describes a small surface, which is fine; the browsing experience is not where Origin is trying to win. Two habits carry over from GitHub without translation: T for go-to-file, and switching the branch before opening history so you are reading the branch you think you are. What I have not seen documented yet is a cross-repository code search across a whole codebase, so for now assume search is scoped to the repo you have open.