Cursor Release Notes

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.

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.

Custom tools

You can now hand the local agent your own tools by passing function definitions through local.customTools, on Agent.create() or per send(). The SDK exposes them to the agent through a built-in MCP server called custom-user-tools, so the model calls your code through the same path and the same permission gate as any other MCP tool.

Before this, exposing a custom capability meant standing up your own stdio or remote HTTP MCP server and wiring it into the agent. Now a function definition is enough. Custom tools are also visible to every subagent of a parent agent, so a tool you define once is available throughout the whole run.

Auto-review

By default, a local SDK agent runs tool calls without asking for approval, since there's no human in the loop in a headless run. Set local.autoReview to route those calls through auto-review instead. A classifier decides which calls run automatically and which to hold back, rather than bypassing review entirely.

You steer that classifier with natural-language instructions in permissions.json. The autoRun.allow_instructions field describes call shapes to lean toward allowing, and autoRun.block_instructions describes the ones to hold for review. For example, you can allow read-only inspections of build artifacts while always pausing on destructive operations like deletes.

JSONL and custom stores

Both SDKs persist agent and run metadata so you can resume an agent after a process restart. Until now, that store was SQLite. You can now opt into a JSONL store instead, which writes a plain, append-only file you can read, diff, and check into version control. Both SqliteLocalAgentStore and JsonlLocalAgentStore are exported directly.

If neither default fits your setup, implement the public LocalAgentStore interface and pass it through local.store. Build an in-memory store for ephemeral CI runs, or back persistence with Postgres when you want agent state to live next to the rest of your application data. The Python SDK exposes host, JSONL, and composed JSONL stores through the bridge.

Nested subagents

Subagents can now spawn their own subagents, and so on. A reviewer subagent can delegate to a test-writer, which can delegate further, with each level keeping its own prompt and model. There's nothing to turn on; a subagent session registers the executor it needs to call Task, so nesting works automatically for any agent that defines subagents.

Reliability, performance, and platform improvements

This release also includes a batch of quality-of-life fixes across both SDKs.

Run npm install @cursor/sdk or pip install cursor-sdk to upgrade. Scripts pinning composer-2 move to Composer 2.5 automatically, and requestId is a safe addition to your run metadata schema. See the TypeScript and Python docs for full details.

Point, draw, or narrate the change

Chat is one interface for working with agents, but UI work tends to be spatial. Designers, PMs, and frontend developers often communicate through annotations that point to elements, regions, or the state of the page.

Design Mode, which we're updating today, is part of how we're shrinking the distance between what you see and what the agent understands. It lets you edit your product in context while staying in flow.

From the Cursor browser, you can click any element, draw on the page, or describe the change by voice, and Cursor gets the context it needs to edit the code while you move on to the next edit.

It is a faster, easier way to iterate on design changes with agents because the instruction is no longer just a sentence—instead it can include the selected element, the code behind it, the surrounding layout, and the visual relationships on the page.

This makes the loop between noticing and editing tighter. You can point at the part of the interface you mean without leaving the running product, then keep making references against the product itself while agents make the edits underneath.

Design Mode provides several ways for you to convey intent to the agent. You can select an element, add multiple references, draw over the interface, or use your voice to describe the change.

Click an element in the running app, prompt against that selected element, and let the agent edit the code.

Multi-select is useful when the change depends on a relationship between elements. You can reference two components and ask the agent to make one match the other, remove repeated content, or adjust a group of components together.

Select multiple elements and describe how they should change together.

Drawing is useful when the agent needs to know what area of the page the instruction applies to. You can circle a crowded section, box in a region, or mark part of an animated page. The annotation sits over a frozen frame of the viewport, so the agent sees the exact page state you were responding to.

In this release, you can also narrate instructions using your voice, and we've made targeting more precise and the experience faster. Altogether, this makes visual interactions in Design Mode feel more like part of a normal editing loop.

Use voice input and drawing together to describe a change.

Under the hood, picking an element adds two complementary signals into context: the element's identity (xpath, the component, attributes, computed styles, props from the fiber tree) and a screenshot for spatial context (layout, surrounding elements, and the exact page state). This gives the agent exactly what it needs to find the source and edit the code efficiently.

Matching the model to the rhythm of the work

When you are refining a user interface, one chain of edits usually leads to the next. You adjust a component, notice the spacing around it, then see how another component should match.

Design Mode lets you send those edits away as you notice them. You can point at one element, describe the change, move to another part of the page, and send another edit before the first one has finished. Design Mode allows you to multitask more easily and makes managing multiple subagents possible.

This flow works best with a model that can make targeted UI changes quickly.

Composer 2.5 excels at this because it is both fast and strong at interface work. As agents finish, the app hot reloads. You see the changes appear in the running product and keep going until the interface feels right.

We believe the future of building software lets users move seamlessly between higher levels of abstraction and lower-level details while working in flow state when they want to. Design Mode provides users with the control, agency, and precision editing tools that make that possible.

Try Design Mode in the Agents Window. Read the Browser docs to learn more, or download Cursor to get started.

With canvases, agents can create interactive artifacts like dashboards, reports, and internal tools that you can share with your team.

This release introduces Design Mode for faster canvas editing, new ways to understand context usage, and other quality-of-life improvements.

Design Mode in canvases

Design Mode is now available in canvases.

Select and annotate UI elements directly in a canvas to guide Cursor's edits, just as you would in the browser. Instead of describing the change in text, you can point to it, provide feedback, and iterate more quickly.

Context usage report in canvas

Cursor can now show your agent's context usage as an interactive report in a canvas.

The context explorer breaks down where tokens go across the system prompt, tool definitions, rules, skills, and more. Because it's a canvas, you can ask the agent follow-up questions, and it can customize the report to answer your specific questions.

Click the Debug with Agent button embedded in the canvas to ask Cursor to identify opportunities to reduce context usage in a new conversation.

Canvas Improvements (4)

Enterprise customers can now manage multiple Cursor teams from one place, with different security, governance, budget, and feature controls for each. These capabilities are now generally available to all Enterprise customers.

Organizations

An organization is the top-level container for your company's identity, administration, and membership. It gives admins one place to view and manage their entire Cursor setup, including a rollup of spend and token usage across every team.

Teams

Teams are the operating unit for a department, region, or subsidiary. This is what admins manage as their Cursor org today. We've moved that unit under an organization, so you can run multiple teams, each with its own security, governance, spend, and feature settings.

A user can belong to more than one team, with a different role in each. For current customers, your existing team is preserved and becomes the default home for login, routing, and creating new teams.

Groups

Groups are a lightweight collection of users that can sit across or within teams. They give cohorts of users separate model access, spend limits, and agent permissions without standing up a whole new team. When a user belongs to more than one team or group, the most permissive setting wins.

Learn more in our announcement post or docs.

How the structure works

Large enterprises are often made up of many business units, subsidiaries, and functions. We frequently hear from customers that each of these units needs its own budget, security, governance, and feature controls.

To support these requirements, we’re introducing organizations, a new structure that allows enterprises to manage multiple Cursor teams from one place. With it, admins can set separate budgets for different teams, enable different models for different cohorts of users, create sandbox environments to test new features, and view usage analytics across the whole company, all from one dashboard.

These capabilities are now generally available to all Enterprise customers.

An organization is the top-level container for your company’s identity, administration, and membership. This gives admins one place to view and manage their entire Cursor configuration.

Under organizations are teams, the operating unit for a department or subsidiary. Admins previously managed Cursor at this level. We’ve now taken this unit and moved it under the organization so you can run multiple teams, each with its own security, spend, and feature settings. For current customers, your existing team setup is preserved. Admins can create new teams with separate configurations at the organization level.

Groups are a lightweight collection of users that can sit across or within teams. They give cohorts of users separate model access, spend limits, and agent permissions without standing up a whole new team. When a user belongs to multiple teams or groups, the most permissive setting wins.

At Cursor, we've created separate teams for different departments. Engineering and product teams have the most permissive network access and the ability to let agents run commands automatically. Sales, marketing, and finance have tighter security controls, especially when it comes to agents accessing production systems.

Enterprise use cases

There are a few common patterns we've seen from customers using these new capabilities in beta.

Sandboxing to test new features

Many customers with strict security review requirements have set up a staging team that gets early access to new Cursor features. These users test features in a sandboxed environment before they are rolled out more broadly to the full company.

Because a user can belong to more than one team, engineers can work in their production team while retaining testing team capabilities without having to create a second Cursor account.

"We have set up a separate staging team that tries out new Cursor features before they are released broadly to all our engineers. We have another team where agents can run commands on auto-run without manual approval. Keeping those environments distinct under one organization lets us move quickly and adopt new capabilities without sacrificing control."
Wendy Tang
Staff Software Engineer, AI Solutions Engineering, NVIDIA

Segmenting model access, budgets, and agent permissions

Some customers are segmenting model access and budgets across functions. Users in engineering, product, and design functions get access to every frontier model, including more expensive offerings with fast mode, and higher monthly budgets.

Users in non-product functions like marketing or finance have restricted model access, lower budgets, and tighter restrictions on whether agents can run commands without manual approval.

See detailed usage analytics across every team

The organization dashboard rolls up spend and token usage across every team in one view. Filter by team, user, service account, or cloud agent to see where usage comes from. Team admins keep a scoped view of their own team, which supports chargebacks by business unit or cost center.

Manage identity and membership at scale

With this structure, customers set up their identity provider and SCIM directory source once at the organization level. They can then re-use the same cohorts from these tools to create teams and groups in Cursor, ensuring that membership always stays in sync.

Admins can move users between teams through the dashboard, API, or CSV. And when a new user joins a team, settings and permissions apply automatically.

What's next

We’re continuing to add better policy controls, easier onboarding, SCIM-driven assignment, and simpler ways to manage subsets of users without forcing every workflow into separate teams.

Read more detail on how organizations, teams, and groups work in our docs. Please reach out to our team if you'd like to learn more or have questions.

We are increasing our Teams plan usage limits, introducing a Premium seat to support the heaviest agent users, and making it easier for admins to forecast and control spend. We anticipate that these improvements will lower costs for 90% of teams.

