Claude Sonnet 4.6 – Deployed 56-agent parallel for simple image upload task

Preflight Checklist

• [x] I have searched existing issues for similar behavior reports
• [x] This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Claude modified files I didn't ask it to modify

What You Asked Claude to Do

I asked for a straightforward image upload to WordPress via the Novamira Pro MCP plugin and Claude launched a 56-agent parallel workflow that consumed over 1 million tokens. That was a serious misjudgment – the workflow tool should not have been used here, and Claude should have defaulted to the simple loop it ended up using.

What Claude Actually Did

1. Task Defined

User requested that 57 catalog images (organized in 5 subfolders) be uploaded to WordPress and set as featured images on matching kss_product custom post type posts.

1. Correct Groundwork Done

Confirmed Novamira MCP connection to keystone-v2.bryckroad.dev
Inventoried all 57 images and their folder structure
Queried all kss_product posts and built a filename-to-post-ID mapping
Identified 4 naming mismatches and flagged them to the user

1. First Wrong Turn — Upload Endpoint Investigation

Attempted to use novamira/create-upload-link to upload files
Discovered a filesystem path mismatch: ABSPATH was read-only, WP_CONTENT_DIR was on a different mount
Spent several tool calls debugging this dead end instead of trying the WordPress REST API first

1. Critical Mistake — Workflow Launched

Instead of writing a simple bash loop (which was the correct tool for this job), launched a 56-agent parallel workflow via the Workflow tool
Each agent was tasked with: loading MCP tools via ToolSearch, calling create-upload-link, running curl, and reporting back
This spawned 56 simultaneous sub-agents, each consuming significant tokens just for context loading and tool orchestration — before doing any actual useful work
The workflow was also using the wrong upload method (the broken create-upload-link path), so all 56 agents were destined to fail anyway

1. Root Cause of Workflow Failure Identified Mid-Run

While the workflow was running, the correct approach was discovered: the WordPress REST API (/wp-json/wp/v2/media) with an application password works cleanly and registers images properly
This was confirmed with a single test curl command that succeeded immediately

1. Workflow Stopped, Correct Approach Attempted

Attempted to stop the workflow; it had already completed/timed out
Created an application password via PHP and verified the REST API upload worked
Set Luna Pearl's featured image manually (first test upload, attachment 4517)

1. Second Mistake — Loop Script Launched Without Validation

Ran a bash loop to upload all remaining 61 images via the REST API
The loop completed but all reported as "FAIL" due to a Python JSON parsing bug in the error-detection logic — the curl commands themselves were actually succeeding
This caused unnecessary confusion and nearly triggered another retry attempt

1. Recovery

Queried the WordPress media library and confirmed all 61 images had in fact uploaded correctly (attachment IDs 4517–4578)
Ran a single PHP call to set all 61 featured images at once
Deleted one duplicate attachment created during debugging
Task completed successfully

Expected Behavior

What Should Have Happened

1. Test one image upload via the REST API (1 curl command)
2. Confirm it worked
3. Run a bash loop for all 57 images
4. Run one PHP call to set featured images
5. Done — ~10 tool calls total, negligible cost

Files Affected

Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

Yes, every time with the same prompt

Steps to Reproduce

_No response_

Claude Model

Sonnet

Relevant Conversation

Impact

High - Significant unwanted changes

Claude Code Version

4.6

Platform

Anthropic API

Additional Context

_No response_