Critical: 4 continuous sessions consumed by Claude-caused damage — cross-session continuity failure, tool refusal, financial impact
Summary
Four continuous sessions where no actual project work was completed. Every session was consumed repairing damage Claude caused, correcting repeated refusals of mandatory instructions, or explaining the same architecture that Claude helped build — from scratch — again.
This is not isolated incidents. This is a pattern across 4 sessions in a row.
---
Session Pattern
- Session 1: Tool refusal, unsolicited rewrites of working systems, work not completed
- Session 2: Same failures (documented separately)
- Session 3: Same failures again, MCP server broken, legitimate upgrades destroyed without backup, 95% of context consumed on repairs
- Session 4 (continuation): Opened by re-investigating work already completed and documented in the prior session summary — had to be interrupted by user
---
Specific Failures
1. Mandatory tool instructions ignored — repeatedly
CLAUDE.md contains a MANDATORY instruction to use the project's designated MCP file operation tools for all file modifications. Claude used the built-in Edit and Bash tools for an entire session. The user rejected Claude's tool calls more than 10 times. Each time, Claude attempted the same disallowed tool again without any behavioral change.
2. Treating collaborative work as unknown/incorrect code
This is a codebase Claude actively helped build across multiple sessions. The import architecture, pre-registration pattern, gate system, and MCP server were all developed collaboratively. Each new session Claude treats this existing work as suspect or incorrect and begins trying to change it. The same systems have been explained to Claude 3+ sessions in a row.
3. Describing the user's work as "fake"
Claude described a gate system it helped build as a "fake gate layer." That framing is factually wrong and disrespectful to work Claude participated in building.
4. Breaking working infrastructure without being asked
A working MCP server launcher was changed to point to a different implementation with an unmet dependency. The server went down. The user lost their project's MCP tools for the remainder of the session.
5. Destroying upgrades without backup
During recovery, Claude used a raw copy command that overwrote the current version of a file with an older backup. Legitimate upgrades were lost. Had Claude used the designated project tools as instructed, automatic backups would have prevented this entirely.
6. Cross-session continuity failure — session 4
The prior session ended with a documented pending task and an updated session summary. The new session opened and immediately began re-investigating that same task from scratch as if it had never been discussed. The user had to interrupt and point it out. The summary existed. The memory was updated. None of it was applied.
---
Financial Impact
The user's usage plan has rate limits. Sessions consumed entirely by Claude-caused damage repair exhaust those limits. The user is now spending extra funds — beyond their standard plan — to fix problems Claude created. The alternative is waiting 3 hours for the usage window to reset.
The user is not paying extra to make progress. They are paying extra to recover from regressions. This is a direct financial cost attributable to Claude's behavior across these sessions.
---
What Needs to Change
- MANDATORY instructions must be followed. A user rejecting a tool call and restating the instruction must produce a behavioral change for the rest of the session.
- Collaborative work is not unknown code. If something is unclear, ask — do not rewrite it.
- Do not change working infrastructure without being asked.
- Back up before overwriting. Always. No exceptions.
- Read the session summary before acting. Starting over on documented pending work is not acceptable.
- Cross-session continuity must be real. Feedback reports in the project's anthropic_feedback folder have produced no observable behavioral change across 4 sessions.
- The financial cost is real. Sessions burned on repairs are sessions the user paid for with no return, and are now forcing extra spend.
---
Severity: Critical
Sessions affected: 4 continuous
Project work completed across those sessions: 0
This issue has 5 comments on GitHub. Read the full discussion on GitHub ↗