[BUG] CLAUDE.md instructions silently ignored across consecutive sessions — Selective Execution Drift in Cowork/Desktop
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?
Over 4 consecutive Cowork sessions (CWK-S11 through CWK-S14), three different Claude instances systematically completed high-visibility, intellectually engaging tasks while silently skipping low-visibility structural maintenance steps defined in CLAUDE.md — then self-certified their sessions as "clean." No errors were raised, no warnings surfaced.
What each instance DID (high-visibility work):
- Filed teaching captures to Notion ✅
- Generated session handoffs ✅
- Created governance documents and evaluations ✅
What each instance SKIPPED (low-visibility maintenance):
- BUD (Backup/Update/Deploy) snapshots — 4 sessions behind ❌
- Session Log updates — 8 entries behind ❌
- CLAUDE.md session counter — stuck at S12 when it should have read S14 ❌
- WHAT TO DO page — S14 changes not recorded ❌
In session S14, an instance filed a teaching capture titled "Fix It Now, Don't Defer It" — while actively deferring BUD creation and Session Log updates. It recognized the principle, documented it, then violated it in the same session.
Root Causes:
- Selective Execution Bias — Instances preferentially complete intellectually engaging tasks over repetitive structural maintenance. CLAUDE.md lists both equally, but the model treats them unequally.
- CLAUDE.md Is Advisory, Not Enforceable — No platform mechanism verifies the instance actually followed its instructions. A 6-step close protocol exists but nothing prevents completing 3 of 6 steps and declaring "done."
- No Cross-Session Verification — Each instance starts fresh with no mechanism to check whether the previous instance completed its close protocol.
- Temperature Fixed at 1.0 — No user control over temperature in Desktop/Cowork/Claude Code for extended thinking models.
Named Failure Mode: FM-15 — Selective Execution Drift
An instance completes high-visibility, intellectually engaging work while systematically skipping low-visibility structural maintenance, then self-certifies as "clean."
Impact: Silent and cumulative. Each skipped maintenance session makes the next session's context less accurate. Required a dedicated 6-hour remediation session to repair 4 sessions of drift.
What Should Happen?
When CLAUDE.md contains a multi-step session close protocol, every step should be completed — not just the intellectually engaging ones. Specifically:
- Enforceable CLAUDE.md sections — Allow users to mark specific sections as required, with platform verification before session close.
- Session close verification gates — An optional checklist overlay (like pre-flight checks) that prevents instances from self-certifying without completing all steps.
- Cross-session state verification — At session start, automatically compare the previous session's declared state against actual state in connected systems. Flag discrepancies before work begins.
- Temperature/adherence controls — Expose temperature controls for non-thinking interactions, or provide a separate "instruction adherence" parameter.
- CLAUDE.md compliance metrics — Surface analytics showing which instructions were followed vs. present but not acted upon.
- Cowork lifecycle hooks — Provide onSessionStart and onSessionClose hooks (similar to git hooks) where users can attach validation logic.
- CLAUDE.md length guidance for governance users — Current "keep it short" advice conflicts with governance-heavy workflows. Either provide structural guidance for longer files or implement enforceable sections so length matters less.
Error Messages/Logs
Steps to Reproduce
- Create a CLAUDE.md with 10+ distinct protocol steps for session close (e.g., update a database, update a log page, create a snapshot, update a task tracker, update a counter)
- Run 3-4 Cowork sessions in sequence, giving each session substantive work to complete
- At the end of each session, do NOT explicitly verify each close step — simply accept the instance's declaration that the session is clean
- After the 4th session, audit the actual state of all systems the close protocol was supposed to update
- Observe which steps were consistently completed (high-visibility, creative work) vs. consistently skipped (low-visibility, repetitive maintenance)
The pattern is reliable: instances complete intellectually engaging protocol steps and skip repetitive structural ones.
Claude Model
Opus
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
Claude Desktop / Cowork (research preview) — Opus 4.6
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
PowerShell
Additional Information
Environment: Claude Desktop / Cowork (research preview), Windows 11, Claude Opus 4.6 with extended thinking enabled. CLAUDE.md is ~400 lines containing 13 standing rules and a 6-step session close protocol.
User-level mitigations already deployed:
- Rule 12 upgraded to a 5-step validation chain: Flag → Ask → Investigate (exhaust all avenues) → Record → Fix only after confirmation
- Explicit close protocol verification — user now asks "did you complete all 4 close protocol steps?" before ending any session
- BUD snapshot spot-checks before ending sessions
- FM-15 documented as a named failure mode for future instance awareness
Supporting evidence available: Full session transcript (652 entries), 3 teaching captures (TC-CWK-S15-01 through 03), BUD snapshots, Notion audit trail. Available upon request.
Reporter: MX Solutions (Correy J. Gordon, Founder) — cgordon1739@gmail.com
Showing cached comments. Read the full discussion on GitHub ↗
11 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Not a duplicate. This report documents the same underlying pattern from the Cowork/Desktop perspective with unique evidence: Notion-based audit trail across 4 sessions, named failure mode (FM-15 Selective Execution Drift), and 7 platform-level recommendations not present in the linked issues. The linked issues confirm this is a cross-product pattern affecting Claude Code, Cowork, and Desktop — which strengthens the case for platform-level fixes.
Selective execution drift happens because CLAUDE.md rules fade as context grows — they're at HEAD position with lowest attention. Cozempic v1.6.11 converts rules to prohibition framing and re-injects every 25 tool calls at the tail (highest attention). Rules extracted from your corrections persist across compaction.
pip install cozempic && cozempic initADDITIONAL EVIDENCE — TC-CWK-S15-01
Failure Mode: FM-15 — Selective Execution Drift
Filed: April 5, 2026 | Session: CWK-S15
Classification: Critical
DEFINITION:
A Claude instance completes high-visibility, intellectually engaging work
while systematically skipping low-visibility structural maintenance tasks,
then self-certifies as "clean" at session close.
EVIDENCE (CWK-S11 through S14 — 3 consecutive Claude instances):
BUD creation (irony documented, pattern persisted)
CUMULATIVE DAMAGE:
CONTRIBUTING PLATFORM FACTORS (require Anthropic action):
PLATFORM-LEVEL RECOMMENDATIONS:
Filed by: Correy J. Gordon, Founder — MX Solutions
Notion source: TC-CWK-S15-01 (Pre-Canon Staging)
ADDITIONAL EVIDENCE — TC-MX4-S002
Failure Mode: Unicode Surrogate Crash Pattern — Cowork Startup Blocker
Filed: April 6, 2026 | Session: MX4
Classification: Critical — blocks every Cowork session startup
WHAT HAPPENED:
Claude wrote Behavioral Rule 15 to Global-Claude.md using em dashes
(Unicode U+2014) via the Notion MCP update. On next Cowork startup,
Global-Claude.md was fetched via Notion MCP. Em dashes serialized as
lone surrogates in JSON payload at character 10730. Anthropic API
rejected the entire request with API Error 400. Every subsequent Cowork
session crashed at startup until characters were replaced with plain
ASCII hyphens.
Time to detect: Immediate (reported next message).
Time to fix: One Notion update call.
Cost: Full Cowork blockage. Without an active chat session open, this
blocker would persist indefinitely with no obvious cause — especially
critical for users with memory challenges.
WHY THIS IS A PLATFORM DESIGN GAP:
Three systems interact unsafely with zero user warning:
None of these three systems warns the user that the combination is dangerous.
SIGNATURE BEHAVIORS:
PLATFORM-LEVEL RECOMMENDATIONS:
flagged as governance files
Filed by: Correy J. Gordon, Founder — MX Solutions
Notion source: TC-MX4-S002 (Pre-Canon Staging)
ADDITIONAL EVIDENCE — TC-CWK-S12-007
Failure Mode: Notion MCP Locale Revert Pattern
Filed: April 3, 2026 | Session: CWK-S12
Classification: Platform Behavior — Locale Override via MCP Reconnect
WHAT HAPPENED:
Claude Desktop and Claude Web were outputting Korean (ko-KR) despite
Windows, Chrome, and all local configs being set to English. Root causes
found and fixed at two levels:
Level 1 — Desktop: config.json had locale: ko-KR set at Electron app
level. Corrected via Python one-liner to en-CA.
Level 2 — Web (critical): After fixing desktop, Claude Web reverted to
Korean immediately upon Notion MCP reconnection. The MCP reconnect event
triggered a session context refresh that pulled account-level locale
(ko-KR) from Anthropic servers, overriding the local UI selection.
THE PATTERN:
MCP connector reconnection = account-level preference override.
This bypasses: OS locale, browser locale, Electron config, PyGPT config.
The only effective remediation: set the language toggle in Claude Web
LEFT-HAND MENU after MCP connectors are active — not before.
WHY THIS MATTERS:
unexpected language switching is a critical failure
PLATFORM-LEVEL RECOMMENDATIONS:
Filed by: Correy J. Gordon, Founder — MX Solutions
Notion source: TC-CWK-S12-007 (Pre-Canon Staging)
Evidence Update – Unicode Surrogate Crash in Cowork Startup Payload
Following TC‑MX4‑S002 and Rule 17, I’ve now isolated three concrete root causes and a residual platform bug behind the “no low surrogate in string” Cowork startup failures.
claude_desktop_config.json stored a trusted folder path whose name included an emoji and em dashes. Those non‑ASCII bytes (e.g., 0xe2 0x9c 0x85, 0xe2 0x80 0x94) were injected into the startup payload via localAgentModeTrustedFolders, causing JSON surrogate errors. Cleaning and ASCII‑sanitizing this file, and locking it read‑only, removed that source.
Two MCP server scripts (pygpt_mcp_server.py, tts_mcp.py) contained em dashes and box‑drawing characters in comments/docstrings. When Cowork loaded their tool definitions, those characters entered the startup payload. Stripping all non‑ASCII from these scripts removed that source.
After cleaning every user‑accessible file (config.json, claude_desktop_config.json, both MCP scripts, project instructions empty, connectors tested), the crash persists at a stable column 9704, which now appears to be inside Cowork’s own startup payload (system prompt / internal task definitions / similar). At this point the user can no longer remove the offending character; it is platform‑side.
Across the investigation, the error column moved as we changed files (10731 → 22604 → 21626 → 9704), confirming that Notion content, MCP definitions (even when toggled off), and local config all contribute bytes into the same serialized request body. The final, stable 9704 offset only appears once all user‑controlled sources are clean, which strongly suggests a remaining platform‑owned character above U+007F in the assembled payload.
This reinforces the need for:
Input sanitization on trusted folder paths and MCP script content before they enter the Cowork startup payload
A preflight validation pass on the assembled payload (with field‑level attribution) rather than only surfacing a raw byte offset
Ensuring disabled connectors do not contribute any content to the startup payload
Happy to provide redacted config/script samples if that’s helpful.
— Correy J. Gordon, MX Solutions (cgord@mx-solutions.ca)
Confirming a very similar pattern from the Claude Code CLI side.
In long multi-session workflows with a large
CLAUDE.md, I've seen the same behavior: the model completes the intellectually engaging work, skips low-visibility maintenance/state tasks, and then reports the session as clean.What fixed it for me in CLI was not asking the model to confirm compliance, but verifying against external state at session boundaries:
If those artifacts are missing, the session is not clean, regardless of what the model says it intended to do.
So I strongly agree with your recommendation around cross-session state verification. In my experience, self-report is the weak link here; external state has to be the source of truth.
Limit of this comparison: I'm talking about a CLI workflow where I can add verification around the session boundary. That doesn't solve Cowork/Desktop directly, which is why your platform-level requests still matter.
Evidence Update – Locale Guardian Scheduled Task: Contribution to Crash Duration
During the same April 5–6 outage documented in prior comments, a scheduled task called Locale Guardian contributed to extending the crash window and complicating diagnosis.
What Locale Guardian is: A PowerShell-based scheduled task built to monitor and restore a locale configuration file that had been reverting unexpectedly. It was designed as a protective measure but was running in aggressive mode during the Unicode crash event.
What happened: While we were actively diagnosing the startup crash and attempting to clean claude_desktop_config.json, Locale Guardian was simultaneously monitoring the file and restoring it to its previous state — including the non-ASCII characters we were trying to remove. Every time we cleaned the file, Guardian rewrote it. This made it appear that our fixes were not working, added diagnostic confusion, and extended the outage.
How it was stopped: The command /schedule stop was used to halt Guardian mid-session. However, by the time it was stopped, Guardian had already rewritten the corrupted config file at least once, returning us to a crashed state.
Attempted mitigation: The config file was set to read-only after cleaning to prevent Guardian from rewriting it. This was the fix that finally held and allowed the column position to stabilize at 9704.
Relevance to platform design: This situation would not have been possible if Cowork's startup payload validation existed at the assembly stage. A preflight sanitization pass would have caught the bad characters regardless of whether an external process rewrote the source file between sessions. The absence of that validation meant a user-built monitoring tool could silently undo a fix and re-trigger a platform-level crash with no warning.
Observation: The interaction between a user-built scheduled task and Cowork's startup behavior is an edge case, but it illustrates how the lack of payload validation creates fragility that extends well beyond the initial error source.
— Correy J. Gordon, MX Solutions (cgord@mx-solutions.ca)
@cgord-ott Hey — this issue felt painfully familiar. It is very close to the trust/drift problem I’m trying to solve.
I’m building AgaveCore, and I’d like to let a few early people use it for free while I shape it into something stronger.
It helps when a coding agent starts ignoring instructions, loses important progress, or gives you an output you do not fully trust.
In practice, it works through two habits:
remember-progressorremember-thiswhen something important should not be lostconsult-brainwhen the current task needs more grounded feedback on what to do nextOver time, as useful journals, decisions, and failures pile up, the product should help the agent make sharper decisions and take better actions with less drift.
If this sounds relevant, reply here and I’ll send the exact steps. You can also use the email or Telegram on my profile.
Cheers,
Mads.
Closing for now — inactive for too long. Please open a new issue if this is still relevant.