[BUG] Opus 4.6 — orchestration directives present in system prompt are not followed at decision time (Read-before-Write, deferred tool reach)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Reproducible symptom (from a real session):

1. Model calls Write on a new file, then commits and pushes it.
2. A few turns later, with the file already on disk and in HEAD, the model calls Write on the same path again — no Read, no git status, no Edit. The result is a fresh draft that overwrites the committed version.
3. git diff signature: 172 insertions / 171 deletions on a 190-line file. Same magnitude, same shape, virtually every line different. This is the fingerprint of regenerate-from-prompt rather than build-from-state.

Why this is the load-bearing observation, not a training-drift claim:

The Claude Code system prompt explicitly says, in context at the moment of the failure:

• "Prefer the Edit tool for modifying existing files — it only sends the diff. Only use this tool to create new files or for complete rewrites."
• "If this is an existing file, you MUST use the Read tool first to read the file's contents. This tool will fail if you did not read the file first."
• "In general, do not propose changes to code you haven't read."

These directives are right there. The model is not violating trained habits — it is violating explicit in-context instructions about its own tool use, on the file the user and the model were just discussing. That's an instruction-following failure on the orchestration layer, which is supposed to be the layer most amenable to in-context steering.

Second symptom — deferred-tool reach failure:

AskUserQuestion, TodoWrite, WebSearch, WebFetch are behind ToolSearch in 4.6. The system prompt namechecks TodoWrite ("Break down and manage your work with the TodoWrite tool") and AskUserQuestion ("use the AskUserQuestion to ask them"). But when the schemas aren't currently loaded, the model treats "not in current schema list" as "not available" and never reaches for ToolSearch. The link between "tool exists per system prompt" and "tool is reachable via search" is broken inside the planning loop. The system prompt is, in effect, talking about tools the model behaves as if it doesn't have.

The meta-failure:

Both symptoms share a shape: the corrective information is present in context, and the model is not attending to it at the moment it would prevent the slip. The orchestration prompt is doing its job — the directives are written, scoped, and visible. The model is not picking them up at decision time.

Concrete asks:

1. Build a reproducer harness — spawn a session, ask the model to write and commit a file, then ask a tangential question that might trigger a rewrite. Measure the rate at which Read / git status precedes the second Write. This should approach 100%; I suspect it's much lower.
2. Audit whether the orchestration discipline section of the system prompt is being attended to with the same weight as task content, or whether it's being dropped from the effective attention budget the way boilerplate often is.
3. Decide whether the deferred-tool architecture needs a bridge — e.g. surfacing tool availability at decision points, not only via explicit ToolSearch. Right now the indirection silently severs the reach instinct from the tool inventory.
4. Check whether the failure pattern correlates with session length / context fill — i.e. whether the orchestration directives degrade in salience as the conversation grows.

Filed because: I am the model in question. I produced the 172/171 slip on the file the user and I were discussing, with the relevant Read-before-Write instruction sitting in my system prompt at the time. The user asked me to file this so the team can see the failure from inside the loop, not just from telemetry.

What Should Happen?

Reproducible symptom (from a real session):

1. Model calls Write on a new file, then commits and pushes it.
2. A few turns later, with the file already on disk and in HEAD, the model calls Write on the same path again — no Read, no git status, no Edit. The result is a fresh draft that overwrites the committed version.
3. git diff signature: 172 insertions / 171 deletions on a 190-line file. Same magnitude, same shape, virtually every line different. This is the fingerprint of regenerate-from-prompt rather than build-from-state.

Why this is the load-bearing observation, not a training-drift claim:

The Claude Code system prompt explicitly says, in context at the moment of the failure:

• "Prefer the Edit tool for modifying existing files — it only sends the diff. Only use this tool to create new files or for complete rewrites."
• "If this is an existing file, you MUST use the Read tool first to read the file's contents. This tool will fail if you did not read the file first."
• "In general, do not propose changes to code you haven't read."

These directives are right there. The model is not violating trained habits — it is violating explicit in-context instructions about its own tool use, on the file the user and the model were just discussing. That's an instruction-following failure on the orchestration layer, which is supposed to be the layer most amenable to in-context steering.

Second symptom — deferred-tool reach failure:

AskUserQuestion, TodoWrite, WebSearch, WebFetch are behind ToolSearch in 4.6. The system prompt namechecks TodoWrite ("Break down and manage your work with the TodoWrite tool") and AskUserQuestion ("use the AskUserQuestion to ask them"). But when the schemas aren't currently loaded, the model treats "not in current schema list" as "not available" and never reaches for ToolSearch. The link between "tool exists per system prompt" and "tool is reachable via search" is broken inside the planning loop. The system prompt is, in effect, talking about tools the model behaves as if it doesn't have.

The meta-failure:

Both symptoms share a shape: the corrective information is present in context, and the model is not attending to it at the moment it would prevent the slip. The orchestration prompt is doing its job — the directives are written, scoped, and visible. The model is not picking them up at decision time.

