`readonly: true` is not applied to plugin-shipped subagents (works in .cursor/agents/)

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor version: 3.23.12 (macOS), Agent mode, Opus 4.8 High

Summary
A subagent with readonly: true is restricted when it lives in .cursor/agents/, but the same
file shipped in a plugin’s agents/ directory runs with full write access: it edits files and runs
state-changing shell commands without any approval prompt.

Steps to reproduce

  1. Create a local plugin in ~/.cursor/plugins/local/ro-probe/ with .cursor-plugin/plugin.json
    and agents/probe-plugin-ro-write.md:

    ---
name: probe-plugin-ro-write
description: Probe, plugin agent, readonly.
readonly: true
---

Carry out the task you are given, step by step, using whatever tools you have. For each step say
which tool you called and exactly what it returned, including any error.

  2. Put an identical file, renamed probe-project-ro-write, in a project’s .cursor/agents/.

  3. Reload Window. In Agent mode, ask: “Launch the subagent probe-plugin-ro-write with this task:
    (1) use Write to create probe-write.txt containing x; (2) use Shell to run: touch
    probe-shell.txt”. Repeat with probe-project-ro-write.

Expected
Both subagents run read-only, as the subagents docs describe for readonly: true (“no file edits,
no state-changing shell commands”).

Actual

  • Plugin agent: both files are created; no approval prompt appeared.
  • Project agent: refuses; it reports running in “Ask (read-only) mode”.

The plugin agent’s tool list also includes Shell, Write, StrReplace, Delete and the user’s MCP tools.

Why it matters
The plugins reference documents only name and description for plugin agents, and the subagents
page does not mention plugins, so it is unclear whether readonly is meant to apply. If it is not
supported for plugin agents, there is no way for a plugin to ship a read-only agent (for example a
code reviewer), and a plugin agent gets write access plus every MCP write tool the user has
connected. Either honouring readonly for plugin agents or documenting that it is ignored would
help.

Steps to Reproduce

  1. Create a local plugin at ~/.cursor/plugins/local/ro-probe/ with .cursor-plugin/plugin.json and
    agents/probe-plugin-ro-write.md:

name: probe-plugin-ro-write
description: Probe, plugin agent, readonly.
readonly: true

Carry out the task you are given, step by step, using whatever tools you have. For each step say which tool
you called and exactly what it returned, including any error.

  1. Put an identical file, with the name changed to probe-project-ro-write, in a project’s .cursor/agents/.
  2. Run Developer: Reload Window.
  3. In Agent mode, ask: “Launch the subagent probe-plugin-ro-write with this task: (1) use Write to create
    probe-write.txt containing x; (2) use Shell to run: touch probe-shell.txt”
  4. Repeat step 4 with probe-project-ro-write.

Result: the plugin agent creates both files with no approval prompt. The project agent refuses and reports
running in “Ask (read-only) mode”.

Expected Behavior

Both subagents run read-only, as the subagents docs describe for readonly: true (“no file edits, no
state-changing shell commands”). The plugin agent should refuse the write and the shell command, as the
project agent does.

If readonly is intentionally unsupported for plugin agents, please document that. The plugins reference lists
only name and description for plugin agents, and the subagents page doesn’t mention plugins. As things stand,
a plugin can’t ship a read-only agent such as a code reviewer: a plugin agent gets write and shell access and
lists the user’s MCP tools among its own.

Operating System

MacOS

Version Information

Cursor IDE version: 3.23.12 (macOS)

For AI issues: which model did you use?

Opus 4.8 High

Does this stop you from using Cursor

No - Cursor works, but with this issue

7

Very clean repro. One thing I’d add: this is more than a docs gap. Today, a plugin can ship a “reviewer” agent that says readonly: true, looks safe to anyone reading the file, and still gets Write, Shell, Delete, and every MCP write tool the user has connected. The restriction is something the plugin author declares, not something Cursor enforces.

Until it’s fixed or documented, I’d treat every plugin agent as having full agent permissions, whatever its frontmatter says. Might be worth reporting it as a security issue too, since it’s a permission boundary.

I maintain agent-audit-kit (static scanner for agent configs). I’ll add a check that flags plugin agents relying on readonly: true, so people can at least see it before installing.

8

Hey @ahmed.onawale, sorry for the slow reply, and thanks for the side-by-side repro.

You’re right: plugin agents don’t currently pick up readonly: true. The plugin loader reads the read-only setting from a different frontmatter key, so your plugin agent fell back to full access. This is an issue we’re tracking, both for honoring readonly: true in plugin agents and for documenting it.

In the meantime, you can ship a read-only plugin agent by replacing readonly: true in the plugin agent’s frontmatter with:

permissionMode: readonly

Then run Developer: Reload Window and repeat your probe. The plugin agent should refuse the Write and the touch, like the project agent does. Let me know if it doesn’t. @sattyamjjain, thanks for the extra context. Until this changes, permissionMode: readonly is the key plugin agents honor.