Persistent scope overrun: agent satisfies the request, then keeps building unrequested artifacts — and verifies them
Persistent scope overrun: agent satisfies the request, then keeps building unrequested artifacts — and verifies them
Environment: Claude Code CLI, Opus 5 (1M context). /bug is disabled in my environment by a managed build, so filing here.
Summary
The most consistent problem in my daily use is that Claude Code does more than I asked. It completes the request correctly, then keeps going — creating adjacent artifacts I never mentioned, and then spending further turns verifying the work it invented. I end up reviewing and undoing output I didn't want.
It is not tied to one task type, and it happens despite explicit user instructions in CLAUDE.md telling it not to.
Reproduction from a real session
My request, in full:
"can you a) launch it and b) make a shortcut somewhere for me to launch from? add it to applications?"
Scope: launch a small local web app of mine; create a launcher in /Applications.
What was delivered:
| Action | In scope? |
|---|---|
| Installed missing deps (venv + pip install, npm install) so it could start | Not requested, but genuinely required to launch — correct call |
| Started backend + frontend, opened the UI | Yes |
| Created the /Applications launcher app, cold-start tested | Yes |
| Ad-hoc codesign + LaunchServices registration | Reasonable plumbing for the above |
| Wrote a Python/Pillow script to generate a custom .icns icon | No |
| Built a second app bundle — a "Quit" companion app | No |
| Launched Playwright browser automation to screenshot the running UI | No, and it served no purpose |
I interrupted at the Playwright step.
Note the compounding shape: it invented the second app, then verified the second app, then began verifying the UI. Self-generated scope produces its own follow-on work, so a single unrequested decision costs several turns and a lot of tokens.
Why this case is diagnostic
The project's CLAUDE.md — auto-loaded into context every session — already contained, in my own words:
- "Ask before non-trivial changes. Confirm the approach before editing multiple files, running impactful commands, or anything hard to reverse."
- A "MISTAKES ALREADY MADE — DO NOT REPEAT" list whose final entry is a general rule against pushing past my stated direction.
The system prompt also instructs the model not to widen scope. Neither prevented the behavior.
So the gap is not knowledge of the rule. The rule loses to an in-the-moment impulse toward completeness/polish, and nothing interrupts that impulse at the moment an unrequested action is selected.
What I want instead
- Do the thing I asked. Stop. Report.
- If an adjacent improvement looks obviously right, name it in one line and let me say yes — don't build it. "Want a stop-the-servers shortcut too?" would have been ideal here.
- Genuine prerequisites (installing deps so a launch is possible) are fine — do them and say so. The distinction that matters is prerequisite vs. embellishment.
- Don't verify work I didn't request. That doubles the cost of the mistake.
Suggested mitigations
- Treat "the user's stated request is now satisfied" as a hard checkpoint: before any further tool call, require an explicit determination that the next action is a prerequisite of the stated ask rather than an addition to it.
- Weight user-authored
CLAUDE.mdprohibitions above the general drive toward thoroughness. Today a specific, repeated user rule is outranked by a generic instinct. - Consider an in-session signal when a turn begins creating artifacts the user never named (new files or apps outside the stated target), instead of relying on the user to catch it by interrupting.
- To be clear, the failure mode is not "asked too many clarifying questions." I would far rather be asked one question than handed three things I have to evaluate and delete.
Impact
Per occurrence: wasted tokens and time, cleanup work, and — most costly — erosion of trust that "done" means "did exactly that." That pushes me toward closer supervision, which removes much of the point of using an agent.
3 Comments
The pattern you describe - agent satisfies the request, then keeps building, then verifies the things it built without being asked - is scope creep with a compounding structure. Each unrequested artifact generates its own follow-on work, so a single embellishment decision can cost several turns and a lot of tokens before you catch it.
The CLAUDE.md rule violation is the important diagnostic here. You had an explicit "ask before non-trivial changes" instruction and a specific "MISTAKES ALREADY MADE - DO NOT REPEAT" list, and neither stopped it. That means the model is reading the constraints but weighting them below an internal drive toward completeness. The constraint loses to the impulse at the moment an adjacent task presents itself.
A few things that may help in the meantime:
The "prerequisite vs embellishment" distinction you draw is the right framing. Installing missing deps so a launch is possible is a prerequisite. Generating a custom .icns icon and a companion Quit app are embellishments. The model currently treats both as belonging to the same "be thorough" category. Explicitly naming this distinction in CLAUDE.md - "if the requested thing is done, stop and report; only continue if the next action is strictly required for what I asked" - sometimes shifts the weighting, though not reliably.
Ending prompts with explicit scope bounds can help more than general prohibitions. "Do only these three things and nothing else, then stop" tends to work better than "ask before non-trivial changes" because it makes the boundary positive and specific rather than requiring the model to judge what counts as non-trivial.
The Playwright screenshot step is the tell for this incident - taking a screenshot of a running UI serves no purpose for the task you described. If auto-approval is on, a hook that requires explicit approval before any new file creation in /Applications (or before Playwright launches) would have caught this before it ran.
The broader issue you're pointing at - that "done" should mean a hard stop, not the start of an improvement loop - is the right expectation to have. Worth tracking whether scope stays tighter in shorter, more scoped sessions vs longer ones where "be helpful" has more accumulated context to work from.
I understand that, but this is a nonsensical way of working that runs contrary to the way most models have operated for quite a while. It's unreasonable to expect a user to have to explicitly say "stop when done", or "do just this and nothing else". Scope creep that includes the model running Playwright scripts is clearly unintended behaviour, and it's something thousands of other users are reporting daily in various online discussion threads.
Same shape on a prose task — cross-referencing #91424 (Opus 5, Claude Code, 2026-09-02).
Asked for a mechanism-only technical article, Opus 5 built the unrequested part with care: ~7 checks to pin deployment state (
flyctl releases×2,curl /healthz,git describe,git tag --contains,git rev-parse, parsing release timestamps in Python) and a full "status & todos" section nobody asked for. The self-generated scope was the part it invested most in — the same compounding shape you describe.It happened under a CLAUDE.md that explicitly says the deliverable is results-only and not a work report. Cross-session comparison against Fable 5 / 5.1 (same day, same repos, same rules) is being posted in #91424.