claude-code - 💡(How to fix) Fix Surface-level fix tendency in long-running projects; previous-session directives not carrying into subsequent bug fixes

Summary

In multi-session projects, Claude Code tends to fix the bug at whichever function it surfaces in — it finds the function, makes the local change, and stops there. Connections out of that function (callers, downstream calls, parallel sibling implementations, coupled data tables) are not audited unless the user explicitly asks. A directive the user gave in an earlier session is applied for that session, but when a bug of the same kind comes up again in a later session, it is not proactively applied. Cumulative effect: surface bugs are dispatched quickly, but spreading / systemic problems continue to live across sessions, and the user effectively carries the long-term memory of the project.

Observed behavior

1. Surface-scoped fix: When a bug is seen in function F, Claude reads F, makes the local fix, and considers the work complete. Upstream functions that call F, downstream functions called from F, race/class parity siblings (e.g. 3 parallel implementations in a multi-class codebase), or coupled data tables typically remain untouched.
2. Directive decay: In session N the user says "when fixing this kind of bug, also check Y and Z, this is a project rule." Session N+1 receives the directive via memory, but applies it only when a new bug very similar to the original arises. For an adjacent-but-distinct bug in the same domain, the rule is not proactively applied — the user has to remind again.
3. Self-caused regression blindness: Side effects of a change made in session A surface as new bugs in sessions B/C. The new session reads the code as-is and treats these bugs as fresh problems — starting root-cause analysis from scratch without realizing that an earlier session led to this state.

Expected behavior

• After a local fix, surface a short "blast radius" note: direct callers, downstream effects, parity siblings, coupled data. Either audit inline or list as follow-up.
• Treat user directives not as session-scoped advice but as rules that persist for the project's lifetime. Proactively apply them to every fix within the rule's scope, not only to those resembling the original.
• When opening a bug report, before starting analysis from scratch, scan recent commits and recent memory entries with the question "could a previous session have caused this state?"

Why this matters

In long-lived codebases the user effectively becomes the project's long-term memory carrier — re-explaining context across sessions many times. The surface-fix pattern causes the cumulative state to drift step by step away from the direction the user expected: the same bug is rediscovered in different forms, palliative fixes accumulate instead of root-cause fixes, and the user spends time redirecting the assistant back to constraints it should have remembered.

Reproduction context

• Multi-day / multi-week project work, many sessions
• Frequent session boundaries (compaction, new conversation)
• Memory files actively used, but cross-session continuity relies heavily on the user
• Strongly interconnected domains (e.g. legacy game server with 3-class parity, refactors coupled to DB migration, multiple subsystems sharing global state)