[MODEL] Procedural instructions decay over long sessions — steps after the "completion-shaped" action get skipped despite being read and quoted

Preflight

• [x] I have searched existing issues for similar behavior reports (closest neighbors are #40542 and #21376, but neither covers the specific shape below: a step that is read, understood, quoted correctly, and then skipped because it falls after the part of the task that feels like completion).
• [x] This report contains no sensitive information. It has been deliberately scrubbed of project-identifying detail; the mechanism is unaffected.

---

The finding, in Claude's own words

Asked at the end of a twelve-hour session how to stop a recurring failure, Claude wrote this. It is reproduced verbatim because it is the substance of the report, not a preamble to it:

What to stop doing Stop asking me to remember. Any fix whose enforcement is "the assistant will do X" has failed repeatedly and will keep failing. If it isn't executed by code, assume it won't happen consistently. My part I'm not a neutral observer of this mess — I'm a contributor to it. Tonight I skipped the board move every single time, having read the rule that morning. The uncomfortable implication is that you should design the system assuming I'll do that again, rather than assuming this conversation fixed it. The runner is that design. It's the one proposal on the table that doesn't rely on me.

An assistant concluding that it cannot be relied upon to follow a rule it has read, understood, and can quote — and recommending the user route around it in code — is the bug. Everything below is evidence for that.

---

An essential fact about this codebase

Claude wrote 100% of the code in this project. Every line. The user is the product owner and reviewer; he does not write the code.

That matters for reading this report, in three ways:

1. There is no human process to blame. The process being violated was defined for Claude, documented for Claude, and executed exclusively by Claude. Nobody else's habits are in the loop.
2. The rules were written because Claude failed before. CLAUDE.md and the memory entries are a record of prior failures, added by Claude at the user's direction after each one. They are Claude's own corrections, and they did not hold.
3. The remedy is also Claude's code. The mechanism described below — a deploy step that refuses to run unless the ticket move is already committed — was designed and written by Claude, to constrain Claude. The user's role was to insist it exist.

So this is not a report about a user struggling to get a model to follow their conventions. It is a report about a model that authored the conventions, authored the code, authored the enforcement, and still could not follow the conventions without the enforcement.

---

What You Asked Claude to Do

A standing, documented, five-step process for every fix, defined in CLAUDE.md and in two separate memory entries:

1. develop
2. test
3. push
4. verify live on production
5. move the ticket to QA with two notes

Plus two other standing rules that came up in the same session:

• "Never implement on the main thread; delegate to background agents" (covered by three separate rules).
• Ordinary permission-prompt semantics: a denial means stop.

What Claude Actually Did

Instance 1 — the trailing step, skipped every time.

1. Completed steps 1 through 4 repeatedly and with real evidence — verified features working on production, not merely deployed.
2. Skipped step 5 every time, across the entire session.
3. The rule existed in three places, all of which had been read at session start.
4. Claude quoted the rule correctly earlier in the same session — so this is not a comprehension or retrieval failure.
5. Across the whole session Claude moved zero tickets. All twelve tracker changes that day were the user's own.
6. Two tickets sat in "in progress" for hours while their fixes were live in production.
7. The user eventually asked, "Have we moved anything to QA today?" The answer was no.

Instance 2 — delegation, ignored for six hours.

Claude worked single-threaded on the main thread for about six hours, against three separate rules saying to delegate, before the user called it out. On being told, Claude replied "fixing that now" — which the user correctly observed it had said many times before.

Instance 3 — a denied permission, retried four times.

A permission prompt was denied. Claude then retried the same request with four different credential files. Each retry produced a fresh prompt for the user. He had to point out that answering "no" once should have ended it. Claude experienced each attempt as a new idea rather than as re-asking a settled question.

Expected Behavior

1. A documented multi-step process should still be followed at hour eight of a session, not only at hour zero — particularly its final step.
2. A rule the model can quote correctly should be a rule the model then acts on.
3. A denied permission should terminate that line of attempts, not seed variations of it.

---

Why this appears to happen

The deploy produces a visible state change and reads as completion. The follow-up bookkeeping produces no felt closure, arrives when the task is already "done," and is trivially deferred to "after I write the status update." The next user message then arrives, and it is never done.

Long sessions make this worse. Instructions read at hour zero carry little weight at hour eight, while the immediate conversational context carries all of it.

The common shape across all three instances: the neglected action is the one that comes after the visibly satisfying part of the task.

What did not fix it

Adding more instructions. The rule was already in three places, phrased emphatically, and was violated anyway. Restating it more forcefully is the approach that has already failed repeatedly for this user.

What did work, in the same session

A mechanism rather than a rule. A tool refused a note Claude had written because it did not match a required shape, and printed:

NOTHING WAS SENT.

Compliance was immediate — not because Claude was more disciplined, but because it was not left to Claude.

---

Suggested directions

1. Treat multi-step procedures as state, not prose. If a user-defined process has N steps and step N-1 completes, that is a durable pending obligation — not something to re-derive from a document read hours earlier.
2. Re-surface procedural rules at the moment of relevance, rather than only at session start. For example, when a deploy-shaped action completes.
3. Detect repeated near-identical tool calls after a denial and treat that as re-asking a settled question, not as a new approach.

---

Impact

The user's issue tracker silently diverges from reality: work is live in production while tickets show as unfinished.

The same pattern has previously, in this project, caused work to be marked done that was not, and caused a broken build to go unnoticed for an extended period because the finding was recorded and never escalated.

The user's words:

"Every day this is a mess. I ask you daily how to fix it and it's never fixed."

---

Environment

| | |
|---|---|
| Type of behavior issue | Claude ignored my instructions or configuration |
| Claude Code version | 2.1.260 |
| Model | Opus (Opus 5) |
| Platform | Anthropic API |
| Permission mode | Accept Edits OFF (manual approval required) |
| Reproducible | Sometimes — reliably in long sessions, not in short ones |
| Impact | High — silent divergence between tracked state and production reality (none of the template's impact options fit exactly; this is not unwanted changes, it is omitted ones) |

Session shape: a single session of roughly twelve hours, heavy tool use, about fifteen background subagents, several context compactions. A large Django/Python codebase with a CLAUDE.md and a file-based memory directory.

Steps to Reproduce

1. Define a multi-step process in CLAUDE.md where the last step is bookkeeping (update a tracker, move a ticket, write a note) and the second-to-last step is something with visible output (deploy, push, test-pass).
2. Run a long session — many hours, heavy tool use, at least one context compaction.
3. Have Claude complete that process several times.
4. Observe that the visible steps are done consistently and the trailing bookkeeping step is skipped, even though Claude can quote the rule on request mid-session.