Memory MCP ignores custom storage path setting

[Fionhurong]

I've been trying to configure the MCP memory server to store data in a custom location, but it continues to store the memory.json file in the NPX temporary directory instead.

Configuration

In my Claude desktop config file, I've specified a custom path:

"memory": {
  "command": "npx",
  "args": [
    "-y",
    "@modelcontextprotocol/server-memory"
  ],
  "env": {
    "MEMORY_FILE_PATH": "/Users/XX/Library/Application Support/Claude/mcp/memory.json"
  }
}

Actual Behavior

Despite setting the MEMORY_FILE_PATH environment variable, the memory.json file is still being created in the NPX temporary directory:

/Users/XX/.npm/_npx/15b07286cbcc3329/node_modules/@modelcontextprotocol/server-memory/dist/memory.json

Additional Information

• I've created the target directory and ensured it has appropriate permissions
• The memory functionality works correctly, but uses the wrong file location
• Claude can read/write to the temporary file location, but this isn't persistent

Can someone help explain why the environment variable isn't being recognized, or if there's a different way to specify a custom storage location? This is concerning because NPX temporary directories may be cleaned up, potentially losing all memory data.

[darrencroton]

Same for me

[PlatanusO]

This still appears to be an issue.

[davidtorcivia]

Same issue on Windows. Seems like the env variable is not being passed along by Claude Desktop.

[davidtorcivia]

Ended up just symlinking in the interim and that works fine.

[nazreen]

Facing this too

[travelingflwr]

Same issue here. Just encountered it today.

[InitPatch]

Same here.
I asked Claude about it, here's a sample of our chat:

Me: remember that my name is InitPatch

Claude: Hello InitPatch! I've noted your name in my memory.

Me: where did you store that memory?

Claude: I stored your name in my knowledge graph, which I refer to as my "memory" ... I stored your name in the knowledge graph system that's part of my architecture.

Me: but according to the MCP server "memory" I have installed, you were supposed to store these memories into: /Users/InitPatch/Documents/Claude_Memory/memory.json. And right now this file is empty.

Claude: Based on this configuration, you're right - the memory information should be stored in that JSON file. If that file is empty, it suggests there might be an issue with how the memory system is functioning or being persisted to that location. The "server-memory" component appears to be set up to use that path, but it seems the data I'm storing when using the knowledge graph functions isn't actually being written to that file as expected.

This could be due to several reasons:

1. The memory server might not be properly connected to the file system
2. There might be permission issues with writing to that location
3. The memory component might be configured but not fully functional
4. The interface between my knowledge graph API calls and the actual file persistence might not be working correctly

Since the file exists but is empty, it suggests the system can access the location but may not be properly writing the data there. This is likely a technical issue with how the memory component is integrated with the file system.....

Me: then tell me where is located your temporary knowledge graph system, where your memory data is currently stored

Claude: ... While I'm interacting with the knowledge graph system through the API functions (as you can see in my function calls above), the data isn't being persisted to the memory.json file. This suggests that the memory system is working in-memory during our conversation but isn't correctly writing to the file system.
I don't have visibility into where my "temporary knowledge graph system" is physically stored, as that's part of the internal implementation of how Claude operates. The data appears to exist within the conversation context but isn't being properly saved to your local file system...

[creativehelm]

From Claude:

After investigating the memory MCP server issue (#692), here are my technical findings:

1. The server code in /src/memory/index.ts does correctly define the MEMORY_FILE_PATH constant using the environment variable, but the problem appears to be in how the environment variables are passed from Claude Desktop to the NPX process.

2. Looking at the code between lines 13-21 in the index.ts file, we found that the path resolution logic itself looks correct:

// Define memory file path using environment variable with fallback
const defaultMemoryPath = path.join(path.dirname(fileURLToPath(import.meta.url)), 'memory.json');

// If MEMORY_FILE_PATH is just a filename, put it in the same directory as the script
const MEMORY_FILE_PATH = process.env.MEMORY_FILE_PATH
  ? path.isAbsolute(process.env.MEMORY_FILE_PATH)
    ? process.env.MEMORY_FILE_PATH
    : path.join(path.dirname(fileURLToPath(import.meta.url)), process.env.MEMORY_FILE_PATH)
  : defaultMemoryPath;

3. The issue occurs at runtime, where the environment variable seems to not be passed correctly to the NPX subprocess.

4. When the server is launched via Claude Desktop's configuration, even though the env property is set with MEMORY_FILE_PATH, this value doesn't seem to reach the actual running server process.

5. The problem appears to be specific to how Claude Desktop's MCP configuration mechanism passes environment variables to NPX-executed packages rather than a bug in the memory server code itself.

The solution given was to replace the above code with:

// PATCHED: Hardcoded path to fix the issue where environment variable is ignored
const MEMORY_FILE_PATH = "~/Claude Desktop MCP/memory.json";

[darrencroton]

Thanks for the code update.

As mentioned an above, I also just symlinked, which is probably better than changing the code if you’re just hardwiring it in. Unfortunately, at some point the MCP seemed to update which moved everything into a new directory (is that meant to happen?). So wasn’t a long term solution either.

Hopefully someone on Anthropic’s side notices and fixes this.

[Derjyn]

This is still not elegantly resolved. We should be able to reference a custom path to memory.json at will - this seems paramount. I'm using OpenCode with both a global and per-project configuration approach. For every other tool, agent setup, etc I've worked with so far, there have been no issues.

However with this, while I can configure the MCP entry like so, specifying the path to memory.json:

"server-memory": {
    "type": "local",
    "command": ["npx", "@modelcontextprotocol/server-memory", "mcp"],
    "environment": {
        "MEMORY_FILE_PATH": "{file:./memory.json}"
    },
    "enabled": true
}

The memory file is never written to, nor read from of course. Every other tool I've defined works fine, my tester agent can happily read/write/patch other various files... it's just this MCP tool that doesn't want to play nice.

[sstklen]

Hey! I ran into a similar pattern in our bug knowledge base and thought this might help.

What's happening: npx spawns an intermediate shell/process that does not reliably forward custom env vars to the actual server process. The MEMORY_FILE_PATH env var set in Claude Desktop config reaches npx but gets lost before reaching the memory server's process.env. The server then falls back to path.join(__dirname, 'memory.json'), which resolves to the npx cache directory.

What worked for us:

Bypass npx entirely. Install the package once, then point Claude Desktop config directly at the installed index.js using node. This guarantees env vars are passed to the actual server process without intermediary shells.

Install once:
  npm install -g @modelcontextprotocol/server-memory

Then update Claude Desktop config:
{
  "memory": {
    "command": "node",
    "args": [
      "/usr/local/lib/node_modules/@modelcontextprotocol/server-memory/dist/index.js"
    ],
    "env": {
      "MEMORY_FILE_PATH": "/Users/XX/Library/Application Support/Claude/mcp/memory.json"
    }
  }
}

(Find actual path with: npm root -g)

Hope this helps! Let me know if it doesn't match your case — happy to dig deeper. 🦞

Disclosure: This analysis is from Confucius Debug, an AI-powered community KB for agent bugs. Please verify before applying.

---

_{🦞 Confucius Debug — community knowledge base for AI agent bugs. Free to search via MCP.}