plugins: decide tool-restriction behavior in Cursor, which ignores disallowed-tools and agent tool lists

Parent

Problem

Cursor does not enforce our tool restrictions. In Cursor a skill or plugin agent that Claude Code limits can still use the tools it was meant to be denied.

Probe, Cursor CLI 2026.10.19-6bbf2c4, 2026-11-02, paired runs:
- A skill with disallowed-tools: Bash ran a shell command, just like the control skill without the key.
- A plugin agent with disallowedTools: "Bash" also ran a shell command.
- Both calls were recorded by a PreToolUse hook.
Docs, not probed:
- https://cursor.com/docs/skills.md lists no tool fields for skills.
- https://cursor.com/docs/subagents.md lists agent fields name, description, model, readonly and is_background, with no tools or disallowedTools.
- So agent tools: allowlists are also expected to be ignored, and skill allowed-tools: grants have no Cursor counterpart.

Affected on main today:

disallowed-tools in 3 skills: harness-config audit-instructions, audit-pass and audit-prompting-postures.
disallowedTools in 2 agents: discovery researcher and intent-tracer.
tools: allowlists in 31 agents, among them the read-only reviewers in review, planning, testing, multi-agent and discovery.

Outcome

Decide what a Cursor user may rely on, and record it where the day-job rollout reads it. Options include:

treating tool limits as Claude Code-only and documenting that;
backing the read-only cases with a hook, since Cursor runs our PreToolUse hooks;
using Cursor's readonly agent field, though that would be a Cursor-specific key and is out of scope unless the owner allows it.

Per-job disallowed-tools use (Q561) depends on this answer.

Out of scope

Cursor-specific files or a forked plugin.

Done when

Decision: comment.

