What happened
A user's ~/.claude.json had this for the recall-memory MCP registration:
"recall-memory": {
"type": "stdio",
"command": "/Users/ed/.bun/bin/bun",
"args": ["run", "/Users/ed/.bun/bin/mem-mcp"],
"env": {}
}
env: {} — empty. The claude mcp add CLI doesn't accept an env block, and the historical installer never patched this after the fact. So mem-mcp always resolved the DB path from defaults instead of the explicit override the user set.
Net effect: the MCP server's view of the DB diverged from the CLI's view in any install that had a non-default MEM_DB_PATH, or after the relocation to ~/.agents/Recall/recall.db.
What we've already done
Phase 1 (c46cc90) added _recall_ensure_mcp_env in lib/install-lib.sh. After recall_configure_mcp runs, the new helper patches env.RECALL_DB_PATH into whichever config file owns the registration (~/.claude.json or ~/.claude/settings.json). Fresh installs and ./update.sh runs are now fixed.
What this issue tracks
Existing installs that haven't run the new update.sh still have env: {}. They keep working only because:
- The default resolver path happens to match where their DB lives, OR
MEM_DB_PATH happens to be set in their shell when Claude Code spawns mem-mcp (depends on launch context — Claude.app, terminal, etc.)
That's fragile. We need:
- A standalone repair command — e.g.
mem doctor --fix should detect a stale env: {} block and patch it without requiring a full re-install. Currently doctor doesn't even check the MCP env block.
- A doctor probe for "MCP env has RECALL_DB_PATH matching the resolved DB path" — if they diverge, warn the user about the next-Claude-restart hazard.
Possibly also: a one-shot mem path --fix-mcp-env to make this surgically repairable from the CLI.
Related:
lib/install-lib.sh:_recall_ensure_mcp_env
src/commands/doctor.ts:checkMcpServer (current MCP check only verifies registration exists, not env state)
src/commands/path.ts (already reports the active env source — could grow a check that compares against config file value)
What happened
A user's
~/.claude.jsonhad this for the recall-memory MCP registration:env: {}— empty. Theclaude mcp addCLI doesn't accept an env block, and the historical installer never patched this after the fact. Somem-mcpalways resolved the DB path from defaults instead of the explicit override the user set.Net effect: the MCP server's view of the DB diverged from the CLI's view in any install that had a non-default
MEM_DB_PATH, or after the relocation to~/.agents/Recall/recall.db.What we've already done
Phase 1 (c46cc90) added
_recall_ensure_mcp_envinlib/install-lib.sh. Afterrecall_configure_mcpruns, the new helper patchesenv.RECALL_DB_PATHinto whichever config file owns the registration (~/.claude.jsonor~/.claude/settings.json). Fresh installs and./update.shruns are now fixed.What this issue tracks
Existing installs that haven't run the new update.sh still have
env: {}. They keep working only because:MEM_DB_PATHhappens to be set in their shell when Claude Code spawns mem-mcp (depends on launch context — Claude.app, terminal, etc.)That's fragile. We need:
mem doctor --fixshould detect a staleenv: {}block and patch it without requiring a full re-install. Currently doctor doesn't even check the MCP env block.Possibly also: a one-shot
mem path --fix-mcp-envto make this surgically repairable from the CLI.Related:
lib/install-lib.sh:_recall_ensure_mcp_envsrc/commands/doctor.ts:checkMcpServer(current MCP check only verifies registration exists, not env state)src/commands/path.ts(already reports the active env source — could grow a check that compares against config file value)