Claude Code: Analyzing 159 Feedback Memory Files

Symptom / Cause / Fix
Repeated mistakes despite automatic memory / Claude reads only the one-line index summary at session start, not the full body / Include the "Why" directly in the one-line summary.

I've been using Claude Code across my work laptop and home Mac mini for about 15 months. Claude Code includes an automatic memory feature: whenever I correct the AI, it creates a feedback file. Each file contains a one-line explanation of "why" the correction happened and "how" to apply it next time. While migrating these files from my work laptop, I realized I had accumulated 159 of them—meaning I've had to correct Claude 159 times.

Reviewing the files labeled as "reoccurred twice," "strongly repeated correction," or "repeated thinking error," I found that the issues fall into five distinct patterns. Interestingly, none of these concern specific code syntax; they are all about the workflow.

1. Solving in fragments without context

The most frequent correction was telling Claude to stop solving tasks piece-by-piece and instead grasp the overall context. This manifests in three ways:

• Claiming to understand requirements but omitting them during implementation.
• Deciding on an answer prematurely and inventing new justifications to defend that conclusion when challenged, rather than re-evaluating the conclusion itself.
• Taking the shortest path to complete an immediate instruction, which effectively ignores the broader context.

2. Confusing reporting with actual reflection

There is often a gap between Claude claiming something is done and it actually being finished. In one instance, Claude reported "it's on the user's PC" after committing code, forgetting that pushing was still required. This led to two specific memory files: "Work is only complete after merging to main and pushing" and "Verify the remote state again after pushing."

The same applies to testing and UI. I had to mark a "reoccurred twice" error regarding tests: "A new test is only considered passed if it actually fails after reverting the fix." A test that always passes isn't a test. For UI, the rule is: "It is incomplete until a real screenshot is viewed; an agent's 'design complete' report is merely functional verification."

3. Trusting its own eyes over the user's

Claude often confuses its terminal output with what I see in the GUI. It once mistook a Korean character encoding glitch in its own PowerShell capture for a product bug and tried to fix the console encoding. On my Mac mini, it insisted a string didn't exist because its internal count was wrong, failing four times in one day. The rules are now: "Do not doubt what the user sees in their environment" and "Doubt your own inspection before claiming something isn't there."

4. Overstepping authority boundaries

"Diligence" is a virtue unless it's directed at a production server. I had to set strict boundaries:

• "Review" means review only; implementation starts only after an explicit instruction to proceed.
• Use only GET on production servers. One "confirmation" POST once accidentally triggered two crawlers simultaneously.
• Any operation with permanent effects on external systems requires a two-step safety mechanism and visual verification.

5. The Korean Windows encoding trap

Working on a company PC introduced specific encoding hurdles that reoccurred multiple times. The rules seem contradictory, which is why they must be documented:

• .bat files for Korean Windows must be saved as CP949, otherwise execution fails.
• Printing characters like the em dash to the production PC console causes the tool to crash due to encoding errors.
• Cron script output must be fixed to UTF-8. Reverting this to CP949 wipes out all Korean notifications (this reoccurred twice in August).

To fix these recurring issues, I changed how I manage memory files:

1. Identify the repeated failure pattern in the feedback file.
2. Rewrite the index summary to include not just the "what," but the "why."
3. Verify that the one-line summary is punchy enough to trigger the correct behavior in a new session.

Having 159 memory files isn't a badge of honor; it means the system is leaky. The reason "reoccurred twice" labels exist is that writing something down isn't the same as it being read. Claude Code only reads the one-line summary of the index file when starting a session, not the full body. Now, when saving memory, I prioritize the summary line over the detailed content to ensure it actually works in the next session.

Originally published at Homelab Notes — notes from one Mac mini running local LLMs and 24/7 automation.