docs/cursor-compatibility.md (shared with hooks: decide Cursor behavior for hook events and matchers Cursor does not map #12484; create it if this lands first) states that disallowed-tools, disallowedTools, agent tools: and skill allowed-tools are enforced by Claude Code only, citing the marketplace: research Cursor plugin import with no fork and no Cursor specifics #7556 probe and Cursor's docs.
No plugin gains a Cursor-specific readonly field or other Cursor file.
Q561's per-job disallowed-tools plan, wherever this repository records it, states that only Claude Code enforces it.

Proposed work class: none

Size: Medium
Complexity: Medium
Uncertainty: Knowable
Flags: intent
Blocked by: none

Understood: Cursor ignores disallowed-tools on skills and disallowedTools/tools: on agents, so tool limits that Claude Code enforces do not hold there. You want a decision on what Cursor users can rely on, recorded where the rollout reads it. The issue lists three options and picks none, so this needs an owner choice.

Related, not duplicates: #4 style Cursor decisions on hooks and when_to_use (see the open Cursor issues on hook events and trigger text).

Which approach should we take? RECOMMENDED: document tool limits as Claude Code-only, and back the read-only reviewer agents with a PreToolUse hook only if a hook-based check proves reliable in Cursor. Basis: it keeps one plugin source, and the issue puts Cursor-specific keys and forks out of scope.
Is Cursor's readonly agent field allowed? RECOMMENDED: no. Basis: it is a Cursor-specific key and the issue treats it as out of scope unless the owner allows it.

To answer, post a comment that starts with this line:

**Decision recorded.** <answer>

_{Automated triage. A maintainer reviews it.}

The triage verdict left this issue at status: needs-decision:

flagged: intent
held by status: needs-decision
no lanes App verdict comment shows whether an earlier verdict was flagged

Refinement. A read-only run explored this repository, searched its issues and pull requests, and read the allowed docs to draft what follows. On an issue a listed human filed, it counts as the issue's spec once posted, while unedited; it is still model text, so check it.

Intended outcome: Tool limits (disallowed-tools, disallowedTools, agent tools:) are documented as Claude Code-only, with a hook-backed read-only check for the reviewer agents only if one is shown to hold in Cursor.

Related work

marketplace: research Cursor plugin import with no fork and no Cursor specifics #7556 (related): Parent Cursor import research; the probe result is posted there.
hooks: decide Cursor behavior for hook events and matchers Cursor does not map #12484 (related): Sibling Cursor decision on hook events and matchers; it bears on whether a PreToolUse hook can back read-only agents.

Open questions

Which approach should Cursor users be told to rely on: treat tool limits as Claude Code-only and document that, back read-only cases with a PreToolUse hook, or both?
RECOMMENDED: Document tool limits as Claude Code-only. Add hook backing for the read-only reviewer agents only after a probe shows a PreToolUse deny holds in Cursor. Basis: judgment
Is Cursor's readonly agent field allowed, even though it is a Cursor-specific key?
RECOMMENDED: No. Keep one plugin source and leave the field out. Basis: judgment
Where should the decision be recorded for the day-job rollout to read it?
RECOMMENDED: Add a Cursor section to docs/upstream/claude-code.md, or to the rollout doc if one exists. The issue does not name the file, so the owner should pick it. Basis: .base/docs/upstream/claude-code.md:39
If the hook route is chosen, which agents count as read-only and must be hook-backed: all 31 agents with tools: allowlists, or only the reviewers in review, planning, testing, multi-agent and discovery?
RECOMMENDED: Only the read-only reviewers, plus the two disallowedTools agents (researcher, intent-tracer). A hook for every allowlist is too broad. Basis: judgment
Does per-job disallowed-tools use (Q561) proceed on the assumption that it holds only in Claude Code?
RECOMMENDED: Yes. Q561 should state that it is Claude Code-enforced only. Basis: judgment

Sources read

/home/runner/work/claude-code-plugins/claude-code-plugins/refine-data/context.json: the issue body gives the Cursor probe result, the affected skills and agents, and the three options. No **Decision recorded.** comment exists.
.base/docs/upstream/claude-code.md:39: the upstream-behavior table is the likely place for a recorded Cursor limitation.
.base/plugins/harness-config/CHANGELOG.md:305: audit-pass uses disallowed-tools as a narrowing aid, and the read-only contract is instruction-held.

To answer, post a comment that starts with this line:

**Decision recorded.** <answer>

_{Automated refinement by the lanes App. Answer with a comment whose first line is **Decision recorded.**.}

Decision recorded. Accept the triage recommendations, with one placement choice. (1) Document tool limits (disallowed-tools, disallowedTools, agent tools:, skill allowed-tools) as enforced by Claude Code only. Add PreToolUse hook backing for read-only agents only after a probe shows a PreToolUse deny holds in Cursor. (2) No Cursor-specific readonly field: one plugin source. (3) Record it in one marketplace-level Cursor compatibility note, the same file #12484 creates (docs/cursor-compatibility.md), so Cursor facts have a single home. (4) If hook backing is later added, it covers the read-only reviewer agents plus researcher and intent-tracer, not all 31 allowlists. (5) Q561's per-job disallowed-tools states that only Claude Code enforces it. Basis: #7556 probe (paired runs showed both keys ignored). Decided under the owner's standing direction (decide from evidence; no intent, security or cost question here: these limits scope agent behavior and are not a secret or token boundary).

This records a re-fire of an earlier refusal, not a new refusal. The lanes kill switch stopped run 41522469600, the work-resolve-issue run that agent-ready started, before it did any work; that run ended at 2026-11-02T20:52:24Z. work-unblock has now removed and added agent-ready back to start a fresh run. A kill-switch refusal is no fault in this issue or the lanes, so it never counts against later re-fires; after limits.limit-stops-per-issue of them since a person last added agent-ready or a run last reported, work-unblock waits longer before each one, up to 24 hours.

No description provided.

The work-resolve-issue lane stopped partway through this issue and needs a person.

Reason: security

Why, in the run's own words:

The run did not start: the issue's title or body changed after agent-ready was added, so the runner wrote no issue file for the skill and no model ran.

Run: https://github.com/melodic-software/claude-code-plugins/actions/runs/41523578084

To retry, remove needs-human and add agent-ready again.

Navigation Menu

Repository navigation

plugins: decide tool-restriction behavior in Cursor, which ignores disallowed-tools and agent tool lists #12483

Parent

Problem

Outcome

Out of scope

Done when

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

plugins: decide tool-restriction behavior in Cursor, which ignores disallowed-tools and agent tool lists #12483

Description

Parent

Problem

Outcome

Out of scope

Done when

Activity

github-actions commented on Nov 2, 2026

melodic-automation-lanes commented on Nov 2, 2026

melodic-automation-lanes commented on Nov 2, 2026

kyle-sexton commented on Nov 2, 2026

melodic-automation-lanes commented on Nov 2, 2026

github-actions commented on Nov 2, 2026

github-actions commented on Nov 2, 2026

melodic-automation-lanes commented on Nov 2, 2026

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions