Claude Code 2.1.32: Keep Team Rules in CLAUDE.md

That distinction is the useful part of XDA-Developers’ account of moving routine preferences and repeated corrections out of an ever-growing CLAUDE.md. The writer’s conclusion is broadly sound, but the operational consequence for teams is more specific: do not replace an auditable, version-controlled instruction set with an automatically maintained local notebook. Trim the former; inspect the latter.

For Windows developers using Claude Code through WSL, Windows Terminal, PowerShell, or VS Code, this is also a storage and governance change. Auto memory is enabled by default, persists on the local machine, and can be shared across Git worktrees for the same repository. A correction casually made in one worktree can therefore influence a later session in another checkout of that same repository.

What Claude Code 2.1.32 Actually Added​

Claude Code 2.1.32 did more than expose a new command for saving notes. Anthropic’s February changelog says Claude now “automatically records and recalls memories as it works,” making persistence part of the ordinary coding-agent workflow rather than a file developers had to curate entirely by hand.

Anthropic describes four categories of auto memory: information about the user’s role or working preferences; feedback and corrections; project decisions or ongoing work that are not recoverable from the repository; and references to external resources such as dashboards or issue trackers. Claude is supposed to avoid recording facts it can derive from code, as well as content that is already present in CLAUDE.md.

That last qualification puts an important limit on the XDA-Developers framing. Auto memory cannot be assumed to capture every preference a developer expresses, nor should a developer rely on it to reconstruct project rules after deleting them from CLAUDE.md. Claude decides which details are useful enough to retain. Its notes are assistance for continuity, not a deterministic configuration system.

Anthropic’s docs say both systems are loaded at the start of every conversation, but their ownership models differ. CLAUDE.md can be checked into Git, reviewed in pull requests, distributed to a team, and amended deliberately. Auto memory is created by Claude in a local directory and is not synchronized through source control.

Keep Shared Rules in CLAUDE.md​

The best use for a repository CLAUDE.md is information that a new contributor, a CI operator, or another coding assistant would need to follow consistently. That includes build and test commands, architectural boundaries, naming conventions, dependency restrictions, deployment rules, database constraints, and instructions such as “run the full integration suite before changing authentication middleware.”

These are team rules, not recollections. If the expected behavior of an agent matters to code review or production safety, it should be visible in the repository and reviewable by humans. Anthropic explicitly warns that CLAUDE.md content is context, rather than enforced configuration, but visible context is still far more manageable than an opaque collection of per-machine inferences.

A practical project file should therefore become shorter and more declarative after auto memory is enabled. Remove the personal, transient, or repetitive notes that merely document how one developer likes to collaborate with Claude. Keep instructions that explain what the repository requires, regardless of who runs the tool or which computer they use.

Anthropic recommends targeting fewer than 200 lines per CLAUDE.md, warning that longer instruction files consume context and reduce adherence. That is a meaningful reason to reduce bloat, but the solution is not to push every rule into auto memory. Large repositories should split durable guidance into .claude/rules/ files, including path-scoped rules that load only when Claude works on relevant code.

For example, an API validation standard belongs in a rule attached to src/api/**, while a release procedure can live in a skill invoked for release work. A short root CLAUDE.md should point Claude toward those structures and establish the few rules that apply throughout the repository.

Auto Memory Is Per-Repository, Not Per-Branch​

The hidden operational detail is where Claude’s automatic notes live. Anthropic stores them in a per-project memory directory under the user’s Claude configuration area, with a MEMORY.md index and separate topic files. The directory is derived from the Git repository, and all subdirectories and worktrees of that repository share it.

For developers who use Git worktrees to isolate feature development, bug fixes, and release branches, that scope is wider than it first appears. A note Claude creates while helping on an experimental branch may still be available when it is later asked to work in the stable branch. This can be useful for enduring coding preferences, but it can also carry temporary assumptions beyond the branch where they were true.

The memory does not travel automatically to a coworker’s PC or a build server, which prevents it from becoming a secret shared repository policy. It does mean, however, that two developers can have materially different Claude Code behavior in the same checkout because their local auto-memory contents differ. If a fix “works on my machine” only because Claude remembers an undocumented preference or project fact, the durable version belongs in the repository.

The index file is also subject to a startup limit. Claude Code loads only the first 200 lines of MEMORY.md, or the first 25 KB, whichever threshold is reached first. Detailed topic files help keep the index concise, but they do not remove the need to audit whether the index still points Claude toward useful and current information.

Audit the Notes Claude Is Writing​

Auto memory is not a background service that developers should ignore after switching it on. Anthropic provides the /memory command to view and edit what Claude Code has retained, including an option to toggle the feature. Teams using local checkout automation should add a quick memory review to onboarding and troubleshooting rather than treating unexpected agent behavior as a model mystery.

The first review should identify stale information from closed incidents, abandoned migrations, removed services, or superseded coding conventions. A particularly risky memory is a workaround that once made sense but has since become dangerous—for example, an old instruction to bypass a check during a deployment failure or to ignore a test that has since been fixed.

The second review should separate private working preferences from team knowledge. “Prefer PowerShell commands on this Windows workstation” may be a valid local note. “The production API requires a header documented only in an internal ticket” is project knowledge that should be recorded in a controlled, access-appropriate location rather than left to a single local Claude memory file.

Memory should also be checked when developers clone a repository into a new environment, change branches heavily, or begin work after a long absence. Auto-memory files are excluded from Claude Code’s normal session-transcript retention sweep, according to Anthropic’s documentation; they remain until Claude or the user changes or deletes them. Persistence is the feature, but it is also why outdated notes can linger.

Instructions Are Still Not Enforcement​

Neither a slimmed-down CLAUDE.md nor auto memory should be used as a hard security control. Anthropic states that both are contextual guidance, and Claude can fail to follow guidance even when the instruction was loaded correctly. A repository rule saying “never access production credentials” is useful, but it is not a substitute for credential isolation, least-privilege access, or command restrictions.

For enterprise deployments, Claude Code supports a managed CLAUDE.md location on Windows under C:\Program Files\ClaudeCode\CLAUDE.md, allowing IT or DevOps teams to distribute organization-wide guidance. Anthropic’s own documentation separates that behavioral guidance from settings that actually enforce restrictions, such as denied permissions, sandbox settings, and environment controls.

Use those technical controls when an action must be blocked regardless of model judgment. Anthropic specifically points to PreToolUse hooks for cases where a team needs to prevent an action instead of merely asking Claude not to take it. That applies especially to destructive database commands, deployment actions, access to credential locations, and unapproved network or package-management operations.

Developers who cannot permit automatically accumulated local context can disable auto memory per project through settings or globally with the CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 environment variable. That is a reasonable choice for sensitive workflows, reproducible automation, or investigations where a clean session state is more valuable than personalization.

Claude Code’s memory feature makes CLAUDE.md less of a scrapbook and more of what it should have been: a concise, shared operating manual for a codebase. The next cleanup is straightforward—move hard requirements into reviewed rules and enforced settings, let Claude retain low-stakes collaboration patterns, and inspect the memory directory before it starts quietly defining how your agent works.