Is Claude Code's MEMORY.md Enough to Track Customer Feedback?
No. Claude Code's auto memory is real and it's useful, but it answers a different question than "what have our customers told us." MEMORY.md is the index file for a directory Claude writes to itself, on your machine, scoped to one repository, filled with your corrections and preferences so Claude doesn't relearn them next session. It has no concept of a customer, a company, or a request that showed up in three different tools worded three different ways.
The two systems solve genuinely different problems. Auto memory keeps one agent from repeating a mistake you already fixed. A customer feedback record keeps a team, and every agent that team runs, agreeing on who asked for what and whether it shipped. Nothing about the first one implies the second, and Claude Code's own documentation is specific about the boundary.
What MEMORY.md actually is
Claude Code has had project instructions (CLAUDE.md) for a while. It's a file you write by hand, checked into source control, loaded at the start of every session. Auto memory is newer and different. According to Claude Code's memory documentation, Claude writes auto memory itself, without being asked, based on corrections you give it and preferences it notices. It files each memory into one of four kinds: user (your role and working style), feedback (corrections and confirmed approaches), project (decisions and context the code alone doesn't show), and reference (pointers to things outside the repo, like a dashboard or a tracker).
Those files land in ~/.claude/projects/<project>/memory/, one topic file per memory, and MEMORY.md is the index on top of them, capped at the first 200 lines or 25KB, whichever comes first. Two details matter more than the mechanics. First, the whole directory is machine-local, and it is not shared across your teammates' machines; the docs say plainly that "auto memory is machine-local... files are not shared across machines or cloud environments." Second, it is scoped by repository rather than by customer or account. Run the same repo from two worktrees and they share one memory folder, but nothing about a customer complaint enters that folder unless you happen to type it into chat and Claude decides it's worth keeping.
So MEMORY.md can hold "always run pnpm, not npm" or "the staging API needs a fake X-Test-User header." It cannot hold "eleven accounts have asked for CSV export in the last quarter, four of them on the enterprise plan," because that's not a coding preference, it isn't derivable from the repo, and no auto memory instance sees more than one machine's worth of sessions anyway.
“we need SSO before rollout”
“any update on single sign-on?”
“SSO came up twice on this call”
Linear issue, quotes attached
insight report in Notion
Claude CodeWhere CLAUDE.md and auto memory do their job well
None of this is a knock on the feature. For its actual job, CLAUDE.md plus auto memory is a solid pair, and it's worth being precise about what that job is:
- Coding conventions, build commands, and architectural decisions that don't live anywhere else.
- Corrections you'd otherwise repeat every session, like a flaky dependency or a naming rule.
- Context Claude can't derive from the code itself, like a deadline or an in-flight decision.
Auto memory even explicitly skips things it can already infer from the codebase or that CLAUDE.md already says, which keeps it from turning into noise. That's the right design for one agent's working notes. It's the wrong shape for a customer record, because a customer record needs to survive the fact that reports arrive on different machines, in different tools, from different people, worded differently each time.
Where a per-repo memory file stops scaling
The pattern repeats past a certain size, and it isn't really about Claude Code specifically, it's about anything that writes memory scoped to one machine and one agent:
- It doesn't survive a change of hands. The teammate who reads the support inbox usually isn't the one whose Claude Code session logged the earlier bug.
- It doesn't dedupe across channels. Three phrasings of the same complaint, in Slack, in email, and in a support ticket, look like three unrelated facts to three separate memory folders (or none at all, if nobody happened to be pairing with Claude when it came up).
- It doesn't attach a person or a company. A
project-type memory note is a sentence about the bug, not a record of who reported it, which makes closing the loop later a matter of remembering, not looking up. - It doesn't leave the machine. Two engineers on the same team, working the same repo from different laptops, keep two memory folders that never reconcile.
Past a small team, that's the point where you need something that isn't scoped to a repo or a machine at all: a record that reads from every channel where feedback actually lands, resolves the same request said three ways into one entry, and hands the result to whichever agent needs it, whether that's a Claude Code session or a person in Slack. We build Modem to be the shared feedback record behind whichever agent or person asks, so read the recommendation knowing where it comes from. Modem watches the channels a team already runs, Slack, email, Zendesk, and GitHub among them, dedupes the same complaint across all of them into one counted topic with the original quotes and the reporting accounts attached, and exposes that graph over MCP so a Claude Code session can query it directly instead of relying on whatever one engineer's memory folder happened to catch. The Claude Code integration goes a step further and lets the Modem agent hand a task to Claude Code with the bug report, the customer quotes, and the topic history already composed into the task description, so a repeat report arrives flagged "second report, different customer" instead of surfacing twice, looking like a brand-new bug both times. Pricing is unlimited users on every plan, pay-as-you-go beyond included usage, so adding a second engineer's Claude Code session to the same graph isn't a new per-seat line item.
None of this means replacing CLAUDE.md or turning off auto memory. Both stay exactly as useful for what they've always done. What changes is adding a layer above the per-repo notes that doesn't forget when the reporter isn't the same person twice, or the machine isn't the same laptop.
Start with a shared doc, not a smarter memory file
If a dedicated feedback layer is more than the team needs right now, the stopgap is a shared, hand-maintained doc, not a machine-local memory file: a running list of confirmed bugs and requests with the reporter's name and channel, updated whenever someone closes a loop. It won't dedupe itself and it won't reach into Claude Code's context automatically, but at least it survives past one engineer's laptop, which auto memory by design does not. Read the mechanics in Agent memory, explained if the short-term versus shared-memory distinction is still fuzzy, and see the six best tools to give Claude Code customer context for the wider menu once a doc stops being enough on its own.
