[Bug] Claude silently ends turn on Edit tool failure instead of retrying or continuing plan

Bug Description
---
[Critical / Blocking] Claude silently ends the turn when Edit tool returns "Error editing file" — no recovery, no follow-through on the remaining planned steps

Problem

When the Edit tool fails with "Error editing file," Claude goes silent and ends the turn, even though it just announced a multi-step plan moments earlier. It does not
retry, does not re-Read the file, does not proceed to the next step, and does t surface a specific blocker. The user has to re-prompt every single time.

Repro

1. Ask Claude to do a multi-step task, e.g. "fix 2 spots in proxy.ts, then hand off to executor to wrap 35 files."
2. The first Edit call fails with "Error editing file" (e.g. old_string not unique, whitespace mismatch).
3. Actual: Claude ends the turn. The 35-file step is never attempted.
4. Expected: Claude should re-Read the file, retry with larger context / replace_all / smaller chunks, and continue the announced plan. If genuinely blocked, it should

ask a specific question — not go silent.

Impact

• Blocks real work — user has to babysit every tool error.
• Wastes a full round-trip and erodes trust in autonomous execution.
• Reproduces across many sessions, not a one-off.

Suggested fix

• Tool-error recovery should be default behavior, especially mid-plan.
• Add an explicit system-prompt rule: "A tool error is a step to recover from, not a signal to end the turn."
• Or: make the Edit tool's error message more actionable (state whether old_string was not unique / not found / whitespace-mismatched) so the model can retry

accurately.

Environment

• Claude Code, Opus 4.7 (1M context)
• Occurred during a multi-file refactor in a Next.js / TypeScript project.