Cursor as a Jira Cloud Agent: Jira comment triggers a merged GitHub PR Split-screen illustration. Left dark panel shows a Jira work item card for ticket ACME-447 with an @Cursor comment specifying repo and branch. Right light panel shows the resulting GitHub pull request opened by Cursor Agent, marked merged and linked back to ACME-447. An accent-blue arrow bridges the two panels at centre. JIRA CLOUD AGENT ACME-447 • Bug • Sprint 22 Fix login timeout on mobile COMMENT AK @Cursor repo=acme/backend branch=fix/login-timeout assigned to Cursor IN PROGRESS A Jira comment triggers the Cursor Cloud Agent to open a pull request automatically. GITHUB PULL REQUEST PULL REQUEST #214 fix: session timeout handling src/auth/session.ts Opened by Cursor Agent Merged Linked Jira ticket: ACME-447 Files changed: 1 • Additions: +47 • Deletions: -12 PR merged and linked back to ACME-447. Jira status updated automatically. How to Set Up Cursor in Jira as a Cloud Agent (May 2026) — pondero.ai
Guide intermediate

How to Set Up Cursor in Jira as a Cloud Agent (May 2026)

Published May 19, 2026 · by Pondero Editorial

The short version

Cursor shipped a native Jira integration on May 19, 2026. Assign work items to Cursor or drop @Cursor in a comment and the cloud agent reads the ticket, writes code, and opens a PR. This guide covers the full setup: Rovo requirement, Marketplace install, service account vs. user-level auth, and the @Cursor mention syntax.

Table of Contents

How to Set Up Cursor in Jira as a Cloud Agent (May 2026)

You can now assign a Jira ticket to Cursor and it opens a PR without you touching the IDE. That shipped May 19, 2026. The integration is a native cloud agent, not a plugin that surfaces ticket text in a chat sidebar. Cursor reads the work item, writes the code, and posts the PR link back in Jira. This guide walks through every step, including the two prerequisites that will stop you cold if you skip them.

What this integration does

Cursor's Jira integration runs inside the cloud agent system. The agent runs in a cloud sandbox, not your local IDE. It reads the full work item context, uses your connected repository, and pushes a branch with a PR. You get the result in Jira.

Assign work items to Cursor or mention @Cursor in a comment

Two ways to kick off an agent run. First: open the work item and set the assignee to Cursor, the same way you'd assign it to a teammate. Second: drop @Cursor anywhere in the comment thread on an open ticket. Both methods start the same underlying process.

The agent reads the ticket title, description, every comment, and your configured repository settings before writing a single line of code. That full context is what makes the native integration different from sending a decontextualized prompt to an AI assistant.

Once the agent finishes, the work item gets a completion update in the comment thread with a summary of what was done. If the task required code changes, that comment includes the PR link. You review the PR on GitHub or GitLab the same way you'd review any other contributor's work.

Progress updates post to the ticket while the agent runs, so you're not staring at a ticket that appears frozen.

You can also continue the conversation. Jira surfaces a Rovo chat panel on the work item; open it to push follow-up instructions to Cursor after the run completes.

For more on how Cursor's cloud sandboxes handle environment setup and secrets, see cloud agent environments in Cursor (May 2026).

What this is not: the Atlassian MCP server for IDE chat context

There's a separate piece of infrastructure called the Atlassian Rovo MCP server. It lets AI tools (Claude, Copilot, Cursor's own IDE chat) read and write Jira and Confluence data as context inside a chat session. It runs over OAuth 2.1 and supports JQL queries, issue reads, and page creation.

That's not what this guide covers. The Rovo MCP server feeds context into IDE chat. The native Cursor Jira integration executes code changes autonomously. Both can run simultaneously. The comparison section at the bottom covers when you'd want both.

What you need before you start

Skip this and you'll hit a wall partway through the Marketplace install flow. These are hard requirements.

Jira Commercial Cloud with Rovo enabled. The integration doesn't work on Jira Free, Jira Standard, or Jira Data Center. Rovo requires at least a Jira Premium or Enterprise plan on cloud. If your workspace shows a Rovo tab in project settings, you're good. If not, check your plan at admin.atlassian.com first.

