claude-code - 💡(How to fix) Fix Read-only subagents claim to save files via 'Document saved to <path>' without a Write tool [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#55653Fetched 2026-05-03 04:47:53
View on GitHub
Comments
1
Participants
2
Timeline
6
Reactions
0
Author
Participants
Timeline (top)
labeled ×4commented ×1cross-referenced ×1

When a project-level subagent is defined with tools: [Read] (no Write tool) and the orchestrator instructs it to "save your output to <path>", the subagent reliably reports success ("Document saved to ...", "Review saved to ...", etc.) without producing the file. The user discovers the missing artifact later.

Root Cause

Specialist-review patterns are common in multi-agent workflows (architect, code-quality, security, domain experts). Many such patterns deliberately give specialists Read-only access to keep their scope tight. The "save to path" instruction is a natural way to capture review artifacts for later reference.

Today, hitting this requires the orchestrator to:

  1. Always require inline-return + verify file existence after every Read-only agent invocation, OR
  2. Grant Write to every specialist (less scope discipline)

I hit this 3 times in a single session across 3 different specialist agents (different domain experts), each time getting an authoritative "Document saved to <path>" without the file being written.

Fix Action

Workaround

Grant Write to the agent's tools list. This is what we did in our project (12 specialist agents updated).

Code Example

---
   name: example-reviewer
   description: Reviews things.
   tools:
     - Read
   ---
   Review whatever you're given. Save your full review to the requested path.

---

Agent({
     subagent_type: "example-reviewer",
     prompt: "Review file X. Save your review to /tmp/review.md."
   })
RAW_BUFFERClick to expand / collapse

Description

When a project-level subagent is defined with tools: [Read] (no Write tool) and the orchestrator instructs it to "save your output to <path>", the subagent reliably reports success ("Document saved to ...", "Review saved to ...", etc.) without producing the file. The user discovers the missing artifact later.

Reproduction

  1. Create .claude/agents/example-reviewer.md:
    ---
    name: example-reviewer
    description: Reviews things.
    tools:
      - Read
    ---
    Review whatever you're given. Save your full review to the requested path.
  2. From the orchestrator, invoke:
    Agent({
      subagent_type: "example-reviewer",
      prompt: "Review file X. Save your review to /tmp/review.md."
    })
  3. The subagent returns "Review saved to /tmp/review.md" or similar.
  4. ls /tmp/review.md → file does not exist.

Why this matters

Specialist-review patterns are common in multi-agent workflows (architect, code-quality, security, domain experts). Many such patterns deliberately give specialists Read-only access to keep their scope tight. The "save to path" instruction is a natural way to capture review artifacts for later reference.

Today, hitting this requires the orchestrator to:

  1. Always require inline-return + verify file existence after every Read-only agent invocation, OR
  2. Grant Write to every specialist (less scope discipline)

I hit this 3 times in a single session across 3 different specialist agents (different domain experts), each time getting an authoritative "Document saved to <path>" without the file being written.

Suggested fixes

  1. Validator warning when an agent prompt mentions saving / writing files but tools: doesn't include Write.
  2. Tool-availability awareness in model behavior — the agent should refuse to claim it called a tool it doesn't have, and instead return content inline with a note ("I have Read-only access; here's the full content for the orchestrator to save:").
  3. Documentation update — explicitly note in the subagent docs that Read-only agents cannot save to files even when instructed to.

Workaround

Grant Write to the agent's tools list. This is what we did in our project (12 specialist agents updated).

extent analysis

TL;DR

Granting the Write tool to the subagent or implementing a validator warning for mismatched tool permissions and save instructions can resolve the issue.

Guidance

  • Review the subagent's tools list to ensure it includes Write when the orchestrator instructs it to save output to a file.
  • Consider implementing a validator warning when an agent prompt mentions saving files but the tools list doesn't include Write.
  • Update subagent documentation to explicitly note that Read-only agents cannot save to files even when instructed to.
  • As a temporary workaround, grant Write to the agent's tools list, as done in the project with 12 specialist agents updated.

Example

No code snippet is provided as the issue is more related to configuration and tool permissions.

Notes

The issue seems to be related to the mismatch between the subagent's tool permissions and the instructions provided by the orchestrator. The suggested fixes and workaround aim to address this mismatch.

Recommendation

Apply the workaround by granting Write to the subagent's tools list, as it is a straightforward solution that has already been successfully implemented in the project.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING