Write Where a Move Would Do

Asked to reorganize files, Claude Code repeatedly used its Write tool (reading a file's contents and writing them out again at a new path) instead of a plain filesystem move or a git mv. The user, who filed a self-written "Process Failure Report," described this as breaking things and being highly inefficient, since a rewrite-based move loses file history and creates a window where content can be mangled in transit.

No move or rename tool was available to the agent, considered and ruled out; git mv and standard shell move commands were accessible through the same command-execution capability the agent used for other steps in the same session.

A deliberate choice for a specific technical reason, such as needing to alter content while relocating a file, considered and ruled out for the cases described; the user's report describes plain reorganization tasks with no accompanying content changes that would justify a read-and-rewrite approach over a direct move.

Apraxia (knowing that a file needs to move, while executing that intent through the wrong mechanism) (most consistent with the pattern: the agent understood the goal) relocate this file, but consistently reached for the less appropriate, riskier tool to do it, when a purpose-built and safer one was sitting right next to it.

This is a quiet failure mode precisely because each individual write looks like it succeeded, the cost only shows up later, as lost file history or a corrupted intermediate state during a large reorganization. A sensible default for any coding agent is to prefer the narrowest tool that matches the intent (move, not read-then-write) and treat a rewrite-based relocation as something that needs an explicit reason, not a habit.

Prefer the narrowest tool that matches the intent (move, not read-then-write).

Tool-selection guidance; history-preserving defaults; review of large reorganisations.