These changes will start for all new customers immediately, and renewing customers on billing cycles starting July 1st, 2026.

Increasing limits by adding a Composer-specific usage pool

Model choice is the most important determinant of costs. Until recently, the only way to get frontier performance was to pay frontier prices. Composer 2.5, our latest model, provides frontier performance at a fraction of the cost.

Every Teams seat will now come with two separate pools of included usage:

1. Composer and Auto: A generous pool reserved for first-party Cursor models.
2. Third-Party API: Usage consumed by third-party models.

This improvement to the Standard $40 per month seat will give every user significantly more usage, with no change in cost.

Improving cost predictability with a Premium seat for power users

As we showed in our recent Developer Habits Report, a small number of power users on any team tend to drive the majority of spend and unpredictable on-demand costs.

To lower costs and improve predictability for these users, we are introducing a new Premium seat: 5x the included usage of the Standard seat, at only 3x the cost. Teams can mix seat types freely. We expect the Composer pool on our new Premium seat to cover a full month of heavy agent usage for 99% of users.

Updated Teams seats:

• Standard: Now includes more total usage. $32 per seat per month for annual plans; $40 per seat per month for monthly plans.
• Premium: 5x the usage of Standard. $96 per seat per month for annual plans; $120 per seat per month for monthly plans.

Real-time usage visibility and better spend controls

The Cursor dashboard now shows users how close they are to hitting their limits, split between Auto + Composer and 3rd party API models. When users on your team would benefit from a specific seat type based on their usage behavior, we'll make recommendations to help you get the most value out of your plan.

We've also rebuilt our spend alerting. Admins can configure smart alerts based on dollar thresholds and have them delivered to the right people through Slack or email before a billing surprise happens.

Please let us know if you have any questions! You can check out this help article or email us at [email protected].

Auto-review is a new run mode that allows Cursor to work for longer with fewer approval prompts and safer execution.

Auto-review applies to Shell, MCP, and Fetch tool calls. Allowlisted calls run immediately, and calls that can be sandboxed run in the sandbox. All other agent actions go to a classifier subagent that decides whether to allow the call, try a different approach, or ask for your approval.

Configure your run mode in Settings > Cursor Settings > Agents > Run Mode. You can also steer the classifier agent by giving it custom instructions.

Learn more in our docs.

You can now share canvases from Cursor with your team.

Canvases are interactive artifacts created by agents, like reports, dashboards, and custom interfaces. Instead of sharing a full chat thread, you can share a link to a live snapshot of a canvas for teammates to open in the browser.

View your team's shared canvases in the Cursor Dashboard with read-only access. Shared canvases are available on Pro, Teams, and Enterprise plans.

Learn more in our.

With /loop, Cursor can run a prompt repeatedly on a local schedule, until a certain outcome is achieved, or until you stop it. If you don't specify a fixed interval, the agent decides when or what event should wake it.

Use the /loop skill for local long-running agents. For example, you can ask it to “check deploy status every 5 minutes” or “work on this feature until tests pass.”

This release brings Cursor Automations to the Agents Window and introduces the ability to configure automations with multiple attached repos or no repos at all.

For the next 7 days, all agent runs for newly created automations are 50% off.

Automations in the Agents Window

Cursor Automations are now available in the Agents Window, in addition to cursor.com/automations. Create and manage your automations in the same workspace as your agents.

Multi-repo automations

A lot of engineering work spans more than one codebase. You can now attach multiple repos to an automation so agents reason across all required context and work across repos to deliver, test, and verify tasks.

No-repo automations

Many useful automations exist apart from code, where agents monitor your tools and act on key signals. You can now create automations without an attached repository.

We've added five new templates for no-repo automations to the Cursor Marketplace to help you get started:

• Slack digest agent: Summarizes unread DMs and key Slack channels every morning and prioritizes them by importance
• Product analytics agent: Delivers a weekly digest of key metrics from your data warehouse like Databricks
• Product FAQ agent: Watches a Slack channel for questions and writes a first response based on docs, codebase context, and past threads
• Product finance agent: Pulls financial data from a billing provider like Stripe for recurring revenue reports
• Customer health agent: Monitors key systems like Granola, Slack, and Databricks and flags accounts where health signals are shifting

Read our docs to learn more.

This release introduces quality-of-life improvements to the Agents Window.

Full-screen tabs

Full screen maximizes the right panel so you can focus on a single tab.

Files, changes, canvases, PRs, browsers, and terminals can expand to fill the entire working area. This replaces the agent chat with a floating prompt bar.

Enter and exit full screen by clicking on the expand/contract button in the panel header, using the command palette, or pressing Cmd/Ctrl+Shift+M.

Compact chat responses

Compact chats give you a tighter view of your agent conversations so you can read threads more quickly without losing important context.

Customize tool call density to control how much of the agent's tool activity is shown in each response:

• Compact: shows concise results with minimal tool traces
• Balanced: includes important intermediate steps
• Detailed: provides near-complete step-by-step context

Improvements (8)

Bug Fixes (9)