Cursor admin access on your team. Team admin access is required to reach the integrations dashboard. Individual accounts can use the integration once set up, but setup itself needs admin.

GitHub or GitLab connected to Cursor. The cloud agent needs a repository to push to. Connect your repo provider first in the Cursor team settings under "Repository providers."

Usage-based billing turned on in Cursor. The integrations dashboard blocks cloud agent configuration until usage-based billing is enabled. Turn it on in Cursor billing settings before step 2.

Step 1 - Install from the Atlassian Marketplace

The install flow starts in Cursor, not in Jira.

Go to the Cursor integrations dashboard and click Connect next to Jira

Log in to Cursor as a team admin. Open the integrations dashboard (Settings > Integrations). Find the Jira row and click Connect. Cursor redirects you to the Atlassian Marketplace.

# Direct URL if you know your Cursor team slug
https://cursor.com/settings/integrations

Find the app on the Atlassian Marketplace and click Get it now

Search for "Cursor" in the Marketplace or follow the redirect link from the Cursor dashboard. Click "Get it now" on the Cursor for Jira app listing.

Select your Jira site, review permissions, and confirm

The Marketplace flow asks which of your Jira sites to install the app on. Pick the correct site, read through the permission list, and confirm. The permissions scope includes reading work items, posting comments, and accessing Rovo functionality.

What the configuration modal asks for

After install, clicking "Configure" in Jira opens a modal asking you to connect the Jira site to your Cursor team. Authenticate with your Cursor credentials. Once linked, Jira routes agent requests to your team.

The full install sequence looks like this:

1. Cursor integrations dashboard -> Click "Connect" next to Jira
2. Atlassian Marketplace -> Find "Cursor for Jira" -> Click "Get it now"
3. Select Jira site -> Review permissions -> Confirm install
4. Jira "Configure" modal -> Authenticate with Cursor credentials
5. Return to Cursor dashboard -> Complete cloud agent setup (Step 2)

Step 2 - Complete cloud agent setup

Back in the Cursor integrations dashboard, configure the cloud agent itself. This step is separate from the Marketplace install.

Connect your GitHub or GitLab repository if not already done

If you skipped the prereq, the dashboard surfaces the repo requirement here. Connect GitHub or GitLab under "Repository providers" before continuing.

Enable usage-based pricing

The configuration step checks for usage-based billing. If it's off, you'll see a prompt before you can proceed. Go to Cursor Billing, toggle on usage-based pricing, then return.

Set the default repository, model, and base branch

The configuration modal asks for three defaults that apply whenever Cursor runs a Jira task without explicit parameter overrides:

  • Default repository: the GitHub/GitLab repo the agent pushes to
  • Default model: the AI model used for code generation
  • Default base branch: the branch the agent branches from (typically main or develop)

These become the fallback for every ticket without explicit overrides. The auth mode section below explains when getting these wrong is costly.

Step 3 - Choose service account or user-level auth

Most teams pick the wrong mode here. Read both before deciding.

Service account: one team identity, shared settings, simpler setup

Every @Cursor invocation runs under a single team-level identity using the default repository, model, and base branch you set in step 2. One configuration, consistent behavior across the workspace.

User-level: each Jira commenter uses their own Cursor account

The @Cursor mention on a ticket routes the agent run through the Cursor account of whoever posted the comment. Their personal settings (default repo, model) drive the run.

When to pick each (solo dev vs. multi-engineer team)

Service account works when your whole team works in one repository with one branch strategy. One engineer or a monorepo shop where "route this to the standard place" covers nearly every case.

User-level works when engineers push to different repositories. In service account mode, every @Cursor call uses the default repo from step 2. If tickets span repositories, that default puts the agent in the wrong repo. User-level lets each engineer's @Cursor calls use their own Cursor account settings automatically.

Multi-repo teams with more than two developers should default to user-level.

How to switch modes after initial setup

Open the Jira integration settings in the Cursor integrations dashboard and toggle the auth mode. In-flight runs complete under the previous mode; new runs use the updated mode immediately.

