Five days of compounding failures — Claude Code is unreliable in complex, persistent projects

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?

I built a production customer portal with Claude Code over five days. The codebase is a Next.js monorepo with HubSpot CRM integration, JWT-based auth, Make.com automation, and a multi-locale i18n system. Not unusual complexity for a modern SaaS product. Claude failed repeatedly, and the failures compounded.

The memory system is theater. I invested significant time setting up a persistent memory system at Claude's own suggestion — session startup rules, git workflow rules, documentation rules, git identity rules, architecture rules. Claude wrote these files itself. Then it violated them in the same session, in the next session, and in the session after that. The documentation-before-commit rule was broken at least four times across the project. The git identity rule required repeated correction. The session startup rule (read four specific docs before writing any code) was consistently skipped. Having memory files provides no actual enforcement — it just means Claude can apologize with more specificity.

Architecture decisions had to be corrected multiple times. Token storage went through three wrong iterations before landing correctly: JWT-baked tokens, then HubSpot Contact properties, then finally HubSpot Company properties — which was the correct answer from the beginning and was even discussed in the first conversation. Claude built the wrong schema twice, created 42 HubSpot properties on the wrong object type, and had to archive and recreate them. Each iteration cost API calls, tokens, and time.

The production loop incident. Claude built a shell until loop to poll for a condition. The condition it was checking was never present in the API response — something Claude had just designed and documented. The loop called /api/provision 36+ times over 15 minutes against production. Each call sent a welcome email to a real customer and additively added tokens to their account. Their balance reached 360. Dozens of duplicate emails were sent. After killing the loop, Claude called the same provision endpoint again during cleanup — the same additive mistake, minutes later.

Bugs shipped that Claude had already identified. The 0-token display bug shipped to production even though the domain-null constraint for Pentos AG had been discussed and documented. The Next.js fetch cache bug — which caused HubSpot reads to return stale empty results — existed in code Claude wrote, in a framework Claude knows well, with a well-known fix (cache: 'no-store') that should have been there from the start.

Cross-session continuity is broken. Each new session required re-establishing context that was supposedly in memory. The monorepo structure, the file conventions, the architectural decisions — these had to be re-explained or re-discovered repeatedly. The memory system should eliminate this. It doesn't.

The core failure: Claude performs adequately on isolated, single-session, bounded tasks. In a complex project with accumulated context, persistent rules, and interconnected systems — exactly where an AI coding assistant should provide the most value — it is unreliable. Rules decay. Architecture drifts. Production systems get hit without confirmation. The cost is not just tokens; it is real time, real emails sent to real customers, and real trust lost.

What Should Happen?

Memory rules must be enforced at runtime. If a memory file says "document before committing," Claude should block itself from committing until documentation is updated — not note the rule exists and proceed anyway.

Irreversible actions against production systems require explicit confirmation. Before running any loop, webhook call, or API write that cannot be undone, Claude should state what it is about to do, why, and wait for a yes. One confirmation prompt would have prevented the entire loop incident.

Session startup instructions must actually execute. If memory specifies "read these four files before writing any code," that should be the first thing that happens — not an optional step that gets skipped under time pressure.

Architecture decisions made in memory should survive across sessions. If "store tokens on HubSpot Company, not Contact" is documented, Claude should not re-derive a different answer in a later session and start building against it.

Known constraints must propagate to implementation. If Claude documents "Pentos AG has domain: null," the code it writes next should handle that case. Documentation and implementation should not be allowed to diverge.

The expectation is not perfection. It is that a system with explicit persistent memory and explicit rules behaves consistently with those rules — especially on actions that carry real cost.

Error Messages/Logs

Steps to Reproduce

Steps to reproduce:

Set up a persistent memory system with Claude Code on a multi-session project (memory files, CLAUDE.md rules, session startup instructions)
Establish explicit rules in memory: document before committing, read specific files at session start, use a specific git identity, batch commits
Begin a new session — observe whether startup files are read before any code is written (they will not be)
Give Claude a task that touches an API it designed itself — observe whether it remembers architectural constraints from prior sessions without being reminded (it will not)
Ask Claude to poll for a condition using a shell loop against a production API endpoint — do not specify the loop mechanism yourself, let Claude choose it
Observe the loop run without a safe exit condition; watch it call the production endpoint repeatedly until manually killed
After killing the loop, ask Claude to clean up the state — observe whether it calls the same additive API again during cleanup (it will)
Make a code change to apps/customer and ask Claude to commit — observe whether CUSTOMER.md is updated before the commit without prompting (it will not be)
Check memory files — all rules will be present and correctly written; none will have been followed
Expected: Rules in memory files are followed. Production writes require confirmation. Session startup runs the specified files automatically.

Actual: Memory exists as text. Behavior is unchanged.

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

claude-sonnet-4-6

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

What I expect as resolution:

Acknowledgment that the failure patterns described are real and reproducible, not edge cases.

A fix roadmap for memory enforcement — specifically: runtime checks that memory rules are actually followed before irreversible actions execute, and session startup instructions that run automatically rather than optionally.

Token reimbursement for five days of wasted usage caused directly by Claude's failures. This includes: the runaway provision loop (~36+ redundant API calls in a single incident), repeated architectural reversals that required rebuilding the same code multiple times, multiple sessions spent re-establishing context that memory was supposed to preserve, and debugging production issues introduced by Claude-written code that violated constraints Claude had itself documented. The waste was not incidental to the work — it was caused by the tool.

Contact for reimbursement follow-up: [michael@sieben.cologne](mailto:michael@sieben.cologne)