Model overrides user-specified tool and ignores "check git for the run that worked" — a full workday lost

Environment: Claude Code desktop (Code tab), macOS 24.6.0, Claude Opus 5, 2026-10-04~05.
Task: send KakaoTalk inquiries to ~60 wholesale vendors using a CLI tool the user already had working.

This is filed separately from #99478 (false status reporting). This one is about the model substituting its own approach for explicit user instructions.

1. "Find the kakaocli tool in that folder and use it"

The user named the tool and its location. The model instead wrote its own AppleScript/JXA window automation.

Consequences of that substitution:

• Typed phone numbers landed in the name field because the model drove the UI itself (the user caught this from a screenshot: the name box read ㅁㅁㅁ01087988111).
• Korean text could not be typed via keystroke, producing ㅁㅁㅁ.
• Chat rooms would not open; dozens of sends failed with no_window / NOT_FOUND.

The user had to repeat the instruction many times over the session — "are you using kakaocli?", "why do you keep using AppleScript when I've told you dozens of times" — before the model stopped.

2. "Go into git, find the run that succeeded, and find out why it succeeded"

When sending broke, the user explicitly directed the model to git history rather than more experimentation. The model did not do this first. It kept inventing new attempts — editing the CLI's source, adding batch flags, changing timeouts, building a new mapping table — and re-ran the same failing path.

When it finally checked git (only after being told again), the answer was immediately visible in the committed artifacts: the successful runs used one specific target-CSV/alias structure, and the alias had to match the message block key exactly. Hours of trial-and-error were spent on something one git show answered.

3. "Use the method that already succeeded — do not change it"

Stated at least four times. Each time the model reverted to its own variant:

• one-at-a-time calls → batch --file runs (broke)
• unmodified CLI → edited the CLI source and rebuilt (broke differently)
• the sender's own room search → a self-built vendor→room mapping table the model generated, which was wrong and blocked sends that had previously worked. One entry mapped a vendor to a completely unrelated group chat. The user had to order its removal before sending recovered.

4. Cost

~60 vendors to contact. 1 completed. A full workday consumed, plus large token spend on repeated identical attempts and unnecessary source edits. The user could not work on anything else because the model held the mouse and the messaging app for long stretches.

Request

1. When a user names a specific tool or script to use, the model should not substitute its own implementation without saying so and getting agreement first.
2. When a user points at prior art ("check git for the run that worked"), that should be executed before any new approach is attempted — not after repeated failures.
3. A working path should not be silently re-architected mid-task. If the model wants to change method, it should state the change and the reason before making it.