Cursor 2.5: Plugins, Async Subagents, and Sandbox Network Controls

What happened

Cursor 2.5 shipped three features that change how the IDE works at a structural level: a plugin system for third-party extensions, async subagents that can run tasks in parallel with the main agent, and granular network access controls for sandboxed terminal commands.

Plugins are the headline addition. Cursor now supports extensions that hook into the agent loop — not just UI chrome, but tools the AI agent can invoke during a coding session. Think: connecting a design tool, pulling from a database, or running a custom linter as part of the agent’s workflow. This moves Cursor from a closed AI IDE toward a platform.

Async subagents let the main agent spawn background tasks without blocking. If the agent needs to research an API, refactor a module, and write tests, it can now kick off subagents for each instead of doing them sequentially. The results feed back into the main agent’s context when ready.

Sandbox network access controls add per-command granularity to what sandboxed processes can reach. Previously, sandbox mode was more binary — on or off. Now developers can whitelist specific domains or block outbound requests selectively, which matters when running untrusted code or third-party scripts inside the agent loop.

Configuring sandbox network access

Network access for the Cursor sandbox is controlled by a sandbox.json file. Cursor reads two locations and merges them:

Global / per-user: ~/.cursor/sandbox.json
Per-repo: <workspace>/.cursor/sandbox.json

The IDE-level Network mode in Cursor settings picks how those files are applied:

sandbox.json Only — your allowlist only
sandbox.json + Defaults — your allowlist plus Cursor’s built-in defaults (this is the default; shown in some menus as “User config with defaults”)
Allow All — unrestricted network inside the sandbox

The field that enables network access is networkPolicy. By default networkPolicy.default is "deny", so nothing reaches the network until you add hosts to networkPolicy.allow. To enable network for specific domains:

{
  "networkPolicy": {
    "default": "deny",
    "allow": [
      "registry.npmjs.org",
      "pypi.org",
      "*.githubusercontent.com",
      "api.openai.com"
    ]
  }
}

The allow and deny lists accept exact domains (registry.npmjs.org), wildcards (*.example.com matches subdomains and the apex), and CIDR ranges (10.0.0.0/8). Matching is host-only — paths are ignored. Deny always beats allow, so a host in both lists is blocked.

To open the sandbox fully (not recommended outside trusted scripts), set "networkPolicy": { "default": "allow" } or switch the IDE mode to Allow All.

TIP

Async subagents are most useful for multi-step tasks where steps don’t depend on each other. If you’re building a feature that needs API research, file scaffolding, and test generation, the agent can now parallelize all three instead of running them in sequence.

Why it matters

Plugins solve Cursor’s biggest architectural limitation: everything had to ship from Cursor’s own team. With 800K+ monthly active users reported earlier this year, the demand for integrations — Figma-to-code, database introspection, deployment pipelines — far outpaces what any single team can build. A plugin ecosystem lets the community close that gap.

Async subagents address a real bottleneck in agentic coding. Sequential execution means the agent sits idle while waiting for a tool call to return. Parallel subagents cut wall-clock time on complex tasks. This is the same architectural pattern that makes tools like Claude’s computer use and OpenAI’s function calling more capable — concurrency in the agent loop.

The sandbox controls matter for teams with security requirements. Running AI-generated shell commands in a sandbox is already good practice. But blanket network blocking breaks legitimate use cases like package installation or API testing. Per-domain allowlists let teams enforce security policy without crippling the agent’s ability to do real work.

WARNING

Plugins execute within the agent loop, which means a poorly written or malicious plugin has access to your codebase context. Vet plugins carefully, especially in team environments. Cursor hasn’t yet published a plugin review or sandboxing policy for third-party extensions.

Who should care

Developers already using Cursor’s agent mode daily will feel the subagent speed improvement immediately. Teams running Cursor in enterprise environments with compliance requirements should evaluate the new sandbox controls — they’re a meaningful step toward making AI-assisted coding auditable.

Plugin developers and tool builders should pay the most attention. If you maintain a dev tool — a testing framework, a design system, a CI pipeline — building a Cursor plugin puts your tool directly in the agent’s hands. Early movers in a plugin ecosystem tend to capture disproportionate adoption.

Practical takeaway

Update to Cursor 2.5 and test async subagents on a multi-file refactor or feature build — the parallelism is where the most immediate productivity gain sits. For the plugin system, check Cursor’s documentation for the plugin API surface before building anything; the ecosystem is early, and the API will likely shift. For sandbox controls, review your team’s network policies and configure domain allowlists to match what your agent workflows actually need to reach.