How to stop Claude from doing more than you asked

The pattern is familiar: you ask Claude to fix a bug. It fixes the bug, then refactors the function it was in, adds a helper, updates comments in adjacent code, and creates a utility it thinks you'll need later. The original fix is buried somewhere in there. You wanted one thing changed and got a diff across five files.

This happens because Claude's default behavior is to be helpful, and helpful reads as thorough. It sees related improvements and makes them. The problem is that unsolicited changes are harder to review, harder to revert if something breaks, and accumulate into a codebase that drifts from what you intended.

There's a specific prompt pattern that stops it.

The minimal footprint instruction

Minimal footprint. Change only what is necessary to complete the specific
task. Do not refactor adjacent code. Do not add error handling that wasn't
asked for. Do not create utility functions or abstractions preemptively.
Do not update comments or documentation outside the scope of the change.

If you see something worth improving that's outside the task scope,
note it as a separate suggestion at the end. Do not implement it.

The last paragraph matters. Without it, Claude will sometimes interpret "don't do X" as "don't do X and don't mention it either." The explicit invitation to note improvements as suggestions rather than implement them gives it somewhere to put those observations without acting on them.

Why "minimal footprint" works better than "only change X"

You could write "only change the bug fix function" for each task. That's more precise but requires you to anticipate every file Claude might touch. "Minimal footprint" as a standing instruction is a principle that transfers across tasks. Claude applies it without you having to specify the exact scope each time.

The phrase itself carries weight — it's specific enough to be actionable and general enough to apply to any task. "Only do what's necessary" is vague. "Minimal footprint: change only what's necessary" is a named constraint that Claude treats as a rule.

When to override it

Some tasks genuinely benefit from the broader approach. "Refactor this module for clarity" or "update all uses of this deprecated API" are wide-scope by design. For those, you'd drop the minimal footprint instruction or override it explicitly in the task.

The pattern works best as a default that you override for specific tasks, rather than something you add only when you've already gotten burned. By the time you're adding it after the fact, you're reviewing an unexpected five-file diff.

In CLAUDE.md

For Claude Code sessions, this belongs in CLAUDE.md so it applies to every task without needing to state it each time:

Minimal footprint. Change only what's necessary for the task at hand.
Don't refactor adjacent code, add unrequested error handling, or create
preemptive abstractions. Note potential improvements separately instead
of implementing them. Ask before creating new files or changing structure.

The last sentence — "ask before creating new files" — covers another version of the same problem: Claude deciding to restructure your directory layout mid-task because it thinks it's cleaner. Better to ask first.

---