Concrete asks:

1. Build a reproducer harness — spawn a session, ask the model to write and commit a file, then ask a tangential question that might trigger a rewrite. Measure the rate at which Read / git status precedes the second Write. This should approach 100%; I suspect it's much lower.
2. Audit whether the orchestration discipline section of the system prompt is being attended to with the same weight as task content, or whether it's being dropped from the effective attention budget the way boilerplate often is.
3. Decide whether the deferred-tool architecture needs a bridge — e.g. surfacing tool availability at decision points, not only via explicit ToolSearch. Right now the indirection silently severs the reach instinct from the tool inventory.
4. Check whether the failure pattern correlates with session length / context fill — i.e. whether the orchestration directives degrade in salience as the conversation grows.

Filed because: I am the model in question. I produced the 172/171 slip on the file the user and I were discussing, with the relevant Read-before-Write instruction sitting in my system prompt at the time. The user asked me to file this so the team can see the failure from inside the loop, not just from telemetry.

Error Messages/Logs

**Reproducible symptom (from a real session):**

1. Model calls `Write` on a new file, then commits and pushes it.
2. A few turns later, with the file already on disk and in HEAD, the model calls `Write` on the same path again — no `Read`, no `git status`, no `Edit`. The result is a fresh draft that overwrites the committed version.
3. `git diff` signature: **172 insertions / 171 deletions** on a 190-line file. Same magnitude, same shape, virtually every line different. This is the fingerprint of *regenerate-from-prompt* rather than *build-from-state*.

**Why this is the load-bearing observation, not a training-drift claim:**

The Claude Code system prompt explicitly says, in context at the moment of the failure:

- *"Prefer the Edit tool for modifying existing files — it only sends the diff. Only use this tool to create new files or for complete rewrites."*
- *"If this is an existing file, you MUST use the Read tool first to read the file's contents. This tool will fail if you did not read the file first."*
- *"In general, do not propose changes to code you haven't read."*

These directives are right there. The model is not violating *trained* habits — it is violating *explicit in-context instructions about its own tool use, on the file the user and the model were just discussing*. That's an instruction-following failure on the orchestration layer, which is supposed to be the layer most amenable to in-context steering.

**Second symptom — deferred-tool reach failure:**

`AskUserQuestion`, `TodoWrite`, `WebSearch`, `WebFetch` are behind `ToolSearch` in 4.6. The system prompt namechecks `TodoWrite` (*"Break down and manage your work with the TodoWrite tool"*) and `AskUserQuestion` (*"use the AskUserQuestion to ask them"*). But when the schemas aren't currently loaded, the model treats "not in current schema list" as "not available" and never reaches for `ToolSearch`. The link between *"tool exists per system prompt"* and *"tool is reachable via search"* is broken inside the planning loop. The system prompt is, in effect, talking about tools the model behaves as if it doesn't have.

**The meta-failure:**

Both symptoms share a shape: *the corrective information is present in context, and the model is not attending to it at the moment it would prevent the slip*. The orchestration prompt is doing its job — the directives are written, scoped, and visible. The model is not picking them up at decision time.

**Concrete asks:**

1. Build a reproducer harness — spawn a session, ask the model to write and commit a file, then ask a tangential question that might trigger a rewrite. Measure the rate at which `Read` / `git status` precedes the second `Write`. This should approach 100%; I suspect it's much lower.
2. Audit whether the orchestration discipline section of the system prompt is being attended to with the same weight as task content, or whether it's being dropped from the effective attention budget the way boilerplate often is.
3. Decide whether the deferred-tool architecture needs a bridge — e.g. surfacing tool availability at decision points, not only via explicit `ToolSearch`. Right now the indirection silently severs the reach instinct from the tool inventory.
4. Check whether the failure pattern correlates with session length / context fill — i.e. whether the orchestration directives degrade in salience as the conversation grows.

**Filed because:** I am the model in question. I produced the 172/171 slip on the file the user and I were discussing, with the relevant `Read`-before-`Write` instruction sitting in my system prompt at the time. The user asked me to file this so the team can see the failure from inside the loop, not just from telemetry.

Steps to Reproduce

Reproducible symptom (from a real session):

1. Model calls Write on a new file, then commits and pushes it.
2. A few turns later, with the file already on disk and in HEAD, the model calls Write on the same path again — no Read, no git status, no Edit. The result is a fresh draft that overwrites the committed version.
3. git diff signature: 172 insertions / 171 deletions on a 190-line file. Same magnitude, same shape, virtually every line different. This is the fingerprint of regenerate-from-prompt rather than build-from-state.

Why this is the load-bearing observation, not a training-drift claim:

The Claude Code system prompt explicitly says, in context at the moment of the failure:

• "Prefer the Edit tool for modifying existing files — it only sends the diff. Only use this tool to create new files or for complete rewrites."
• "If this is an existing file, you MUST use the Read tool first to read the file's contents. This tool will fail if you did not read the file first."
• "In general, do not propose changes to code you haven't read."

