Cursor Integrations: Slack, Linear, Jira, Notion, Xcode and Git Hosts

Start with the system that already owns the task. If work starts in Slack, Linear, Jira or Notion, route the agent from that conversation or issue. If the blocker is source access, connect the repository provider. If the work is native iOS, connect Xcode through MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. before you ask the agent to build or test.

The table reads top to bottom by where work starts, which is not the order you connect things in. Every intake row below ends in a Cloud Agent run, and you cannot finish Cloud Agent setup without a repository provider attached to it. For teams already on GitHub or GitLab, that step is behind them. If your code lives in Azure DevOps or Bitbucket, the repository-provider row is where you start.

Anything not in that table generally arrives through MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. instead, and the setup guide has the click path.

These integrations are intake surfaces. They let a team start an agent from the artifact that already describes the work: a Slack thread, a Linear issue, a Jira work item or a Notion page. That keeps the prompt close to the discussion, but it does not remove review. The agent still needs a clear repo, branch, model choice and merge gate.

Slack moved furthest of the four on 2026-07-17, and the changes are about steering rather than triggering. Cursor now replies with a plan before it begins, and updates its status as it works, so a wrong direction gets caught in the thread instead of in the diff. It can start in a named multi-repo environment rather than a single default repository, and when a task needs a repo outside that environment it offers a Switch repository button mid-task. And it can read from and post to other Slack channels and threads, pulling context from elsewhere in the workspace and posting updates back to the original thread or the relevant channel. Details in Cursor's Slack docs.

Notion comes with two prerequisites the Slack and Linear entries do not have. Cursor names a Business or Enterprise Notion plan, plus a GitHub connection on the Cursor side. The Microsoft Teams install, by contrast, will take any of the four repository providers. That is where the advice at the top of this page stops holding, since a team whose code lives only in Bitbucket can wire up Slack and Linear and still find Notion out of reach. The click path is in the setup guide.

How many intake surfaces to connect depends on team size, and for a small team the answer is one. A second surface mostly splits the record of what was asked: half the briefs in Linear, half in a Slack thread nobody can find a month later. Bigger orgs have a real reason for two, because support conversations live in Slack while roadmap work lives in Linear or Jira, and those are different people. What I would settle first is which surface counts as the record, then let the other link into it.

Repository-provider integrations decide where Cloud AgentsAgents that run in a Cursor-managed virtual machine, check out the repo, do the work and open a pull request, then shut down, with no load on your laptop. Press Enter for the full definition. and review tooling can actually operate. GitHub and GitLab are not the whole market; Azure DevOps and Bitbucket matter for teams whose code and pull requests already live there. Connect the host before promising cloud-agent work on those repositories.

The caption says to test the branch, PR and review path first, which is right and too vague to act on. Run one real task end to end on a repository nobody is waiting on, then read the pull request it opens rather than the agent's summary of it. A beta label mostly costs you certainty about where to look when a run fails, and the cheapest way to buy that back is to have the first failure somewhere quiet. Both hosts carry the label today, so this holds whichever one you connect.

Read the scope column closely if review tooling is why you are connecting. BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. Press Enter for the full definition. appears in the Bitbucket docs, and on GitHub and GitLab elsewhere, while the Azure DevOps row stops at Cloud AgentsAgents that run in a Cursor-managed virtual machine, check out the repo, do the work and open a pull request, then shut down, with no load on your laptop. Press Enter for the full definition.. Whether it reaches Azure DevOps I would not assume from a summary, so check the integration page first.

Because repository selection resolves from more than the sentence you typed. Defaults and message text both feed it, and some of those defaults were set by somebody else. Cursor documents the order for Microsoft Teams: explicit repo, branch and model options win, then repository or model names in the message text, then repositories you used recently, then the dashboard default.

Before touching any of that, open cursor.com/agents and check whether a run exists at all, because a mention that never started an agent is a different problem.

For Slack, the next place to look sits outside the thread. The team-level settings behind it show up in Cursor's Enterprise audit-log event types, which cover Slack default repo, default branch, default model, summary sharing (including sharing into external channels) and channel-to-repository mappings. An admin can change any of those, so a channel that keeps launching agents against the same wrong repo is more likely mapped that way than badly prompted. Check the mapping before rewriting the prompt again.

Xcode and Cursor BlameAn augmented git blame that records line-level human and agent co-authorship, so you can trace which code was written by AI versus a person. Press Enter for the full definition. solve different problems. Xcode gives the agent access to native build and test actions it cannot infer from code alone. Cursor Blame gives reviewers an authorship signal after code exists, so they can see where AI-assisted changes entered the history.

• Xcode: Xcode 26.3+ exposes a built-in MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. server. Cursor's agent can read and edit files, trigger builds, run tests, capture SwiftUI previews and search Apple documentation. The sidecar loop is in the mobile engineering guide.
• Cursor BlameAn augmented git blame that records line-level human and agent co-authorship, so you can trace which code was written by AI versus a person. Press Enter for the full definition.: extends git blame with AI-versus-human authorship signals, useful for review, debugging and compliance conversations.

Cursor writes Swift well already. What the bridge adds is everything after the writing, and the build logs that come back from Xcode carry more diagnostic detail than the same build run in a terminal. Without it the agent can still build from the terminal, on thinner output to iterate against. Setup is quick, and living with it is the part worth planning for, because Xcode asks you to allow the bridge connection when it launches, around five allows, and asks again the next time you open it. Every session, not just the first.

Cursor BlameAn augmented git blame that records line-level human and agent co-authorship, so you can trace which code was written by AI versus a person. Press Enter for the full definition. is worth turning on before anyone asks for it, because of what the audit log does not hold. The Enterprise audit log records security events and administrative actions, and prompts and generated code are not among them, so it cannot tell you which lines an agent wrote. Blame carries that at line level, with an API over the same signal if you want it in a dashboard.