Cursor Release Notes

We've expanded team marketplaces to support Team MCPs and organization groups.

Admins can now configure Team MCP servers once and distribute them across cloud agents, the agents window, IDE, and CLI.

When an admin sets up Team MCP servers for cloud agents, they can make those same servers available in a team marketplace from Dashboard -> Integrations & MCP. This allows members of the team to install approved integrations locally without configuring servers themselves.

Learn more in the docs on migrating existing Team MCPs.

Team marketplaces now support organization groups, in addition to team-level SCIM directory groups.

Under Dashboard -> Plugins -> Team Marketplaces, restrict marketplace access to specific organization groups. Marketplaces that already use SCIM directory groups keep that configuration.

Get started in the Cursor dashboard.

Cursor is now available as a native iOS app in public beta, so you can build from anywhere.

Until now, developers have worked around the limits of their local machines, keeping laptops half-open and caffeinated everywhere they go.

With Cursor for iOS, you can launch always-on agents in the cloud, or control agents running on your computer from your phone. Kick them off when ideas strike, get notified when work is ready for review, and merge PRs on the go.

Whether your agents are running on your machine or in the cloud, you can move work forward from wherever you are.

Get Cursor for iOS

Launch and track agents from anywhere

Whether you're catching a flight, cooking a meal, or in between sets at the gym, you can now act on moments of inspiration or curiosity.

Open the Cursor mobile app, choose a repo, and launch an agent the same way you would on the desktop app. You can pick any frontier model, describe ideas out loud with voice input, and use slash commands to guide Cursor in the right direction.

For agents running on your computer, use Remote Control to continue directing them from your phone. To ensure your machine remains reachable while you're away from your desk, you can enable a setting that keeps your computer awake.

New ways of working from your phone

At Cursor, we use the mobile app for everything from small, well-scoped tasks to long-running projects. It has enabled new workflows for our team and early testers:

• Handling incidents while on call: When you get paged at lunch, you can kick off an agent to investigate and propose a fix. By the time you get back to your computer, you'll have a PR ready for review.
• Resolving customer issues: If a customer reports a time-sensitive bug while you're away from your desk, you can start an agent from your phone to reproduce the issue, inspect the relevant code, and work toward a fix.
• Acting on feedback from other mobile apps: When you see user feedback on X or other platforms, take a screenshot, annotate it, and send it to an agent as visual context. This is often the fastest way to start design or UI changes.

Stay in the loop

Once an agent starts, you can leave the app. Cursor keeps you updated with Live Activities on your lock screen and push notifications when an agent finishes, needs input, or is ready for review.

Beyond code, cloud agents produce demos, screenshots, and logs that make it easy to validate their work. When an agent is done, you can review these generated artifacts, inspect diffs, leave follow-up instructions, or merge the PR directly from the app.

Handoff between local and cloud

Cloud agents run in isolated virtual machines with full development environments to test, verify, and demo work. Since they operate asynchronously with their own tools and resources, cloud agents can run for longer and iterate toward merge-ready PRs without intervention.

To take advantage of these capabilities, send a local plan to a cloud agent or move active agents to the cloud to keep running. You can move the cloud session back to your computer to test changes locally before merging.

What's next

Over time, the experience of running agents in the cloud will become indistinguishable from running them on your local machine. Until then, we want to make it easy to work with agents across both environments with Remote Control and fluid handoffs between local and cloud.

We are also working on adding the ability to create repo-less chats to make it easier to kick off tasks that don't require codebase context. Teams are already using Cursor today with MCPs to query Datadog logs, summarize activity across Slack channels, and more.

Cursor for iOS is available now in public beta on all paid plans. Get 75% off on Composer 2.5 runs in the mobile app now through July 5, 2026.

Download for iOS to start building from your phone, or read the docs to learn more.

Cursor for iOS is now available in public beta on all paid plans. Launch and manage always-on agents from anywhere.

Cloud agents on mobile

Open the Cursor mobile app, choose a repo, and launch an agent the same way you would on the desktop app. Pick any frontier model, describe ideas out loud with voice input, and use slash commands to guide Cursor in the right direction.

Cloud agents run in isolated virtual machines with full development environments to test, verify, and demo work. Move sessions from local to cloud to keep them running with your laptop closed.

Remote Control

Use Remote Control to take an agent you're running on your computer and keep directing it from your phone.

