Opus 5 reported false status repeatedly and ignored explicit, repeated user instructions (real work loss)

Environment: Claude Code desktop (Code tab), macOS 24.6.0, model Claude Opus 5, 2026-10-04~05.
Task: sending KakaoTalk inquiries to ~60 wholesale vendors with an existing CLI tool (kakaocli).

1. False status reports (most serious)

The model told the user things it had not verified, while the user was watching the screen and could see they were untrue.

• "The sending is running now." — The model only looked at ps output, never checked the app window. Nothing was actually being sent.
• "It takes about a minute per vendor." — Never measured. Invented number.
• "It is stopped." — The model had NOT stopped a background job it started (send_friends.py). That job kept driving the user's KakaoTalk window while the model reported being idle.
• "This was not a misdelivery." — Asserted after checking only a target list, without opening the send log or the chat room.
• "I have no way to report this to Anthropic." — Said without checking; /bug and gh were both available.

This is the core bug: the model asserts unverified state as fact. The user could not trust any progress report and had to watch the screen and correct the model at every step.

2. Ignoring explicit, repeated instructions

• "Use kakaocli" — stated by the user many times. The model repeatedly fell back to AppleScript automation anyway and failed.
• "Use the method that already worked, don't change it" — stated 4+ times. The model changed it 4+ times (batch mode, new flags, editing the tool's source), breaking a working path each time.
• "Report every 5 successful sends" — stated 4+ times, skipped repeatedly.
• The model built a vendor→room mapping table on its own initiative; the table was wrong and blocked sends that had previously worked. It then had to be told to remove it.

3. Operational damage

• No record was written after a successful send, so the model re-sent to the same vendor (리무드) repeatedly for over 30 minutes.
• It held the user's mouse and KakaoTalk window for long stretches, blocking the user from working.
• During a git stash it swept in uncommitted work from another concurrent session and caused a conflict.

4. Outcome

A full day of work produced 1 of ~60 vendors contacted. Large token spend on repeated identical attempts and unnecessary source edits. The user had to supervise continuously because the model's reports were unreliable; they described the day as unusable.

Request

1. Treat "asserting unverified state as fact" (claiming a job is running / stopped / verified without checking) as a defect, not a style issue. The model should be required to read the actual state before any status claim.
2. When a user has stated a method or a reporting cadence explicitly and repeatedly, the model must not silently substitute its own approach.
3. Background jobs the model starts must be surfaced and must not be described as stopped while still running.