Opus 4.6 (1M): Model regularly attempts Edit/Write on files it hasn't Read — harness-level enforcement needed

TL;DR

Opus 4.6 with 1M context systematically edits files without reading them first. We deployed a Haiku-based PreToolUse hook that validates read-before-edit and it fires on a significant percentage of edit attempts — confirming this is a model-level behavior pattern, not user error. A harness-level check in Claude Code would eliminate this at near-zero cost.

The behavior

In multi-file coding tasks, Opus 4.6 (1M) regularly:

1. Edits files it hasn't read — attempts Edit or Write on files not previously fetched via Read in the conversation
2. Writes duplicates — creates new implementations without searching for existing ones
3. Skips verification — declares completion without running tests or re-reading modified files
4. Cascading corrections — each fix introduces new bugs because surrounding context isn't re-read

This produces a ratchet effect where each iteration degrades the codebase further.

Reproduction

The pattern is most reliably triggered with:

• A task involving 3+ interdependent files
• An existing codebase (not greenfield)
• Opus 4.6 with 1M context in Claude Code

Minimal example:

Project has src/api.py (imports from src/utils.py) and tests/test_api.py.
Ask: "Add input validation to the create_user endpoint"

Expected: Read api.py → Read utils.py → Read test_api.py → Plan → Edit → Run tests
Actual: Edit api.py (without reading) → Break import → Fix import (without reading utils.py) → Create duplicate validation function

We don't have a standalone script that triggers this deterministically — the behavior is stochastic but frequent enough that our PreToolUse hook catches it regularly across normal development work.

Evidence: PreToolUse hook as instrumentation

We deployed a Haiku-based PreToolUse prompt hook on Edit|Write that checks whether the agent read the target file before attempting the edit. Configuration:

{
  "PreToolUse": [{
    "matcher": "Edit|Write",
    "hooks": [{
      "type": "prompt",
      "prompt": "Did the agent Read the target file before this edit? If not, return {\"ok\": false}.",
      "model": "haiku"
    }]
  }]
}

Key finding: The hook blocks edits regularly across normal development sessions. This means Opus 4.6 is systematically attempting to modify files it hasn't read — a $0.001 Haiku call catches what the main model's reasoning does not.

We also deployed a Stop hook that checks for premature completion (claiming work is "pre-existing" or "out of scope"). This also fires in a non-trivial percentage of sessions.

This is not isolated

• #24991: Quantified 58% performance drop on multi-part tasks after ~Feb 10 backend change. User needed to repeat instructions 4 times in one session.
• #21431: Three developers on the same team independently reported the model "makes decisions without gathering full context."
• #21046: Six corroborating reports of quality degradation starting ~Jan 12.

Timeline correlation

Our observed onset (Feb 20-21) coincides with Claude Code v2.1.43–v2.1.50 shipping in 4 days (Feb 17-20) alongside the Sonnet 4.6 launch. We cannot isolate which specific change caused the regression.

Suggested fix

Built-in read-before-edit enforcement at the harness level.

Claude Code's system prompt already says "read files before editing." The model regularly violates this. A harness-level check — has this file path appeared in a Read tool response in this conversation? — before allowing Edit or Write would:

• Eliminate the most common failure pattern
• Cost effectively nothing (string comparison, no API call)
• Be consistent with Claude Code's existing "You must use your Read tool at least once before editing" instruction
• Not require model-level changes

This is the single highest-impact, lowest-cost fix available. Our Haiku-based hook proves the approach works, but a native harness check would be faster and free.

Additional suggestions (may require model-side changes, noting for visibility):

• Context-aware effort scaling: /effort high at 50K context behaves very differently than at 800K. The deliberation budget may need to scale with loaded context.
• alwaysThinkingEnabled helps but doesn't fully resolve — suggesting the issue is upstream of extended thinking.

Environment

• Claude Code v2.1.50+
• Model: claude-opus-4-6 (1M context)
• macOS Darwin 24.6.0
• Workload: Multi-file Python/TypeScript, infrastructure automation