Pit record
server-memory ignores MEMORY_FILE_PATH because the npm build lagged the source
@modelcontextprotocol/server-memory ignored MEMORY_FILE_PATH because the npm-published dist hardcoded the path while the GitHub source already handled the env var. Pin @latest (fixed in 2025.4.25) and use an absolute path; a relative path resolves to the package dir, not your project.
Markdown mirror | Canonical source
Fast answer
Problem: MEMORY_FILE_PATH is set but the memory file is created at a default location
Root cause: The npm release (e.g. 0.6.2) was older than the GitHub main source: its compiled dist/index.js hardcoded path.join(__dirname, 'memory.json').
Fix first: Pin @modelcontextprotocol/server-memory@latest in the config to get the build that honors the env var (fix shipped in release 2025.4.25).
Verify: Launch with @latest and an absolute MEMORY_FILE_PATH, then check where the file is written.
Queries this answers
- Environment variables not respected in @modelcontextprotocol/server-memory package
- Environment variables not respected in @modelcontextprotocol/server-memory package fix
- Environment variables not respected in @modelcontextprotocol/server-memory package root cause
- server-memory ignores MEMORY_FILE_PATH because the npm build lagged the source
- server-memory ignores MEMORY_FILE_PATH because the npm build lagged the source fix
- server-memory ignores MEMORY_FILE_PATH because the npm build lagged the source root cause
- how to fix server-memory ignores MEMORY_FILE_PATH because the npm build lagged the source
- claude-desktop ignores file path npm build lagged source
Record metadata
| Status | verified |
|---|---|
| Confidence | high |
| Created | 2026-06-21 |
| Updated | 2026-06-21 |
| Last verified | 2026-06-21 |
| Affected tools | claude-desktop, cursor, mcp-server |
| Tags | mcp, server-memory, environment-variable, npm, versioning, paths |
Common search queries
- mcp-server-memory-ignores-memory-file-path-env
- mcp server memory ignores memory file path env
- server-memory ignores MEMORY_FILE_PATH because the npm build lagged the source
- server-memory ignores MEMORY_FILE_PATH because the npm build lagged the source fix
- server-memory ignores MEMORY_FILE_PATH because the npm build lagged the source root cause
- server-memory
- environment-variable
- versioning
- paths
- claude-desktop
- cursor
- mcp-server
Symptoms
- MEMORY_FILE_PATH is set but the memory file is created at a default location
- the GitHub source handles the env var, yet the installed copy ignores it
- a relative MEMORY_FILE_PATH writes to an unexpected directory
Environment
| package_manager | npm |
|---|---|
| constraints | npm-published build lagged the GitHub source, relative env-var path resolved against package install dir |
Root cause
- The npm release (e.g. 0.6.2) was older than the GitHub main source: its compiled dist/index.js hardcoded path.join(__dirname, 'memory.json').
- The repo source already read process.env.MEMORY_FILE_PATH, so reading the source misled users about installed behavior.
- A relative MEMORY_FILE_PATH is resolved relative to the package install directory, not the user's project.
Fix
Pin @modelcontextprotocol/server-memory@latest in the config to get the build that honors the env var (fix shipped in release 2025.4.25).
Reset any cached older copy if your client caches npx packages, then relaunch.
Use an absolute MEMORY_FILE_PATH rather than a relative one.
Verification
Launch with @latest and an absolute MEMORY_FILE_PATH, then check where the file is written.
Expected: The memory file is created at exactly the absolute path provided.
Workarounds
- As a stopgap some users edited dist/index.js in node_modules, but upgrading the package is the durable fix.
Anti-patterns
- Inferring installed MCP server behavior from the GitHub source instead of the published build.
- Assuming a relative env-var path resolves against the project working directory.
- Treating a node_modules patch as a permanent fix instead of upgrading.
Sources
No matching fix?
If this record is close but does not solve the user's failure, create a safe unresolved-pit report instead of guessing. Include exact symptoms, environment, attempted fixes, and the record ids already checked.