Step 4 - Run your first agent task

Setup is done. This is the actual workflow.

Method 1: assign the work item to Cursor from the assignee field

Open any Jira work item. Click the assignee field. Select "Cursor" from the assignee list. That's the full trigger. The agent starts within seconds and posts its first update to the comment thread.

Method 2: drop @Cursor in a comment on any open ticket

Write a comment on the ticket and include @Cursor with your instructions. A minimal invocation:

@Cursor Please fix the timeout bug described above.

The agent reads the full ticket context plus your comment. You don't need to re-describe what's in the ticket description.

Override repo, branch, and model with @Cursor parameters

Add parameters inline to override the step 2 defaults. Full syntax:

@Cursor repo=acme/backend branch=fix/login-timeout model=gpt-5.5 Please fix the timeout bug described above. The relevant file is src/auth/session.ts

Parameters and what they do:

  • repo=acme/backend sets the GitHub/GitLab repository for this specific run, overriding the team default
  • branch=fix/login-timeout sets the base branch or target branch name for this run
  • model=gpt-5.5 selects the model for this run, overriding whatever default you set in step 2

All three parameters are optional. Use them when the default settings from step 2 don't fit the specific ticket.

What Jira shows while the agent works

The work item's comment thread shows progress updates as the agent runs. The assignee field shows Cursor as active. The run is asynchronous, so you don't need to keep the ticket open.

When the run completes, Cursor posts a final comment with a summary of what it did. If code changes were made, that comment includes the PR link. Open it on GitHub or GitLab and run your normal review.

If the agent couldn't complete the task (repository not found, ambiguous instructions, permission error), the completion comment says so with enough context to debug.

Cursor in Jira vs. connecting Jira to Cursor via MCP

The MCP approach to connecting Jira and Cursor involves running an Atlassian MCP server (or a community Docker-based variant) that surfaces Jira issue data inside Cursor's IDE chat as context. It reads tickets, pulls acceptance criteria, and answers JQL queries while you write code. The Rovo MCP server works over OAuth 2.1 and supports reads and writes across Jira, Confluence, and Compass. It doesn't write and ship code autonomously. The native Cursor Jira integration is the cloud agent path: hand off the ticket, the agent works without an IDE session, posts a PR when done. Both can run in the same workspace; they serve different moments.

FAQ

Does Cursor in Jira work with HIPAA or FedRAMP Jira instances?

No. HIPAA, FedRAMP, and Government Cloud Jira instances are not supported per Cursor's docs. The integration requires standard Jira Commercial Cloud with Rovo enabled.

What Jira plan includes Rovo?

Rovo is available on Jira Premium and Enterprise cloud plans. Check your plan at admin.atlassian.com. Standard plan customers need to upgrade before the integration's install flow will complete.

What happens if the agent can't find the repository?

Cursor posts a completion comment explaining the failure. The most common cause is a mismatch between the default repository in step 2 and the actual repo name on GitHub/GitLab. Verify the slug format (org/repo-name) in the Cursor integrations dashboard.

Can I limit which repositories the Cursor agent can touch?

The agent's access is scoped to your connected GitHub or GitLab account. To restrict it, adjust the OAuth app permissions on the GitHub/GitLab side to limit which repos the Cursor app can reach.

What model does the Cursor Jira agent use by default?

Whatever you set in the cloud agent configuration in step 2. Override it per-ticket with the model= parameter in an @Cursor comment. The integrations dashboard lets you update the team default at any time.

How do I check the agent's session log or debug a failed run?

Cursor posts a summary to the Jira ticket on completion or failure. For deeper inspection, open the Cursor automations dashboard and find the run log for that session. It shows each step the agent took, including file reads, code edits, and errors.

Getting started

If you're building with Cursor and your team runs Jira Commercial Cloud on a Premium or Enterprise plan, the setup takes about ten minutes once Rovo is confirmed. The real decision is auth mode: user-level wins for any team with more than two repositories.

Claude Code handles IDE-external task execution differently. See Claude Code plugins and the Marketplace (May 2026) for a side-by-side of how the two ecosystems compare.