When to interrupt, when to let it run

Claude Code can run for a long time on a complex task. The problem is not duration — a well-scoped task should run until it finishes. The problem is that it can also run for a long time on a task that has gone wrong, and the two situations look identical from the outside.

Three signals that the run has gone wrong

First: Claude is reading files that have no relationship to the task. A refactor of UserController does not need to read PaymentService. If you see tool calls reaching outside the stated scope, Claude has lost the thread.

Second: Claude's proposed plan is substantially larger than the brief. If you asked it to extract a service layer and it proposes to also update the router, add a new middleware, and restructure the models directory, that is scope expansion, not thoroughness.

Third: The same test failure appears three times in a row and Claude's response to each failure is a different approach rather than a diagnosis. This is the "almost done" loop. Claude is guessing rather than reading the error.

The interrupt move

Press Escape or send a new message. You do not have to wait for the current tool call to finish. Name what you are seeing specifically:

> Stop. You're reading files in src/payments/ which is outside scope. 
> Come back to the UserController refactor and ignore that directory.

Claude recalibrates from its current position. It does not start over. The context it has built up about the files it has already read is intact.

Three signals that the run is on track

First: Claude is moving through a predictable sequence — read the controller, propose the service interface, create the service file, update the imports. Each step follows from the last.

Second: The tool calls are staying inside the files you would expect. A controller refactor reads the controller, its imports, and its tests. Nothing else.

Third: When tests fail, Claude reads the failure message and changes the code at the location the failure points to. It is not iterating randomly.

When silence is not a problem

Claude sometimes pauses for several seconds between tool calls while it reasons about the next step. This is normal. The pause is not a stall. Wait for it.

If you get stuck

• You interrupted and Claude seems confused about where it left off: give it a one-sentence summary of what it had completed before the interrupt — "You had already created UserService.ts and updated the imports. The remaining task is to remove the direct DB calls from UserController."
• Claude keeps expanding scope even after you interrupt: add an explicit constraint to every subsequent message — "Do not touch files outside src/api/user.ts and src/services/UserService.ts."
• You are not sure whether to interrupt: run git diff mid-session. If the partial diff is coherent and scoped, let it run. If it is sprawling, interrupt.

Cross-reference

The diff-reading habit from l3 is the prerequisite here. You can only detect scope drift by reading the diff. If you have not built that habit yet, go back to l3 before running a long task.

Deliverable

Run a task long enough to see at least three tool calls. Write down whether each call was inside or outside the scope of what you asked. If one was outside scope, note whether you interrupted or let it run, and what happened.