[BUG] Edit tool rejects 'File must be read first' even when the file was just written by Bash/Write in the same session

Summary

The Edit tool rejects with File has not been read yet. Read it first before writing to it. even when the file in question was created or modified by Bash (or Write) earlier in the same session. The same-session safety check only treats Read as a "warm" signal, so any file produced via Bash requires an extra Read round-trip before any small Edit can be performed.

Reproduction

1. In a single Claude Code session, generate or rewrite a file via Bash (for example, a Python heredoc that writes the merged file: python3 -c "open('a.txt','w').write('hello world')" or a shell cat <<EOF > a.txt).
2. Without calling Read on a.txt, attempt Edit a.txt 'hello' 'world'.
3. Edit returns:

``
<tool_use_error>File has not been read yet. Read it first before writing to it.</tool_use_error>
``

1. Calling Read on the same file once and retrying the Edit immediately succeeds.

Expected

Edit should not block in this case. The session itself just produced or modified the file, so the contents are already known to the environment (and frequently still in the conversation as the Bash tool's stdout). At minimum, file paths that the same session has just written via Bash or Write should be considered "warm" for the Edit safety check.

Why this matters in real workflows

A common pattern is:

1. Bash assembles or generates a file (merging several sources into one .cs, building a generated config, scripting a transform).
2. The assistant then needs a tiny surgical Edit on that file (e.g., fixing a single header line, renaming an identifier in the generated artifact).

Today, every Bash-generated file requires a manual Read before any Edit, which:

• adds turns and friction without adding meaningful safety, since the file is something the same session just wrote, and
• silently blocks plans the model already laid out, breaking the flow.

I hit this repeatedly while preparing a multi-file C# sample (Bash-merged → small Edit on the header) — every header tweak cost an extra Read.

Suggested fixes (any one of these would help)

1. Treat Bash/Write as warming the file for the in-session "must Read first" check. Track paths that the session itself wrote.
2. Auto-Read once on the first Edit of an unread path, then proceed, instead of erroring out.
3. Setting/flag, e.g. editAllowsBashWrittenFiles: true, for users who explicitly want this behavior.

Option 1 looks the cleanest — it preserves the original safety intent (don't blindly Edit a file the session has never touched) while removing the false positive on files the session just produced.

Environment

• Claude Code: 2.1.118
• OS: Windows 11
• Model: claude-opus-4-7 (1M context)
• Mode: auto

Notes

• Not blocking, just friction. But it is consistent enough across long sessions that it appears to be a deliberate gating, not flake.
• Closely related but distinct from #21751 / #50597 (those are about silent empty assistant turns); this one is a deterministic tool error, easy to reproduce.