[BUG] Edit/Write "File has not been read yet" error causes ~17% of cases to halt the agent turn, requiring user "continue"

Preflight Checklist

• [x] I have searched existing issues
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

Related

Reopens the behavior pattern from #57558 (closed). The reporter described an
agent halting on "File must be read first" until a human typed "continue".
Filing this with empirical data from our own session logs to support that
the behavior is reproducible and not isolated.

Summary

When Edit or Write returns File has not been read yet. Read it first
before writing to it., the agent's turn ends ~17% of the time without
recovery, requiring a human "continue" to resume. The remaining ~83% of cases
self-recover (Read + retry on the next assistant turn).

Halt Mechanism (consistent across all confirmed halts)

After the error tool_result, the harness injects a batch of metadata entries
(attachment, system, file-history-snapshot, permission-mode,
last-prompt, pr-link, queue-operation). The assistant turn ends
during or before this flush — no new assistant turn is queued. The CLI shows
Cogitated for Xm Ys and waits for the user. The user has to type something
to re-prompt the model.

Verbatim Excerpt (anonymized)

[assistant] Edit → packages/api/src/app.ts
[tool_result is_error=true] File has not been read yet. Read it first before writing to it.
[attachment] [attachment] [attachment] [system] [system] [last-prompt]
[permission-mode] [pr-link] [file-history-snapshot]
[user] "continue"
[user] "stuck?"
[assistant] "No — just hit a harness rule that requires a Read before Edit.
             Reading then editing:"
[assistant] tool_use: Read → packages/api/src/app.ts

The model clearly knows how to recover when re-prompted — the issue is that
the turn ends before it does so.

Why This Matters

• Long-running autonomous workflows (agent fleets, multi-step refactors,

ralph/autopilot loops) silently stall. The user only discovers it on
return.

• The error itself is correct — the harness is right to require a Read.

The bug is in turn-continuation: a recoverable error should not end
the turn.

Reproduction Conditions

Most likely after:

• Long sessions where the file was read in a turn that has since been

context-compacted.

• Subagent hand-offs where the parent's read-state didn't transfer.
• Files renamed/moved during the session (the Read at the old path no

longer satisfies the harness for the new path).

Suggested Fixes (any one)

1. Harness-side: auto-issue a Read on the file path and retry the

Edit/Write transparently before surfacing the error to the model.

1. Harness-side: persist "file has been read" state across context

compaction and propagate it to subagents.

1. Model-side: ensure the recoverable error does not end the assistant

turn — the model should always continue with a Read and retry.

Environment

• Claude Code: 2.1.144
• Model: Opus 4.7 via Bedrock (global.anthropic.claude-opus-4-7[1m]); behavior also seen on Sonnet 4.6 via Bedrock
• Platform: macOS 25.4.0, zsh
• Provider: AWS Bedrock (CLAUDE_CODE_USE_BEDROCK=1, region us-east-1)