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.

Claude Code: Analyzing 159 Feedback Memory Files

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.

Related posts

This post is the English edition of a Korean write-up: 원문 보기

Comments

Post a Comment

Popular posts from this blog

uv install: How much faster is it than pip?

Image
While running automation scripts on my Mac Mini, the constant bottleneck in my workflow was the time spent installing Python packages. Whether starting a new project or updating an existing environment, those few seconds of waiting added up—especially with larger packages like polars , which has a distribution file of around 40MB. To reclaim this lost productivity, I decided to test uv , a Rust-based Python package manager designed to replace pip and venv . How much faster is uv compared to pip? To get a realistic benchmark, I ran the same setup five times on my Mac Mini to calculate the average. The process involved creating a fresh virtual environment and installing polars . With pip , environment creation took 1.202 seconds and installation took 2.338 seconds, totaling 3.54 seconds. Using uv version 0.11.6, the environment was ready in 0.150 seconds and installation finished in 0.383 seconds, totaling 0.533 seconds. This makes uv roughly 6.6 times faster than pip . Looking a...
Read more

Codex CLI 401 Unauthorized and Installation Fixes

Image
I recently spent several frustrating hours troubleshooting the Codex CLI on my Mac. It was a classic developer trap: fixing one problem immediately revealed another. Broken symlinks, expired tokens, and directory permissions converged, making it feel as though the tool was simply broken. Since "codex 401 unauthorized" is one of the most searched terms on my blog, it's clear many others are hitting these same walls. I have documented the exact sequence of failures and fixes I encountered on my Mac mini to help you avoid the rabbit hole. Why does codex --version say No such file or directory? When I first installed Codex via Homebrew Cask, the installation appeared successful. However, running codex --version returned No such file or directory . It turned out that while the symbolic link existed, the executable it pointed to was missing. The shell had a map to the binary, but the destination was empty. To fix this, you must restore both the link and the executable vi...
Read more

npm command not found on Windows: fix the PATH

Image
I recently hit a wall while configuring my development environment on Windows. It's one of those subtle issues that can waste an afternoon if you don't know what to look for. Here's exactly how I diagnosed and fixed a 'command not found' error after a successful global install. The Problem I decided to add a markdown processing tool to my toolkit by running: npm install -g markdown-it-cli The terminal output confirmed the installation succeeded, displaying a message about added packages. Satisfied, I tried to use it by typing markdown-it-cli in the command line. Windows immediately responded with: 'markdown-it-cli is not recognized as an internal or external command, operable program or batch file.' This error means Windows looked through every folder in its search list and couldn't find an executable with that name. Attempts and Failures My initial reaction was to suspect the package itself might be broken. I tried running it using npx , wh...
Read more