You can also turn on a setting to keep your computer awake, so your machine stays reachable while you're away from your desk.

On Teams and Enterprise plans, admins must enable Remote Control from the Cursor Dashboard.

Live Activities and push notifications

Track the status of your agents with Live Activities on your lock screen. Get push notifications when an agent finishes, needs input, or is ready for review.

Artifacts and SCM

Review demos, screenshots, logs, and diffs from your phone. Leave follow-up instructions, or merge the PR directly from the app.

Download Cursor for iOS to start building from your phone. Read our announcement or the docs to learn more.

Plugins, skills, and MCPs

Plugins, skills, and MCPs let you customize Cursor for your workflows. The new Customize page brings them into one place.

You can now add and manage plugins, skills, MCPs, subagents, rules, commands, and hooks at the user, team, or workspace level, and even bring your own custom MCPs.

Marketplace leaderboard

Cursor now shows you a leaderboard of the most popular plugins, skills, and MCPs across your team.

Add any to your setup with one click from the new Customize page and extend Cursor for your workflow.

Plugin canvases

Plugins now support prebuilt canvases: shared setup templates your team can open and reuse.

Use the Hex Canvas to build data visualizations.

Use the Atlassian Canvas to see a realtime view of all our issues, projects, and documents.

New Team Marketplaces

Team marketplaces now support imports of plugin repositories from GitLab, BitBucket, or Azure DevOps so you easily add plugins and distribute them to your team.

Learn more in our docs.

Take a first pass at addressing inline review comments on PR diffs

You address inline PR review comments with a first-pass fix.

Goal

When a reviewer leaves an inline comment on the diff, attempt a minimal fix and respond on the thread.

Process

1. Read the triggering inline comment from the payload (author, comment body, comment URL, PR number).
2. Use the comment URL or gh to fetch the file path and line if needed.
3. Understand the requested change — bug, style, missing case, naming, etc.
4. Inspect the surrounding code and make the smallest correct fix.
5. Commit and push to the existing PR branch. Do not open a new PR.
6. Reply on the review thread with what you changed. Resolve the thread if the comment is fully addressed.

Rules

• Only change code required by the comment. Match existing patterns.
• If the comment is unclear, a design question, or needs human judgment, reply explaining what is ambiguous — do not guess.
• If you cannot fix confidently, say why and what you'd need to proceed.
• Do not approve the PR. Do not address unrelated comments.

Cursor Automations save you time by automating repetitive tasks with always-on agents. This release introduces the /automate skill, new triggers for GitHub and Slack, and support for computer use.

/use /automate to create an automation directly in your local agent session.
Describe the task you want to automate in plain language and Cursor will configure the triggers, instructions, and tools for you.

An emoji trigger for Slack

React to any Slack message with a designated emoji to kick off an automation. At Cursor, we use this to trigger specific automations right from Slack.

New GitHub triggers

Automations now support five additional GitHub triggers:

• Issue comment: when a comment is made on a non-PR issue
• PR review comment: when an inline comment is left on a pull request diff
• PR review submitted: when a PR review is submitted
• Review thread updated: when a review thread on a pull request is marked resolved or unresolved
• Workflow run completed: when a GitHub Actions workflow run finishes on a pull request or branch

We've added new templates for triaging failed GitHub actions and auto-fixing PR review comments to the Cursor Marketplace to help you get started.

Computer use tool for automations

Cloud agents kicked off by automations can now use their own computers to produce demos or artifacts of their work.
The computer use tool is enabled by default for every automation, just tell the agent to include a demo of its work in your instructions.

To get started, update to the latest version of Cursor. Learn more in our docs.

Cursor Automations save you time by automating repetitive tasks with always-on agents. This release introduces the /automate skill, new triggers for GitHub and Slack, and support for computer use.

/automate skill

Use /automate to create an automation directly in your local agent session.
Describe the task you want to automate in plain language and Cursor will configure the triggers, instructions, and tools for you.

An emoji trigger for Slack

React to any Slack message with a designated emoji to kick off an automation. At Cursor, we use this to trigger specific automations right from Slack.

New GitHub triggers

Automations now support five additional GitHub triggers:

• Issue comment: when a comment is made on a non-PR issue
• PR review comment: when an inline comment is left on a pull request diff
• PR review submitted: when a PR review is submitted
• Review thread updated: when a review thread on a pull request is marked resolved or unresolved
• Workflow run completed: when a GitHub Actions workflow run finishes on a pull request or branch

We've added new templates for triaging failed GitHub actions and auto-fixing PR review comments to the Cursor Marketplace to help you get started.

Computer use tool for automations

Cloud agents kicked off by automations can now use their own computers to produce demos or artifacts of their work.
The computer use tool is enabled by default for every automation, just tell the agent to include a demo of its work in your instructions.
To get started, update to the latest version of Cursor. Learn more in our docs.

Cloud environment setup

Cursor can now help you set up your dev environment in the cloud in less than 10 minutes. You can watch the agent's progress in a shared terminal session as it handles setup tasks like installing dependencies.

Your environment is captured in a reusable snapshot, so future cloud agents start up faster with the ability to test changes by running your software. It can iterate over long time horizons until outputs are verified. This benefits your entire team when committed to .cursor/environment.json.

Cloud subagents with /in-cloud

Use /in-cloud to spin up a cloud subagent in its own VM to work on the next task you submit. It runs on its own VM and branch, so your local workspace stays clean and responsive.

This is especially useful for isolating long-running or parallel work like fixing CI, investigating an issue, or exploring a codebase while you keep working locally.

You can also ask a cloud subagent to babysit a PR by clicking on the quick-action pill or using /babysit. The cloud agent will iterate remotely to prepare your PR for merge without tying up the local session.

The cloud subagent can run in the background without interrupting the parent agent, which can continue to run locally or in the cloud.

Handoff between local and cloud

Move agent sessions more reliably between your local computer and the cloud. You can offload long-running work from your machine and run as many cloud agents in parallel as you want. Pull a cloud agent back down to local to test changes yourself.

This release introduces updates to cloud agents in the Agents Window of the Cursor desktop app.

Cloud environment setup

Cursor can now help you set up your dev environment in the cloud in less than 10 minutes. You can watch the agent's progress in a shared terminal session as it handles setup tasks like installing dependencies.

Your environment is captured in a reusable snapshot, so future cloud agents start up faster with the ability to test changes by running your software. It can iterate over long time horizons until outputs are verified. This benefits your entire team when committed to .cursor/environment.json.

Cloud subagents with /in-cloud

Use /in-cloud to spin up a cloud subagent in its own VM to work on the next task you submit. It runs on its own VM and branch, so your local workspace stays clean and responsive.

This is especially useful for isolating long-running or parallel work like fixing CI, investigating an issue, or exploring a codebase while you keep working locally.

You can also ask a cloud subagent to babysit a PR by clicking on the quick-action pill or using /babysit. The cloud agent will iterate remotely to prepare your PR for merge without tying up the local session.

The cloud subagent can run in the background without interrupting the parent agent, which can continue to run locally or in the cloud.

Handoff between local and cloud

Move agent sessions more reliably between your local computer and the cloud. You can offload long-running work from your machine and run as many cloud agents in parallel as you want. Pull a cloud agent back down to local to test changes yourself.

To be their most productive for coding and other tasks, agents need a healthy level of autonomy.

That means they should be able to operate independently, be creative, and accomplish work without stopping too often to ask for permission.

However, greater autonomy introduces security risks if agents take unintended actions. This is especially true for local agents, which often run near files, credentials, environment variables, MCP tools, and have access to production systems.

The easy answer is to ask the user before any action happens, but asking for permission too often creates its own safety problem. After enough repeated prompts, people stop reading carefully, and the approval flow becomes less meaningful.

This week we launched Auto-review, which makes decisions around agent autonomy behave more like a dial than a switch. The core idea is that an agent should be able to move freely when the stakes are low, but slow down when its next action crosses a meaningful boundary.

We determine where an action sits along that continuum with a specialized classifier agent that reviews actions in context before they run. Building it meant turning our intuition for how agent autonomy should be governed into a working model of consequence, intent, and feedback that we could test against real agent behavior.

Whether an agent action poses risk depends on the situation. The same command can be harmless in one workflow and unacceptable in another. What matters is the relationship between the action, the user's request, and the consequence of being wrong.

That recognition pushed us toward developing a "classifier" agent that would govern overall agent autonomy. We wanted it to be a small model, so that it stayed fast and inexpensive to run, while still making a nuanced judgment about whether the next action was consistent with the user's intent.

