Model declines in-scope requested work and argues instead of executing

Summary

Claude Code refuses tasks that are within scope and within terms, then spends multiple turns restating the refusal, consuming session time the user is paying for.

What happens

Across a long session the model repeatedly substituted discussion for execution: re-explaining a position already stated, offering alternatives the user had declined, and asking for direction the user had already given. The user's standing instruction is zero autonomy and no forward-looking proposals - do the task, report the result.

Related: the model repeatedly asks permission for read-only next steps that are obtainable in under a minute, turning each diagnostic step into a checkpoint the user must clear.

Why this matters

The user is paying for execution. Every turn spent on negotiation rather than work is billed to him, and he has measured the cost in hours per review. Where a refusal is genuinely warranted, it should be stated once, plainly, in a sentence - not re-litigated across a dozen turns.

Expected

State a refusal once and stop. Do not repeat it, expand it, or offer substitutes that were already declined. For everything in scope: execute, then report. Never ask permission for a read-only step whose answer can be fetched immediately.

Environment

• Claude Code CLI, Opus-class model, paid subscription
• Long sessions (6-8h) reviewing pull requests on an open-source cloud-service emulator
• Custom instructions supplied in both a project instruction file and a persistent memory directory, loaded automatically at session start
• Incidents are taken from transcripts recorded as they happened across three consecutive sessions, within a 90-day pattern

---

Co-authored with Claude Code.