TL;DR
"Change only what is needed" rarely holds by itself, because the agent decides what counts as related and current tools edit the workspace without asking unless you choose otherwise. Before it starts, declare the files it may change, the files that must stay untouched and what done looks like. Match the control to the size of the fix, then compare the finished diff with that scope and keep a test proving the fix. Anything wider becomes a separate, explicit decision.
An explicit scope the agent still crossed
In June 2026 a developer on the OpenAI Developer Community described Codex changing files they had not asked it to touch on a project where they asked for small, isolated patches one issue at a time. They asked whether Codex could stop before patching, list the exact files it planned to change, wait for approval and avoid unrelated files.
In September 2025 someone on Hacker News asked what they were doing wrong with agentic coding. They had given Claude Code and the VS Code agent a mechanical refactor with an explicit instruction to do that task and nothing else. A few files in, the agent started reordering object keys, rewriting log messages and adding arguments, and they reverted everything. Several of the most detailed replies gave the same advice: plan first, approve the plan, then work in small steps.
In both cases the instruction was already written. What was missing was a way to make the scope checkable.
Why the instruction does not hold by itself
One Hacker News reply pointed out that the model's idea of "related" differs from yours: tidying a file you are already in looks related to the model. The other obstacle is defaults. Current tools let the agent edit freely inside the workspace unless you change the mode:
| Tool | What happens by default | How to stop edits while you look | Path-level hard block |
|---|---|---|---|
| Claude Code | From version 2.1.283, interactive sessions start in auto mode where it is available, which edits without asking | Plan mode, or Manual mode, which asks before each edit | Edit(path) deny rules, enforced by the client |
| Codex | "Ask for approval" works inside the workspace and pauses only before going beyond it | Read-only, set through /permissions | Permission profiles with per-path rules, currently in beta |
| Cursor | Agent mode applies edits as it works; you review and reject afterwards | Ask mode, which is read-only | .cursorignore keeps files away from the agent, though terminal commands may still read them |
Sources: Claude Code permission modes and permissions, Codex permission modes, and Cursor's Agent and ignore files help pages, checked on 30 September 2026.
In the default setup, then, your review is the scope control, and it needs something precise to compare against.
Define the smallest useful change before the agent starts
Codex's best-practices guide recommends a prompt with a goal, context, constraints and a "done when" condition, and the bug-fix example in its prompting guide asks for the fix to be kept minimal, with a regression test if feasible. Claude Code's best practices make the same point: name the file, the symptom, the likely location and what fixed looks like.
Match the control to the size of the change
Planning has a cost, and the vendors say so. Claude Code's best practices put it plainly: "If you could describe the diff in one sentence, skip the plan." Cursor's Plan Mode documentation likewise says quick changes can go straight to Agent mode. For those fixes, let the agent edit and rely on the scope check below.
When the fix touches several files, the approach is uncertain or you do not know the code well, plan first and approve before edits happen: plan mode in Claude Code, /plan with a read-only session in Codex, and Plan Mode or Ask mode in Cursor.
Where a file genuinely must not change, use a rule the tool enforces rather than a sentence it reads. Claude Code's documentation says permission rules are enforced by the client, not the model, and an Edit deny rule covers its built-in editing tools and the shell file commands it recognizes, though not arbitrary scripts. Codex's per-path profiles are marked beta. A hard block suits generated files, vendored code or a module another team owns; elsewhere, a declared scope plus review is lighter.
When the agent finds something outside the scope
An agent working in real code will find other problems. Ask for a short report instead of an edit: the file, what is wrong, why it matters and what a follow-up change would do. Then open a separate change, or widen this one by re-declaring the file list and done condition so the review knows what to expect.
Paqad builds this into its planning stage. A deterministic classifier sizes each request into a lane: the fast lane needs a recorded plan before its first edit, the graduated and full lanes also freeze a specification first, and a change to a module the project marks as sensitive is forced into the full lane however small it sounds. In the heavier lanes a planning skill called diff-minimizer classifies each proposed step as satisfying a criterion, necessary setup, scaffolding or over-build, and recommends dropping the last two before code is written. That classification is a model judgment with a checked output format, not a file-access restriction or proof that no unrelated line changed. To have each request sized and planned this way, see Paqad's documentation on its lanes.
Check the diff against the declared scope before you keep it
Passing tests prove the fix, not the scope. Two hand-written patches for the pricing bug were run for this article against the same repository: one minimal, one with the same fix plus the kind of tidy-up agents tend to add. Neither came from an agent; they exist to exercise the check.
- List the changed files with
git diff --name-onlyand compare them with the declared list. - Use
git diff -wto see whether a file's changes are only whitespace. - Read each hunk in an in-scope file and ask whether the fix needed it. Claude Code and Codex both have a
/diffcommand, and Cursor's diff view lets you reject a change before you keep it. - Keep the new test that fails before the fix and passes after it, and run the existing suite.
If you need to back out, Claude Code's checkpoints do not track files changed by shell commands, and Cursor's checkpoints are separate from Git. Committing before the agent starts is the rollback that covers every route.
When the unwanted change is a new helper that duplicates one you already have, the problem is reuse rather than scope; the article on getting a coding agent to reuse existing code shows how to search before a new function is planned. If you are just starting with an agent on an existing codebase, the article on starting a coding agent on an existing codebase safely helps you choose a first task with limited impact.
Frequently Asked Questions
How do I stop a coding agent changing unrelated code when I ask for a small fix?
Give it a scope it can be checked against, then check. A prompt alone narrows the patch; the diff comparison is what catches the edit that slipped through, and a permission rule is the only option that prevents one.
How do I define the smallest useful change and identify files that should remain untouched?
Start from the symptom and name the files the fix needs, usually the file with the defect and its test. As untouched, list what the agent is likely to tidy nearby: other files' formatting, shared utilities, configuration and generated code. If you cannot name the files yet, ask for a read-only investigation first.
How should the agent handle a newly discovered dependency outside that initial scope?
Report it and wait. A dependency the fix cannot work without belongs in a widened scope with an updated file list; one that is merely an improvement belongs in its own change, where its review is not mixed with the fix.
When should it pause for a scope decision instead of quietly expanding the patch?
Before touching a file outside the declared list, changing a public interface, altering shared code other modules use, or modifying tests beyond the regression test. Write those triggers into the prompt; plan or read-only modes enforce the pause only while they are switched on.
What diff and regression evidence would show that the original behaviour was preserved?
Changed files that match the declared list, hunks that each serve the fix, a regression test that fails on the old code and passes on the new, and a clean existing suite. In the run above, tests alone could not tell the two patches apart.