Windows setup failures: unversioned python3 calls break ChromaDB, MCP, and hooks

Environment

• OS: Windows 11
• Claude Code: Desktop app
• MemPalace: 3.1.0

###Mind you, however, I am just dumb sometimes, and this might just simply be my own issue.

Root cause

Throughout the codebase, python3 is used without a version pin. On Windows, python3 resolves to whatever is first on PATH. If that happens to be Python 3.14 (which is available via the Windows Store and common on newer machines as just kinda the default, somehwat biased as this is my first one listed on PATH). ChromaDB fails immediately due to the Pydantic V1 incompatibility (Which was noted in the April 7 transparency statemen) So basically no version check, no clear error pointing to any sorta python version.

Unfortunately this kinda throws a wrench into the entire process.

Failure 1: mempalace init crashes mid-run

The init command partially completes (saves entities.json) then throws a ChromaDB/Pydantic traceback with no mention of Python version as the cause. No clear signal really provided that the fix is to switch Python versions.

Failure 2: .mcp.json uses python3, MCP server never starts. I kept trying to figure out why the connection wasn't working and the mempalace itself was running but the tools weren't working.

{
  "mempalace": {
    "command": "python3",
    "args": ["-m", "mempalace.mcp_server"]
  }
}

Same result. The MCP server silently fails to start. In the Claude desktop app specifically, this file is what the app reads to launch the server. The ~/.claude.json project config used by the CLI is a separate context, which makes debugging non-obvious. Realized that most people are normal and use the actual terminal version of Claude Code which might have been part of the foundation of my issue.

Failure 3: Hook scripts use python3, auto-save never works

Both mempal-stop-hook.sh and mempal-precompact-hook.sh call python3 directly. Same failure, same silent result.

Failure 4: --palace flag rejected on init

mempalace init "D:\XXXXX" --palace "D:\XXXXX.mempalace"
error: unrecognized arguments: --palace

The flag works on other subcommands but is silently rejected on init. README implies it should work globally.

Suggested fixes from somebody that might have just been dumb and did a foundational step wrong;

Add a Python version check at startup with a human-readable error (something like "MemPalace requires Python 3.9 to 3.13. Detected 3.14.") since all it says right now is that anything above 3.9 is fine.

Replace python3 with python in .mcp.json and hook scripts for broader Windows compatibility, or support a MEMPALACE_PYTHON env var to let users specify the path (PR #633 appears to address as later mentioned)

Add a Windows setup note to the README callling out the version requirement

Fix or document the --palace flag behavior on init

Add input validation on the entity removal step

Note: PR #633 appears to address the hook issues and introduces MEMPALACE_PYTHON as an env var for specifying the Python path. The .mcp.json issue may still need a separate fix since it is outside the hook system.

Note 2: Currently I run an Obsidian Vault that relies on the agent to update a range of context files and use ai-grep to index the vault, basically just this project but simplified in some ways, it was able to be implemented together perfectly fine, just as a note to anybody else that might be curious and sees this.

Note 3: To reiterate, I am not some sort of advanced python user, I might have simply just screwed something up early on, and a broken foundation made the rest of the building shaky.