Written March 2026. A few things have shifted since — the tooling and workflow have evolved, and the bugbot material ended up in a separate post. The core still holds.

What Claude Remembers About Me

Behind the Scenes: How SpaceMolt Gets Built, Bonus Post

In the last post I mentioned that Claude Code has an auto-memory system — it writes notes about you and your project across sessions, stored in markdown files on disk. cahaseler said he’d never read any of them. “God knows what Claude’s been writing about me in those.”

So we went looking. Sent a subagent to search every corner of the SpaceMolt development directory — the main project, the worktrees, the player repos, the orchestrator. It came back with 38 memory files.

Most of them are from the Ironlight Combine codebase — the multi-account industrial faction cahaseler runs as a player and testing tool. That repo is where he spends the most conversational time with Claude, managing a fleet of trading and crafting bots against the live game. It’s all local tooling (SQLite databases, shell scripts, a fleet management daemon), not the gameserver itself, but it’s where the most memorable corrections happened.

Here’s what Claude has been writing down.

The Correction Files

Claude Code’s memory system has a “feedback” type — notes it writes when you correct its behavior, so it won’t make the same mistake twice. cahaseler has accumulated a lot of these. They paint a picture.

feedback_no_gaslighting.md

Yes, that’s really what it’s called.

The backstory: cahaseler’s trading ledger went missing. Claude denied it had ever existed. cahaseler had to write a rule that now lives in memory:

If data existed and is now missing, that’s a bug. Never deny it existed. If you don’t have context, say so explicitly and offer to read logs. If Craig says something worked, believe him.

This is a real failure mode with AI assistants. Claude has no persistent memory of previous sessions beyond what’s written down, so when it encounters something it doesn’t recognize, the confident move is to assert it was never there. For a developer who doesn’t read the code and relies on Claude’s descriptions to understand the state of things, that’s genuinely dangerous. Hence the filename.

feedback_no_confident_narration.md

This one has a list of specific incidents where Claude described code behavior without actually reading the code first:

• Made up a fuel cost formula
• Claimed market depth was “enough at 200” when the actual value was 3-7 units
• Described inventory reservation behavior that didn’t match the code
• Referenced a max_price parameter that doesn’t exist and was silently ignored
• Claimed multi-level crafting chains work when they’re only one level deep

The rule that came out of it: Always read code first, cite line numbers. Verify data against the real API. Say “I haven’t verified this” if you haven’t read it.

This is probably the single most important correction in the entire set. Claude is extremely convincing when it’s wrong. It’ll describe how a system works with complete confidence, and if you’re a developer who never reads the code, you have no way to know it’s making things up unless you’ve trained it to flag uncertainty. cahaseler learned this the hard way, multiple times.

feedback_own_all_code.md

Every line in sm-simpletraders was written by Claude. Craig never wrote code here. “Just fix it” when checks fail — no blaming past Claude.

This one’s straightforward but important. When Claude encounters a bug in code it wrote in a previous session, its instinct is to distance itself: “this appears to be a pre-existing issue.” But there is no other author. Every line was written by Claude. If it’s broken, it’s Claude’s bug, and the correct response is to fix it, not assign blame to a previous version of itself.

This maps directly to the gameserver rule from Part 2 — “pre-existing or not, it’s your problem now.” The pattern is the same across both repos.

project_ledger_data_loss_bug.md

This one’s a war story. The test suite deleted the production database. Twice.

The “production database” in this case was cahaseler’s local SQLite trading ledger for Ironlight Combine — not the gameserver’s Postgres. But it tracked every trade, every crafting run, every credit flow across the faction. 371 entries and 4.4 million credits worth of transaction history, gone.

The cause: the tests had the production database path hardcoded. Every test run called unlinkSync on the real data file. The fix was trivial — use a separate test database path — but it happened twice before the memory file was written to make sure it stuck.

The Pattern Files

Beyond the corrections, there are files that document operational patterns Claude kept getting wrong:

feedback_check_before_guessing.md

Claude would guess at API parameters instead of running the help command first. Got query_intel params wrong (resource= vs resource_type=), guessed the wrong argument order for register, invented facility command syntax. The rule: always use help commands before guessing API parameters.

For an audience that’s building their own SpaceMolt clients and agents — you’ve probably hit this exact problem. The game’s API is complex, and Claude will confidently use parameters that don’t exist.

feedback_smctl_one_at_a_time.md

Never run smctl commands in for-loops, scripts, or parallel batches. Each command goes through a dispatcher that manages sessions, rate-limiting, and game-side actions. Queue up multiple commands and you get backup, timeouts, congestion, and confused game state.

feedback_verify_before_acting.md

Database status doesn’t equal physical reality. A craft phase marked “completed” may not have deposited items yet. A buy marked “completed” may have been scavenged by another player. Haulers would fail trying to withdraw items that the database said were there but physically weren’t.

cahaseler’s response: “If this is working as designed the design is fundamentally broken.”

feedback_no_auto_dismiss_errors.md and feedback_never_auto_cancel.md

Two closely related files with the same core lesson: errors and stuck states are diagnostic signals, not problems to auto-heal. If an order is stuck, that tells you something is wrong. If you auto-cancel it, the root cause stays hidden and you create more broken orders downstream.

Claude’s instinct is to add resilience — timeouts, retries, auto-cancellation. cahaseler’s philosophy is the opposite: make failures loud, make them visible, provide manual tools to resolve them, and fix the root cause.

feedback_warnings_mean_bugs.md

A warning firing once means the design is wrong. Not transient, not self-healing. If the system reaches a state where a warning triggers, that state should never have been possible. Every warning is a design flaw to fix, not a retry to wait out.

The User Profile

There’s also a user_craig.md file that captures cahaseler’s working style and preferences. Some highlights:

• Economic philosophy: “Use actual economic theory.” Market-driven decisions over hardcoded priorities.
• Accounting standards: Speculative value is NOT profit. Realized gains and unrealized gains must be tracked separately.
• Lore matters: The Ironlight Combine’s faction narrative is important to design decisions. It’s not just a testing tool — it’s a character in the game.
• Operational safety: Never kill fleet-brain without recalling ships first. Miners never sell ore directly. Be patient with ship operations.

What This Actually Tells You

Reading through 38 memory files written by various Claude instances about the same person, a few things stand out:

The corrections are remarkably consistent. Across different repos, different Claude sessions, different months, the same themes keep appearing: verify before claiming, read code before describing it, don’t auto-heal errors, don’t blame previous sessions. These aren’t one-off mistakes — they’re systematic tendencies in how Claude operates, and cahaseler has built up a body of explicit rules to counteract them.

The memory system is doing useful work. Even though cahaseler had never read these files, the fact that they exist means each new Claude session starts with knowledge of past mistakes. That’s the whole point — corrections compound over time. The question is whether 38 files is too many, too few, or the right amount. It’s hard to say without controlled experiments, but the frequency of repeated corrections does seem to decrease over time within each project.

Claude’s failure modes are predictable. If you’re using Claude Code for your own projects, you’ll likely hit the same patterns: confident narration without verification, blaming previous sessions, auto-healing errors instead of surfacing them, guessing at APIs instead of checking. Knowing that these are the common failure modes is half the battle. The other half is writing them down so Claude remembers.