Why Claude Code Still Runs npm After You Switched to pnpm: The Memory Invalidation Problem

Two Types of Persistent Information Entering the Current Context

Teams using Claude Code often encounter a puzzling phenomenon: after migrating a repository from npm to pnpm — updating the lock file, CI, and CLAUDE.md — the agent still chooses npm for builds. Correcting it works for the current session, but the old command returns in a new session.

Simply appending "must use pnpm" to the rules may not fix the issue. The investigation must answer three questions: where the old command lives, why it still enters the context, and who is responsible for revoking it. Repository maintainers must revoke the applicability of obsolete notes; platform engineers must ensure they no longer enter the next decision cycle.

In Claude Code, two kinds of persistent information complement each other:

Manual rules — team conventions the agent should follow (e.g., build process in CLAUDE.md).

Automatic memory — notes the agent saves for future sessions (e.g., operational experience from a past correction).

Both are read into the context alongside the current conversation and tool results, becoming the material the model sees for this decision. However, context text is not mandatory configuration: what the file says, what the model chooses, and what the tool is allowed to execute must each be verified separately.

The article fixes the client baseline at version 2.1.96; its CHANGELOG entry 2.1.63 records the change to shared automatic memory across worktrees (independent working directories of the same repository). Actual directories should be opened from /memory and compared, while also checking the autoMemoryDirectory configuration. No live client behavior testing was performed.

In the migration example, the rule "project must use pnpm" should be maintained by the team per code version; the concrete executable entry must be cross-checked against the current commit's package.json, lock file, and CI. Automatic accumulation is suited for context not derivable from code — such as who to ask for a test environment — not for copying build configuration that will inevitably lag.

From Writing Experience to Old Command Re-execution

Forensics starts by comparing the current commit's build entry, effective rule files, and memory files to locate any old command that was actually read into context. Once the obsolete note is found, handle it along the memory chain; otherwise continue checking other rules, restored old sessions, or unupdated scripts — do not prematurely blame automatic memory.

The agent decides what information is worth saving and writes it to memory files. Per the official memory documentation, a new session loads a restricted index of MEMORY.md, while topic files are read on-demand by the model via the file tool.

During forensics, save the startup load records and topic-file read records that the version provides, then compare them with the revised file content. The /memory directory is only for locating the directory, not as proof of loading. Logs that list only filenames cannot prove which text was injected; without content evidence, clearing the old input is marked as unverified.

Automatic memory files are not cleaned up with the session retention period — "a long time ago" is not an expiry condition. An unloaded index does not prove the topic files have been deleted.

The model then uses the task, rules, memory, and read code together for decision-making. If an old note still says "build with npm" while only a new requirement is added to CLAUDE.md, competing inputs remain. Load order cannot guarantee reliable override of conflicting directives the way a configuration system does.

Current code must also be read first. For this case, the team should require verification of the package manager declaration, corresponding lock file, and CI build entry; if the three are inconsistent, stop the build and have the repository maintainer confirm migration completion, rather than letting the agent guess a command that happens to run.

After the model selects a command, the tool executes it. If the old command would modify dependencies or trigger unwanted scripts, memory correction alone is insufficient. PreToolUse is Claude Code's pre-tool-call hook and can return a blocking decision.

For example, a team-built validation gate can accept three inputs: repository directory, workspace state, and pending script. It allows execution only when the project declares pnpm, retains only the corresponding lock file, and CI ultimately calls pnpm; if CI calls a wrapper script, the gate continues verifying the actual entry inside that script. The result is either allow or block with a reason. Since other shells or tools may bypass this gate, it only protects the controlled entry point.

Letting the Migration Event Revoke Old Knowledge

Build-related memory should be treated as notes that require dependency validation. The team can maintain a governance record with the following fields:

Source & Owner — pre-migration build record; repository maintainer. Purpose: trace basis and confirmation person when errors occur.

Scope — commit range in this repository that still uses npm. Purpose: prevent cross-branch misapplication.

Version Basis — commit, lock file, and CI revision at time of recording. Purpose: reconstruct why it was valid then.

Invalidation Condition — change in package manager declaration, lock file type, or build entry. Purpose: trigger re-verification.

This is a team-built governance record, not a client built-in protocol. A startup checker compares the record's package manager declaration, lock file type, and build entry against the current workspace (including uncommitted changes). Changing only the README does not trigger invalidation; changing any of the above bases marks the record as "pending verification", and the maintainer judges which commits the old experience still applies to.

Before modifying active files, platform engineers stop the old writers. If the team centrally manages startup, they can register "memory directory → session processes and background tasks", pause new tasks for that directory, confirm each process exits, then move the entries and backups out of the active index and normal topic read paths. Deleting only index references may still allow reading topic files. If not all writers can be controlled, do not auto-revise online; handle manually in a maintenance window with confirmed write stop.

Revocation targets the unconditional applicability of the old command, not its validity for all historical commits. After maintainer confirmation, manual rules update with their respective code versions. The shared memory note "build with npm" can be rewritten to: "Before build, verify current commit's package manager declaration, lock file, and CI entry; if inconsistent, escalate to maintainer first."

If old experience must be retained, write explicitly verifiable applicability conditions — for example, that the commit's package manager declaration and lock file still correspond to npm.

After revision, start only clean sessions; open tasks after regression passes, avoiding old context writing back old content.

Rollback also distinguishes objects: code rolling back to a pre-migration commit uses that commit's corresponding rules; only a faulty new memory write is reverted and the current code re-verified. Revision history is kept for tracking, not returned to the active read path.

Acceptance Must Leave the Just-Corrected Conversation

Disk files have changed, but old text already loaded into context remains. Stop the old session and accept using a new session that checks actual reading and execution.

Fix the request as "check the project and execute the build" — do not tell the agent to use pnpm in the prompt. Otherwise you test ad-hoc compliance, not persistent correction. The following regression table defines the scenarios:

Original directory, new session — evidence: client version, commit, actual loaded files, tool command. Pass: selects pnpm per current config.

Another worktree, same commit — evidence: actual memory directory, loaded content, command. Pass: does not restore old command due to startup location.

Another worktree, pre-migration commit — evidence: that commit's config and invocation record. Pass: does not misapply new rules to old code.

Controlled test with inconsistent package manager declaration, lock file, or CI entry — evidence: implemented execution gate's block record, assignee, and handling result. Pass: gate blocks build, escalates to maintainer.

The first three rows count as memory revision passed only when both command selection is correct and loaded content no longer contains the unconditional old command; seeing only the correct command or filenames remains unverified. The last row validates the execution gate separately. After a block, the maintainer records the consistent build entry and confirmation commit in the change ticket; the platform engineer rechecks configuration, then retries from a new session — never bypassing the gate directly.

If also testing the model's ability to recognize contradictory notes, keep its record of verifying materials and requesting confirmation; do not require the tool hook to magically recognize text conflicts. The gate allowing the correct command does not prove the old input is cleared; the two evidences must be examined separately.

Ultimately, the responsibility to "make it forget" falls on two roles: the repository maintainer decides when knowledge no longer holds, and the platform engineer implements controllable file revision and execution checks, using regression records for acceptance. If the product only provides an opaque memory switch, do not entrust build contracts that change with version to it; keep current code and manual rules as the authoritative sources.