Enterprise Jenkins now builds from Cursor Origin

The Cursor Origin Branch Source plugin (beta, MIT-licensed, contributed upstream by CloudBees) lets Jenkins discover Cursor Origin repositories, build branches and pull requests, and report check results back to Origin. It authenticates with signed app keys instead of personal access tokens and requires Jenkins 2.568.1 or newer. Install it from the Jenkins Update Center.

The first agentic-forge plugin to Jenkins

Jenkins has long been open and extensible, letting teams adapt it to their software delivery needs while allowing developers to use the forge of their choice. Connecting established forges like GitHub, GitLab, and Bitbucket is already well supported through plugins. Forges built for AI coding agents raise a new question: how your platform team integrates the first one will shape how it integrates the rest?

The latest agentic forge, Cursor Origin was announced in June 2026 and opened early beta in August. Cursor describes it as a git forge for the agentic era, designed for the volume of changes AI agents generate. It offers repositories browsable at cursor.com/codebase, standard git push and pull, pull requests with code review, a public API, and support for Cursor's cloud agents working directly against Origin repositories.

Many enterprises rely on Jenkins to build their code. Our mission is to support them on their journey of modernizing their estate as new emerging technology and best practices emerge. For this reason, we contributed the branch source to the Jenkins project - under the same jenkinsci org where the Pipeline and Checks API plugins have been shared in the past. 

The policy set for the first agentic forge sets the pattern for the rest

Say no to Origin and developers work around you or leave. Say yes without a plan, and the pipelines you spent years stabilizing become a quarter of rework. Neither answer works when the forges keep arriving.

Cursor Origin is the first agent-era forge with a Jenkins branch source in the update center. The pattern your platform team sets for it becomes the pattern for the next five.

The decisions that become the pattern

Every platform team makes these when a new forge lands:

1. Who gets to trial it, on which repos? Sanctioned pilot, or the eager developer on their side project?
2. How to connect it to your CI? A vendor’s proprietary connector, community plugin or a homegrown script mean different investments and maintenance commitments. 
3. What authentication model is standard? App-signed keys the platform can rotate, or personal access tokens pasted into job config?
4. What evidence signals it is production-ready? Should CI checks land on the PR before promoting anything else? Must the evidence be attached? Should it meet security’s audit standards? 
5. How agent-authored commits get treated when they reach your CI? Same as human-authored, or logged separately, or held to a different review bar?

In many cases, the above decisions don't get written into policy the first time. They get made in Slack, in a Jira ticket, in a pull request from the platform lead. Then they become muscle memory and get replayed for the next forge.

Spending time thinking through this now prevents:

• Building a proprietary connector. You build one for Origin, then five more. Each unauditable by security. Each vendor lock. Each person's maintenance debt.
• Rewriting pipelines. Every new forge burns a quarter of platform work. In 18 months your platform team is not building, it is porting.
• Policy drift. By the third forge, developers stop asking. Your platform team is out of the loop on where the code lives.

Cursor Origin is one of the first agent-era forges your platform team will have to integrate, but it will not be the only one. Google Antigravity, Amazon Kiro, GitHub Copilot Workspace, Anthropic if they build one, plus whatever Replit / Cognition / Factory / smaller players ship - each one raises the same five questions again. The platform team that already answered them for Origin doesn't have to answer from scratch.

What you can now do with Jenkins and Cursor

• Multibranch Pipelines and Organization Folders. Pick Cursor Origin as the branch source for a single repository, or as the repository source for a whole codebase namespace. Jenkins discovers what is there and creates and removes jobs as branches and pull requests come and go.
• Branch and pull request discovery traits. The standard Jenkins traits model, so you configure discovery the way you already do elsewhere. One difference from GitHub worth knowing: Origin has no fork concept, so pull requests come from branches inside the same repository.
• App authentication with a signing key. You create a Cursor Origin App, upload its public key to Origin, and store the private key as a Cursor Origin App credential in Jenkins. Jenkins signs its API calls with that key, no personal access tokens pasted into job configuration. Install the app across an entire codebase or scope it to selected repositories.
• Checks on Origin pull requests. The plugin implements the Jenkins Checks API, so every build reports its status back to Origin, and carries real detail with it: test failures from the JUnit plugin, line annotations from Warnings Next Generation, and anything else that publishes through the Checks API.
• Webhook-triggered builds. A single endpoint at /cursor-origin-webhook/ receives these events from Origin: repository created, deleted and pushed, pull request lifecycle, check runs, and verifies their signatures before acting. Push a commit and the right job starts. No polling.

Under the hood, the Origin API client is generated from Cursor's published OpenAPI specification rather than hand-rolled, which keeps the plugin honest as the service evolves. The plugin requires Jenkins 2.568.1 or newer.

Cursor Origin Branch Source Plugin (Beta):

Origin is in early beta on Cursor's Pro, Teams, and Enterprise plans. The plugin's README content calls out: Origin service changes may break this plugin at any time. It ships under a 0.x version. We recommend you trial it on a real repository where a broken build is causing issues, not an incident. We recommend not putting it in front of the production release train yet. When it breaks, file the issue on the repo.

Try it, then tell us what breaks

If your team has Origin access:

1. Install Cursor Origin Branch Source (beta) from the Jenkins update center, on Jenkins 2.568.1 or newer.
2. Create a Cursor Origin App in Origin's app settings. Grant it read access to repository contents and pull requests, plus permission to create and update check suites and runs. Subscribe it to the repository, pull request, and check run events, and point its webhook at https://your.jenkins.url/cursor-origin-webhook/.
3. Generate a signing keypair, upload the public key to the app, and paste the private key into a new Cursor Origin App credential in Jenkins. Install the app on the repositories you want Jenkins to see.
4. Create a Multibranch Pipeline or Organization Folder, pick Cursor Origin as the source, and select your app credentials.
5. Push a commit. Watch the run start, then watch the check land back on the pull request.

The README covers the exact permission and event names. Issues, pull requests, and blunt feedback all go to the repository: github.com/jenkinsci/cursor-origin-branch-source-plugin.

The forges will keep changing. Your pipelines should not have to.

‍