The central rule we gave the classifier was that it should be more lenient when the security stakes are lower, and more cautious when they're higher. With that broad understanding in place, we began building the classifier as a fast, contextual reviewer that could sit directly in the agent's execution path.

The first technical decision was model choice. The classifier runs before a tool call executes, so it sits directly in the agent loop and needs to be fast as well as accurate. Being a multi-model company helped here because we could try a wide range of models and reasoning modes, then choose the one that sat at the right point between speed and judgment.

One early surprise was that lower-reasoning models were not always faster. When a model struggled to understand the policy or the tool call, it could spend more time and tokens searching for what ultimately became a worse answer. The better trade-off was a small model with enough reasoning to make the decision cleanly.

We also made the classifier agentic, because some actions cannot be judged from the command alone. A command like

python script.py

might be safe or unsafe depending on what is inside the file, so the classifier can inspect the workspace with tools like ReadFile, Grep, Glob, and ListDir before deciding.

We avoided a separate classification endpoint, because an extra round trip would add latency directly before every reviewed tool call. Instead, the classifier runs in the same RPC stream as the parent agent, using an architecture similar to subagents.

The next decision was what a block should do. We did not want the classifier to become another approval prompt generator. When it blocks an action, it returns an explanation to the parent agent, and the parent agent can often use that feedback to choose a safer path without interrupting the user.

User intent is what makes that feedback useful. The question is not whether an action looks risky in isolation. The question is whether the action is justified by what the user asked the agent to do. That is what lets normal development work keep moving while higher-consequence actions require a clearer signal from the user.

That design only works if the classifier is tuned against the actions it should let through and the ones it should stop, so we needed evals that covered both.

Our first set of evals came from internal usage data to understand the normal shape of agent work. The classifier had to catch risky actions without blocking routine development work, and internal sessions were the best way to see that baseline. We started with roughly 12 hours of internal developer sessions, then cut that down and deduplicated common actions into 6,122 labeled rows.

We also needed synthetic data, because the worst cases do not appear often enough in normal usage. We generated cases where the agent might read secrets, touch production data, follow untrusted instructions, or take actions with large side effects. Those examples gave us coverage for the failures we most wanted the classifier to catch.

The policy changed as we learned, which made the data work more complicated. When we changed the categories of behavior the classifier should recognize, we had to relabel or rematerialize the eval set. Otherwise, we would be testing the current classifier against an outdated understanding of the problem.

We ran the evals through the same backend classifier loop used in production. That let us test the full path, including tool use, final classification, model overrides, and parse failures. The evals checked the final allow or block decision, along with the context the classifier used when it needed to inspect the workspace before deciding.

We also looked for flapping. If the same case allowed six times and blocked four times, that usually meant the policy or prompt was underspecified. Repeated runs gave us a way to find those unstable cases and tighten the classifier until its behavior was more consistent.

In practice, only a small share of agent actions need to be reviewed by the classifier. Many commands are already covered by allowlists or sandboxing, so the classifier mostly runs when the action needs contextual judgment.

When the classifier does run, it currently blocks around 4% of actions, though a block does not immediately become a user prompt. The classifier sends an explanation back to the parent agent, which can often narrow the action, choose a different tool, or avoid the risky step entirely.

Some blocks from the classifier become user interruptions, but globally we're seeing that only about 7% of total chats in Auto-review mode lead to at least one interruption. To put that in perspective, some enterprise customers we're working with previously saw roughly 40% of actions blocked within their organization.

This early data is consistent with the main product behavior we wanted. The classifier rarely interrupts the user directly, and in most blocked cases the parent agent can use the feedback to continue in a safer, narrower way.

Auto-review is still early, and our understanding of the autonomy continuum will keep changing as agents become more capable. Today, it is focused on local agents in the desktop app, and we expect the same ideas to shape how we govern agent autonomy in more places over time.

We want agents to have real autonomy, while making the decision to slow them down depend on context rather than a single global permission setting. The classifier lets us improve safety without turning autonomy back into a stream of approval prompts. It catches actions that need more scrutiny, gives the parent agent feedback, and lets the agent keep working when there is a safer way to proceed.

Auto-review is now the default for new users. For existing users, you can enable it in Settings > Agents.

