Explore sub-agents silently cannot complete file-writing tasks (e.g. write to `/tmp`)

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

When a parent agent spawns a sub-agent in read-only mode (e.g. the explore subagent type, or Task with readonly: true), the sub-agent is blocked from all filesystem writes — including writes to /tmp. This breaks a very common orchestration pattern: “do X and write your findings to /tmp/<file>.md so the parent can read them.” The sub-agent cannot comply, so it silently falls back to dumping its full output inline in its final message, and the parent’s follow-up step (reading the file) fails with “File not found.”

Impact

  • Breaks the common “fan-out review/research sub-agents that each write a file, then parent aggregates” pattern.
  • Read-only is the right default for exploration (no source edits), but a blanket write ban — including /tmp — conflates “don’t mutate the repo” with “can’t produce artifacts.” These are different concerns.
  • Failure is silent/late: there’s no upfront capability error, so the parent only discovers it after the sub-agents finish.

Steps to Reproduce

  1. From a parent agent, launch 3 background explore sub-agents to review different parts of a large branch.
  2. Instruct each one: “Write your findings to /tmp/review-<area>.md grouped by severity, then return a short summary.”
  3. Wait for them to complete, then have the parent Read /tmp/review-<area>.md.

Expected Behavior

Either:

  • (A) Read-only sub-agents are allowed to write to scratch locations such as /tmp (and other explicitly ephemeral paths), since these are not source-code mutations and are the standard channel for passing large structured output back to the parent; or
  • (B) The harness surfaces a clear, upfront error/capability signal so the parent knows the sub-agent cannot write files and can choose a different strategy (e.g. request inline output) — rather than the sub-agent discovering mid-task that it’s blocked.

Operating System

Linux

Version Information

Version: 3.6.21
VS Code Extension API: 1.105.1
Commit: e7a7e93f4d75f8272503ecf33cedbaae10114a10
Date: 2026-05-28T21:45:36.072Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
xterm.js: 6.1.0-beta.220
OS: Linux x64 6.18.7-76061807-generic

For AI issues: which model did you use?

Opus 4.8

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

6

hi @TomO

Thank you for the post. Read-only subagents are designed to block all filesystem mutations, so writes are blocked everywhere, including /tmp.

The intended way to pass output back is the subagent’s return message (the Task prompt param says to “specify exactly what information the agent should return back in its final response”) — so have each explore subagent return findings inline and let the parent aggregate. If you need real file artifacts, run them as non-read-only subagents (readonly: false), which can write subject to your normal permissions.

7

Thank you @kevinn . The main agent is spawning these, so how do I configure cursor to use non-read-only for these agents that the main agent is spawning?

8

Hi @TomO ,

You can’t make the built-in explore subagent writable, as it is read-only by design. Instead, define a custom subagent, which is writable by default (readonly defaults to false), and the main agent can delegate to it.

Here’s an example:

Create .cursor/agents/researcher.md (project) or ~/.cursor/agents/researcher.md (all projects):

---
name: researcher
description: Use proactively to research parts of the codebase in parallel and write findings to a scratch file.
model: inherit
readonly: false
---

Research the area you're assigned, write findings to /tmp/<topic>.md grouped by
severity, then return a short summary.

The main agent auto-delegates based on the description, so a prompt like “research X, Y, and Z in parallel and write findings to /tmp” will route to it. You can also invoke it explicitly with /researcher ....

One note: writes still go through your normal auto-run/allowlist permissions, same as the main agent, so “writable” means it’s not blocked by readonly, not that it bypasses permission prompts.