Subagents that are configured as read-only fail to start and return a refusal response

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Subagents that are configured as read-only (readonly: true) fail to start and immediately return a refusal response (“I’m sorry, but I cannot assist with that request.”) even for trivial harmless prompts.

This appears to be a regression because it was working earlier today, and many workflow subagents depend on read-only mode.

There is also a related issue where subagent_type: “explore” fails even without readonly: true, while other non-readonly subagent types still work.

Steps to Reproduce

Launch a subagent with readonly: true and a minimal prompt (for example: “Reply with OK”).
Observe immediate refusal (“I’m sorry, but I cannot assist with that request.”).
Launch the same prompt without readonly: true using subagent_type: “generalPurpose” (works).
Launch subagent_type: “explore” without readonly (still refuses).

Expected Behavior

Read-only subagents should start successfully and perform read-only analysis tasks.
explore subagent should start successfully with valid prompts.
Behavior should be consistent with earlier today when these flows were working.

Operating System

MacOS

Version Information

Version: 2.5.26
VSCode Version: 1.105.1
Commit: 7d96c2a03bb088ad367615e9da1a3fe20fbbc6a0
Date: 2026-02-26T04:57:56.825Z
Build Type: Stable
Release Track: Default
Electron: 39.4.0
Chromium: 142.0.7444.265
Node.js: 22.22.0
V8: 14.2.231.22-electron.0
OS: Darwin arm64 24.6.0

For AI issues: which model did you use?

subagent runtime (multiple subagent types tested).

For AI issues: add Request ID with privacy disabled

f9a7046a-279b-47e5-ab48-6e8dc12daba1

Additional Information

Repro matrix (observed)
generalPurpose + readonly: false → works
shell + readonly: false → works
security-sentinel + readonly: false → works
any tested subagent + readonly: true → fails with refusal
explore + readonly: false → fails with refusal

High impact on workflow reliability: many specialized subagents are designed to run in read-only mode for safe analysis, and those workflows are now blocked.

Does this stop you from using Cursor

No - Cursor works, but with this issue

1 Like

Encountering the same issue on my Windows 10 machine:

Version: 2.5.26 (user setup)
VSCode Version: 1.105.1
Commit: 7d96c2a03bb088ad367615e9da1a3fe20fbbc6a0
Date: 2026-02-26T04:57:56.825Z
Build Type: Stable
Release Track: Default
Electron: 39.4.0
Chromium: 142.0.7444.265
Node.js: 22.22.0
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.19045

Also attempted on nightly build and got the same response:

Version: 2.6.8 (user setup)
VSCode Version: 1.105.1
Commit: 860af19aa4e53f128bd7bdc300e7874cfe03b920
Date: 2026-03-03T03:30:30.350Z
Build Type: Stable
Release Track: Nightly
Electron: 39.6.0
Chromium: 142.0.7444.265
Node.js: 22.22.0
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.19045

1 Like

codex 5.3 extra high max: plan mode doesn’t work

opus 4.6 thinking max: plan mode works

Hey, thanks for the detailed bug report. The repro matrix and request ID are really helpful.

This looks like a server-side regression since it repros on both macOS and Windows, in stable and nightly builds. I’ve passed this to the team.

Based on your testing, there are two separate issues:

  1. Any subagent with readonly: true fails immediately
  2. The explore subagent type crashes even without readonly

Both cases used to work, so something clearly changed on the backend.

I’ll update this thread once there’s progress. If anything changes on your side in the meantime, let me know.

Dean - Really appreciate the quick response to the bug report report. I ran the nightly build/ update this morning and the subagents with both readonly: true and exploreappear to be functioning as expected again.

Version: 2.6.11
VSCode Version: 1.105.1
Commit: 8c95649f251a168cc4bb34c89531fae7db4bd990
Date: 2026-03-03T18:57:48.001Z (19 hrs ago)
Build Type: Stable
Release Track: Default
Electron: 39.6.0
Chromium: 142.0.7444.265
Node.js: 22.22.0
V8: 14.2.231.22-electron.0
OS: Darwin arm64 24.6.0