claude-code - 💡(How to fix) Fix [BUG] Edit/Write "File has not been read yet" error causes ~17% of cases to halt the agent turn, requiring user "continue" [1 comments, 2 participants]

Preflight Checklist

• I have searched existing issues
• This is a single bug report
• 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.
2. Harness-side: persist "file has been read" state across context compaction and propagate it to subagents.
3. 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)