Edit tool fails after every user message, forcing unnecessary file re-reads

What happens

The Edit tool fails with "File has not been read yet" every time I send a new message, even if Claude just read the file moments ago. Claude then has to re-read the file and retry the edit. This means roughly 3x the token cost per edit -- the failed attempt, a re-read, then a successful retry.

What I found

I tested this systematically to isolate the trigger:

• Read a file, edit immediately: works
• Edit again 10 seconds later (same turn): works
• Edit again 60 seconds later (same turn): works
• Edit again 2 minutes later (same turn): works
• Edit again 5 minutes later (same turn): works
• User sends any message, then edit: fails

It's not time-based. Edits work indefinitely within a single turn. The moment I send a new message, the file-read state is gone and every edit fails until Claude re-reads.

My hypothesis for why this happens

Context compression runs when processing a new user message. It compresses older conversation history to stay within the context window. The "file has been read" state lives in that conversation history, so when compression drops the original Read call, the Edit tool thinks the file was never read.

Suggested fix

The file-read state should persist through context compression. Options:

1. Persist file-read state as session metadata (not in conversation history)
2. Have the Edit tool auto-read the file before editing
3. Preserve Read tool calls during compression

Environment

• macOS
• Claude Code VSCode extension