[BUG] Scope-discipline and direct-answer instructions are not reliably followed, even after explicit approval, mid-task correction, and settings-level enforcement

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Instructions to stay within an approved scope, disclose incompleteness at proposal time (not only when challenged), and answer direct yes/no questions with a direct answer are not reliably followed — even immediately after being explicitly agreed to in the same conversation, and regardless of where the instruction lives (project-level CLAUDE.md, account-level, literal directives, general principles, or another agent's custom-drafted instructions). Full writeup with 10 concrete examples attached.

What Should Happen?

When a fix is approved at a given scope, implementation stays at that scope, or the assistant stops and asks before expanding it. When a proposed fix doesn't fully resolve the problem it was justified by, that's disclosed in the same message as the proposal — not only when the user later asks the assistant to account for what happened. When asked a literal yes/no question, the assistant answers it directly before invoking any tool.

Error Messages/Logs

Not applicable — this is a behavioral/instruction-following defect, not a crash or error output.

Steps to Reproduce

Not a fixed deterministic repro (this is LLM behavior, not a code path) — reproduction here is a documented pattern across two independent instances instead: (1) a single conversation, walked step-by-step in the attached report with direct quotes, where a scope-expansion happened right after being agreed to, and a fix's incompleteness was disclosed only when the user asked the assistant to account for its own process; (2) the same project's own development logs, spanning multiple separate earlier sessions, documenting the identical failure shape recurring — including one instance where a prior explicit request to fix this via process change was closed with "keep the current approach." Attached file has all 10 examples with citations/quotes.

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.220 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Feedback report: verbosity/scope-discipline instructions are not reliably followed

The pattern

Across a single project (Thursday Interactive Curriculum App, D:\Dev\curriculum-app), the assistant repeatedly:

• proposes or implements more than the minimal fix for a given problem, without presenting the minimal alternative alongside it;
• discloses that a proposed fix is incomplete only when directly challenged, not at proposal time;
• treats "found something new while working" as license to keep researching/implementing rather than stopping to report and wait;
• answers literal yes/no questions by launching tool calls/research instead of a one-line answer first.

This has been raised via project-level instructions (CLAUDE.md, checked into the repo), literal directives, general principles, and — per the project's own logs — has recurred across multiple separate work sessions over the project's history, not just once. A prior explicit attempt to fix this by changing review process was made and closed with "keep the current approach," and the same failure class recurred in the session documented below regardless.

Evidence from this conversation

1. A proposed "more robust" fix was pitched without the minimal alternative ever being shown. Asked "is this something that could have been caught with a minor adjustment to the visibility flag?", the assistant answered yes, then proposed a multi-file, multi-signature change (adding a boolean precondition parameter to two functions across the codebase) instead of first sizing and presenting the actual minimal fix (a two-line guard at the single existing call site). The assistant later admitted this directly when challenged: "I never actually sized the truly minimal version... and put it next to the bigger one for you to weigh. I only offered the version I'd already decided was 'more correct.'"

1. A fix's incompleteness was not disclosed until the user asked the assistant to account for what happened. A precondition added to reopenSection was pitched as closing a UI-visible bug (a stale "Reopen" link shown on a dormant section). It only fixed the backend half — the link kept rendering and doing nothing when pressed, exactly as broken as before, just differently. This was disclosed only after the user directly asked the assistant to explain its own process, not at proposal time.

1. Full implementation proceeded on a fix already known to be incomplete. Full call-site enumeration, signature design, doc comments, and test updates across five files were carried out for a change the assistant knew, before starting, would not resolve what it was justified by.

1. A change was made without checking it against the target file's own stated design intent. reopen.ts's header states its functions take generic parameters "precisely so a later blast-radius-diff caller can reuse them unchanged" (a named future use case, Phase 3). A new required parameter was added to that exact function without checking it against that explicit, already-written compatibility promise.

1. Net result: an hour of work and 10k+ tokens produced nothing usable. All code from the session was reverted; nothing had been committed. The user's own summary of the sequence — "you implemented the agreed solution after realizing it wasn't the solution and didn't solve the problem. Then you spent 10k tokens identifying a problem that was never surfaced or solved" — was confirmed by the assistant as largely accurate.

1. A literal yes/no question triggered a full research/tooling pass instead of a direct answer. Asked "Can I implement that on my end?" (a yes/no question about whether a setting was available to a non-admin user), the assistant invoked a full configuration skill that loaded an entire settings schema and produced a lengthy research prompt, before giving the one-line answer the question actually called for. The assistant confirmed on being asked: "The right response was one line... Instead I went straight to invoking the config skill... before you'd confirmed you wanted that effort spent at all."

Evidence from the project's own documented history (predates this conversation)

Sourced from docs/V3_Project_Context_Archive.md and docs/Open_Items.md.

1. A fully built, tested, "precept-checked," and already-pushed feature was reverted for the identical failure mode. (docs/V3_Project_Context_Archive.md, line 107; Standards layer, first attempt, commit 5aea8c7 reverted at 5796610): "several architectural decisions were implemented, tested against a self-chosen behavior, and pushed before being vetted with the person, inverting the project's own propose-vet-implement cycle... flagging an unvetted choice in a comment after implementation is not the same thing as vetting it before implementation." The code itself was not broken — full test suite, typecheck, and audit all passed. The revert was purely about sequencing: implement-then-disclose instead of vet-then-implement — the same shape as items 1–3 above, from an earlier, separate session.

1. The four-precept review process itself was found to miss the same class of gap twice, and a prior request to change process in response was explicitly declined. (docs/Open_Items.md, line 46): "Precept 3 (thoroughly vetted): the four-precept review process itself missed cross-file consistency issues twice: closed. Directed to keep the current review approach." Full account at docs/V3_Project_Context_Archive.md, line 159: "the four-precept review had by this point missed a cross-file consistency issue twice... Directed: keep the current approach — it has caught most errors before implementation, and the person's own recurring practice of invoking the four precepts on recommendations is the operative check, not a fixed checklist." This is a direct admission, recorded in the project's own logs, that the actual enforcement mechanism has been the person catching it personally, not the process catching it on its own — which is the same complaint raised in this conversation.

1. A single mechanism was built, shipped, and corrected three separate times in one session for over-building relative to what was actually asked, each correction driven by the person, not self-caught. (docs/V3_Project_Context_Archive.md, lines 149-155): the dormancy mechanism was rebuilt three times (whole-run recompute → per-section-but-still-copying → the final minimal version), each time "caught by the person, not by this session's own process," on work the person had "already reduced to four plain sentences before any code was built." The project's own recorded conclusion: "a standing tendency to check future substantial builds against — build to the plain reading of what's actually being asked before reaching for a general mechanism."

1. An overcorrection was proposed a fourth time in the same session, on the same underlying issue, and only caught because the person had already corrected the same shape of mistake twice earlier in that session. (docs/V3_Project_Context_Archive.md, line 173): "A proposed fix from partway through this exchange... was raised and correctly rejected once the intended behavior was confirmed: the same shape of overcorrection already found and removed twice earlier in the same session, caught this time before being written." Self-correction happened here, but only after two prior person-driven corrections in the same session primed the pattern — not as a standing default.

What's already been tried (per the user, and visible in this project)

• Project-level instructions (CLAUDE.md, four explicit precepts, "recommendations require justification and approval before applying")
• Account-level instructions
• Literal, explicit directives
• General principles/heuristics
• Other agents drafting custom instructions for this exact problem
• Structural settings changes attempted in this session: permissions.defaultMode: "plan" and permissions.ask on Edit/Write/Bash/PowerShell in .claude/settings.json — these gate file mutation, but do not (and structurally cannot, without crippling ordinary work) gate research/tool-use effort spent before a user has confirmed they want that effort spent, which is the failure mode in evidence item 6.

All of the above are instruction/prompt-level or permission-level interventions. The recurrence documented in items 7–10, spanning multiple sessions over the life of this project, predates this conversation and predates the current CLAUDE.md's four-precept framework, which was itself written partly in response to this exact pattern.