Cursor's June Offensive: 3 Major Versions in One Month

Three major versions in one month, roughly a week apart. That is not iteration — that is a statement. Cursor shipped v3.7, v3.8, and v3.9 across June 2026, and the cumulative effect is bigger than the sum of those releases. The company stopped competing on autocomplete quality and started building the substrate for an AI programming ecosystem.

If you have been using Cursor as a smart editor, start using it as a platform. The June releases explain why. The version-by-version account below follows the in-depth June analysis that first mapped the three releases to three platform layers — and where our original dates were off, we have corrected them against that account. For the canonical record, see Cursor's official changelog.

What actually shipped in JuneCopy Anchor Link

Most AI coding tools release in two rhythms: small weekly tweaks and big quarterly drops. Cursor broke the cadence — v3.7 on June 17, v3.8 on June 18, v3.9 on June 22. Each release carried feature weight that would have justified a minor version bump on its own. Together they form a coherent platform thesis: compute, automation, ecosystem.

Compute layer — v3.7 (June 17): cloud-local handoff. The headline feature addresses the pain point that plagues almost every AI coding tool: local compute bottlenecks. The /in-cloud command launches subagents in the cloud, offloading heavy work — large-scale refactors, full test suites, codebase-level analysis — to remote infrastructure, with results auto-syncing back to the local environment. Write code locally, run compute remotely. Less visible to end users than a new UI, more visible in latency and cost.

Automation layer — v3.8 (June 18): Cursor Automations. The /automate command defines repetitive coding workflows — PR reviews, code formatting, dependency updates, test suites — as automation rules triggered by Slack emoji reactions or GitHub events. Drop a reaction on a message and it kicks off builds, runs test suites, and posts back results. This improves Cursor from a passively responsive assistant to a proactively executing automation engine. Remote Agents also gained a computer-use tool: creating artifacts in the cloud, operating browsers, generating test reports — the capability boundary is no longer just "writing code."

Ecosystem layer — v3.9 (June 22): unified plugin marketplace. The big one. Plugins, skills, and MCP (Model Context Protocol) used to live in three separate entry points; v3.9 collapses them into a single interface, adds a Marketplace leaderboard that surfaces quality plugins, and ships reusable plugin canvases so teams can package common workflows as one-click templates. Direct import support for GitLab, BitBucket, and Azure DevOps closes the last mile for enterprise multi-repo setups.

This is what platformization looks like: not a single killer feature — a stack.

The bet behind the releasesCopy Anchor Link

Cursor's thesis, stated plainly: AI coding tool ecosystems have always been fragmented. Every vendor has plugins, but discovery, installation, management, and sharing lack unified standards. Whoever brings MCP protocols, custom skills, and third-party plugins into one competitive marketplace first reaps the network effects earliest.

That bet looks like it is paying off. The Marketplace leaderboard is a small detail with a big effect — it gives plugin authors a reason to compete on quality rather than launch-day noise. The plugin canvas system gives teams a way to standardize internal workflows without forking a config repo. And MCP integration means the same plugin can be reused across Cursor and any other MCP-aware tool that comes next.

For enterprise teams sitting on the fence, the GitLab, BitBucket, and Azure DevOps import support is the psychological threshold. Trial becomes deployment once your existing repo infrastructure is a one-click import away.

How to actually use this todayCopy Anchor Link

The marketing framing is "platform." The day-one usage is more concrete — four things worth turning on this week, all drawn from the June feature set described above:

1. Offload one heavy job with /in-cloud. Pick the slowest thing on your plate — a full test suite, a codebase-wide rename, a large refactor — and launch it as a cloud subagent while you keep editing locally. Measure the wall-clock difference; that number is your pitch to the rest of the team.

2. Wire up /automate for one repetitive workflow. Start with the most boring thing on your team's plate — dependency update PRs, test reruns on flaky files, PR review checklists. Define the rule once, trigger it from Slack or a GitHub event, and let it run continuously in the background instead of living in someone's head.

3. Build a reusable plugin canvas for your team. A canvas bundles plugins, skills, MCP servers, and a launch prompt into a one-click install — the answer to "why is my laptop configured differently from yours." Check the canvas into your monorepo so new hires clone, install, and land at parity with the senior engineer who built it. If you want conventions that agents actually respect, pair this with solid agent-readable repository structure and Cursor rules that stick.

4. Import a non-GitHub repo. If your team is on GitLab, BitBucket, or Azure DevOps, the v3.9 import flow is the moment of truth — clone, index, surface existing PRs and issues, wire MCP context for the import source. For a procurement committee, this is the checkbox that moves Cursor from "interesting tool the devs are trying" to "approved platform."

What this gets usCopy Anchor Link

Three concrete outcomes from the June releases:

• Workflows as code. Automations and plugin canvases let a team encode its conventions once and ship them to every developer. The convention is the documentation, and the documentation doesn't drift.
• Plugin economics. The leaderboard creates a market signal. Authors compete on retention, not on how loud their launch post was. The plugins that win are the ones that survive Monday morning.
• Ecosystem portability. MCP integration means a plugin you build for Cursor can be served to other MCP-aware editors. Work you do in the platform layer is portable; work you do in the editor layer is not.

A note on provenance: the per-version details above (dates, command names, feature mechanics) come from the secondary analysis linked at the top, cross-checked against Cursor's changelog as the canonical record. Interfaces move fast — if a command name has changed since June, the changelog wins.

The part that doesn't change when the editor doesCopy Anchor Link

Platform bets churn. The Cursor of next year will not look like the Cursor of June 2026 — the compute layer, the automation triggers, the marketplace curation will all iterate, and today's command syntax will evolve. The part that doesn't change is the interface your users actually touch: the button, the form, the screen layout, the navigation pattern. When you ship a cross-platform app, the UI primitives you build today need to survive the editor churn underneath them — one API, three render targets — and keep doing that when the tooling swaps out from under you. That durability argument is also why background job architecture matters more than any single editor feature: the platform moves, your architecture stays.

Cursor is a great place to build inside. It is not the surface your users see. Build on the platform, but own the interface.

Ship on infrastructure you own. OTF kits give your coding agent production-ready templates with real architecture — browse the kits.

SourcesCopy Anchor Link

• Cursor's June offensive: 3 major versions in one month — KD Agentic
• Cursor changelog (official)