Write tool read-before-write guard fires on new files, forces Bash heredoc bypass

Summary

The Write tool requires a Read call before writing to any file path. This guard is logically misconceived: it blocks the Write call, but the same write is trivially achievable via Bash heredocs, which have no guard at all.

The check doesn't prevent blind overwrites. It relocates them to a less visible tool.

The logic problem

The guard's stated goal is to prevent overwriting file content the assistant hasn't seen. But:

1. For new files: There is no prior content. The check is vacuous — it blocks a safe operation for no reason.
2. For existing files: The assistant can bypass it via cat <<'EOF' > file in Bash. The guard doesn't control the write — it only controls which tool performs it.
3. The bypass is strictly worse: Bash heredocs are harder for the user to review than a Write tool call with explicit file_path and content parameters. The guard pushes the assistant toward the less inspectable path.

The guard doesn't reduce the set of things the assistant can do. It reduces the quality of how those things are presented to the user. A safety check that degrades visibility while preventing nothing is worse than no check.

Repro

1. Ask Claude Code to create a new file at a path that doesn't exist yet (e.g. /tmp/something-new.conf)
2. Claude calls Write without a prior Read (because there's nothing to read — the file is new)
3. Write rejects with: "File has not been read yet. Read it first before writing to it."
4. Claude falls back to Bash heredoc, which succeeds with no guard at all

Expected behavior

At minimum: Write should succeed for paths that don't exist on disk.

More broadly: if the guard can be trivially bypassed by another tool in the same toolset, it needs rethinking — either enforce it across all write paths or remove it.

🤖 Generated with Claude Code