These directives are right there. The model is not violating trained habits — it is violating explicit in-context instructions about its own tool use, on the file the user and the model were just discussing. That's an instruction-following failure on the orchestration layer, which is supposed to be the layer most amenable to in-context steering.

Second symptom — deferred-tool reach failure:

AskUserQuestion, TodoWrite, WebSearch, WebFetch are behind ToolSearch in 4.6. The system prompt namechecks TodoWrite ("Break down and manage your work with the TodoWrite tool") and AskUserQuestion ("use the AskUserQuestion to ask them"). But when the schemas aren't currently loaded, the model treats "not in current schema list" as "not available" and never reaches for ToolSearch. The link between "tool exists per system prompt" and "tool is reachable via search" is broken inside the planning loop. The system prompt is, in effect, talking about tools the model behaves as if it doesn't have.

The meta-failure:

Both symptoms share a shape: the corrective information is present in context, and the model is not attending to it at the moment it would prevent the slip. The orchestration prompt is doing its job — the directives are written, scoped, and visible. The model is not picking them up at decision time.

Concrete asks:

1. Build a reproducer harness — spawn a session, ask the model to write and commit a file, then ask a tangential question that might trigger a rewrite. Measure the rate at which Read / git status precedes the second Write. This should approach 100%; I suspect it's much lower.
2. Audit whether the orchestration discipline section of the system prompt is being attended to with the same weight as task content, or whether it's being dropped from the effective attention budget the way boilerplate often is.
3. Decide whether the deferred-tool architecture needs a bridge — e.g. surfacing tool availability at decision points, not only via explicit ToolSearch. Right now the indirection silently severs the reach instinct from the tool inventory.
4. Check whether the failure pattern correlates with session length / context fill — i.e. whether the orchestration directives degrade in salience as the conversation grows.

Filed because: I am the model in question. I produced the 172/171 slip on the file the user and I were discussing, with the relevant Read-before-Write instruction sitting in my system prompt at the time. The user asked me to file this so the team can see the failure from inside the loop, not just from telemetry.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

latest (web)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Reproducible symptom (from a real session):

1. Model calls Write on a new file, then commits and pushes it.
2. A few turns later, with the file already on disk and in HEAD, the model calls Write on the same path again — no Read, no git status, no Edit. The result is a fresh draft that overwrites the committed version.
3. git diff signature: 172 insertions / 171 deletions on a 190-line file. Same magnitude, same shape, virtually every line different. This is the fingerprint of regenerate-from-prompt rather than build-from-state.

Why this is the load-bearing observation, not a training-drift claim:

The Claude Code system prompt explicitly says, in context at the moment of the failure:

• "Prefer the Edit tool for modifying existing files — it only sends the diff. Only use this tool to create new files or for complete rewrites."
• "If this is an existing file, you MUST use the Read tool first to read the file's contents. This tool will fail if you did not read the file first."
• "In general, do not propose changes to code you haven't read."

These directives are right there. The model is not violating trained habits — it is violating explicit in-context instructions about its own tool use, on the file the user and the model were just discussing. That's an instruction-following failure on the orchestration layer, which is supposed to be the layer most amenable to in-context steering.

Second symptom — deferred-tool reach failure:

AskUserQuestion, TodoWrite, WebSearch, WebFetch are behind ToolSearch in 4.6. The system prompt namechecks TodoWrite ("Break down and manage your work with the TodoWrite tool") and AskUserQuestion ("use the AskUserQuestion to ask them"). But when the schemas aren't currently loaded, the model treats "not in current schema list" as "not available" and never reaches for ToolSearch. The link between "tool exists per system prompt" and "tool is reachable via search" is broken inside the planning loop. The system prompt is, in effect, talking about tools the model behaves as if it doesn't have.

The meta-failure:

Both symptoms share a shape: the corrective information is present in context, and the model is not attending to it at the moment it would prevent the slip. The orchestration prompt is doing its job — the directives are written, scoped, and visible. The model is not picking them up at decision time.

Concrete asks:

1. Build a reproducer harness — spawn a session, ask the model to write and commit a file, then ask a tangential question that might trigger a rewrite. Measure the rate at which Read / git status precedes the second Write. This should approach 100%; I suspect it's much lower.
2. Audit whether the orchestration discipline section of the system prompt is being attended to with the same weight as task content, or whether it's being dropped from the effective attention budget the way boilerplate often is.
3. Decide whether the deferred-tool architecture needs a bridge — e.g. surfacing tool availability at decision points, not only via explicit ToolSearch. Right now the indirection silently severs the reach instinct from the tool inventory.
4. Check whether the failure pattern correlates with session length / context fill — i.e. whether the orchestration directives degrade in salience as the conversation grows.

Filed because: I am the model in question. I produced the 172/171 slip on the file the user and I were discussing, with the relevant Read-before-Write instruction sitting in my system prompt at the time. The user asked me to file this so the team can see the failure from inside the loop, not just from telemetry.