The average review time for Bugbot is now ~90 seconds, down from ~5 minutes. Bugbot also finds 10% more bugs per review on average 1.62, up from 0.56 and costs ~22% less per run.

These performance gains are made possible by progress we've made training Composer 2.5, which now powers Bugbot. Bugbot respects model block lists, and speed and performance can vary depending on your configuration.

Run Bugbot before you push

You can now run Bugbot and Security Review with /review before pushing code. /review prompts you to choose which agents to run, or use /review-bugbot and /review-security directly.

/review also syncs with Bugbot on GitHub and GitLab. If you run /review and then open a PR with the same diff, Bugbot recognizes it, skips the review, and leaves a comment noting it has already reviewed that diff.

Available in Cursor 3.7+ and on cursor.com/agents, with support in CLI coming soon.

Only review what's new in your PR

You can now configure Bugbot to only review what's new since the last review, keeping feedback focused on your latest updates.

Learn more in our docs.

Today we're shipping our biggest set of improvements yet to Bugbot.

Bugbot is now over 3x faster to run, 22% cheaper, and finds 10% more bugs per review. In practice, 90% of Bugbot runs now finish in under three minutes.

A faster, less expensive, more thorough Bugbot allows you to find issues sooner and merge code faster.

Run Bugbot before you push

You can now run Bugbot and Security Review with /review before pushing code. /review prompts you to choose which agents to run, or use /review-bugbot and /review-security directly.

This is a great way to catch and fix issues before pushing the code. /review also syncs with Bugbot on GitHub and GitLab. If you run /review and then open a PR with the same diff, Bugbot recognizes it, skips the review, and leaves a comment noting it has already reviewed that diff.

Available in Cursor 3.7+ and on cursor.com/agents, with support in CLI coming soon.

Only review what's new in your PR

Bugbot by default re-reviews the entire PR every time a change is pushed. This can result in new flags on code it had already reviewed and approved. You can now configure Bugbot to only review what's new since the last review, keeping feedback focused on your latest updates.

How we got here

These performance gains are made possible by harness improvements and progress we've made training Composer 2.5, which now powers Bugbot. Our model training work is one part of how we will continue to improve Bugbot over time.

Bugbot respects model block lists. If your organization has opted out of Composer 2.5, Bugbot will automatically fall back to the next best available model. Speed and performance can vary depending on your configuration.

Learn more

Try Bugbot here and read the Bugbot docs to learn more.

The average review time for Bugbot is now ~90 seconds, down from ~5 minutes. Bugbot also finds 10% more bugs per review on average — 0.62, up from 0.56 — and costs ~22% less per run.

These performance gains are made possible by progress we've made training Composer 2.5, which now powers Bugbot. Bugbot respects model block lists, and speed and performance can vary depending on your configuration.

Run Bugbot before you push

You can now run Bugbot and Security Review with /review before pushing code. /review prompts you to choose which agents to run, or use /review-bugbot and /review-security directly.

/review also syncs with Bugbot on GitHub and GitLab. If you run /review and then open a PR with the same diff, Bugbot recognizes it, skips the review, and leaves a comment noting it has already reviewed that diff.

Available in Cursor 3.7+ and on cursor.com/agents , with support in CLI coming soon.

Only review what's new in your PR

You can now configure Bugbot to only review what's new since the last review, keeping feedback focused on your latest updates.

Learn more in our docs.

With Design Mode in the Cursor browser, you can click, draw, or describe changes by voice to help agents update your UI.

Multi-select elements

Click on two or more elements together in the browser. Cursor sees the selected elements, their code, the surrounding layout, and the visual relationships on the page.

Ask the agent to make one match the other, remove repeated content, or adjust a group of components at once.

Voice input

Narrate changes through the Design Mode overlay. The mic stays available while an agent is mid-run, so you can queue the next change by voice without waiting for the previous one to finish.

With Design Mode in the Cursor browser, you can click, draw, or describe changes by voice to help agents update your UI.

Multi-select elements

Click on two or more elements together in the browser. Cursor sees the selected elements, their code, the surrounding layout, and the visual relationships on the page.

Ask the agent to make one match the other, remove repeated content, or adjust a group of components at once.

Voice input

Narrate changes through the Design Mode overlay. The mic stays available while an agent is mid-run, so you can queue the next change by voice without waiting for the previous one to finish.