Plugin assumes python3 -m mempalace — breaks on modern Linux (PEP 668) and with uv/pipx

[armujahid]

Plugin assumes python3 -m mempalace works — breaks on modern Linux (PEP 668) and with uv/pipx installs

Problem

The Claude Code plugin (.claude-plugin/) invokes mempalace via python3 -m mempalace... in three places:

Component	File	Invocation
MCP server	.mcp.json, plugin.json	python3 -m mempalace.mcp_server
Stop hook	hooks/mempal-stop-hook.sh	python3 -m mempalace hook run --hook stop --harness claude-code
PreCompact hook	hooks/mempal-precompact-hook.sh	python3 -m mempalace hook run --hook precompact --harness claude-code

This requires mempalace to be importable by the system python3, which fails when:

1. Modern Linux distros with PEP 668 (Ubuntu 23.04+, Fedora 38+, Debian 12+, Arch) — pip install mempalace into the system Python is blocked with externally-managed-environment error
2. uv tool install mempalace — installs the CLI on PATH in an isolated venv, but the system python3 can't import it
3. pipx install mempalace — same as uv: CLI on PATH, package not importable by system Python
4. Virtual environments — python3 -m mempalace only works while the venv is active

The skill documentation (SKILL.md) also hardcodes pip install mempalace as the only install method.

Suggested fix

Replace python3 -m mempalace with the mempalace CLI entry point everywhere. The mempalace binary is placed on PATH by all installation methods (pip, uv tool install, pipx), so this works universally.

Hooks — straightforward replacement:

# Before
echo "$INPUT" | python3 -m mempalace hook run --hook stop --harness claude-code

# After
echo "$INPUT" | mempalace hook run --hook stop --harness claude-code

MCP server — needs a new CLI subcommand (e.g., mempalace mcp-serve) since mcp_server.py is currently only launchable as a module:

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

// After
{"command": "mempalace", "args": ["mcp-serve"]}

SKILL.md — offer multiple install methods:

pip install mempalace       # in a venv
uv tool install mempalace   # recommended on modern Linux
pipx install mempalace      # alternative

Impact

Anyone installing the plugin from the marketplace on a modern Linux distro (PEP 668) will have a broken MCP server and non-functional hooks out of the box.

Environment

• mempalace 3.0.14
• Arch Linux (PEP 668 enforced)
• Installed via uv tool install mempalace

[bmaltais]

Yeah... The installed MCP config in Claude Code on WIndows with:

claude plugin marketplace add milla-jovovich/mempalace
claude plugin install --scope user mempalace

Is broken.

[bmaltais]

I had the fix for it but it got rejected: #313

Maybe implementing that would work... just saying...

[armujahid]

@bmaltais my PR should resolve mempalace detection issue from PATH but I think the existing bash scripts won't work on windows unless you are in WSL. I have another pending PR that would allow users to add their own hooks since those will be bundled in package. check #265

[bmaltais]

This is what I had to do in claude code to make it work as is on windows:

  1. Created python3.exe — copied python.exe to python3.exe in C:/Users/berna/AppData/Local/Programs/Python/Python311/. Windows doesn't ship a python3 executable; MCP servers need a real .exe, not a    bash shim.
  2. Removed env.PATH from settings.json — it was overriding the full Windows PATH with a Unix-format string (/c/... colon-separated) that Windows process spawning can't parse. This was actively      
  hiding Python311, which was already in my Windows user PATH.   

[psaghelyi]

Confirming this still affects mempalace 3.1.0 on a uv-only Proxmox host — no system python3 available anywhere, only uv / uvx installed.

Concretely, we run mempalace via uvx --from mempalace python -m mempalace … and uvx mempalace …, which works fine for the CLI and the MCP server. The friction points are:

1. Plugin hooks ship a python3 -m mempalace invocation — on this host that resolves to nothing and hooks silently no-op. We keep a locally-patched copy at /root/.claude/plugins/cache/mempalace/mempalace/3.0.14/hooks/mempal-*-hook.sh that swaps in uvx --quiet --from mempalace python -m mempalace …, and have a note to re-apply it on every plugin update.

2. mcp.json ditto — we run it as command: "uvx", args: ["--quiet", "--from", "mempalace", "python", "-m", "mempalace.mcp_server"].

3. Docs/instructions (e.g. instructions/init.md) tell the user to run python3 --version as a prerequisite check, which fails on hosts like ours where uv is the only entry point. uv python --version or uvx --from mempalace python --version work.

4. Embedded scripts inside the package (onboarding.py, split_mega_files.py, convo_miner.py, etc.) have #!/usr/bin/env python3 shebangs — fine when the package is installed, but they also print python3 … usage strings in their docstrings which is misleading for uv users.

Our host has no Python at all on the bare OS, but uv pulls and caches whatever interpreter mempalace needs on demand. The whole project could be uv-idiomatic with essentially no code changes — the fixes are all in the wrapper scripts and docs. I'll comment separately if we get around to a PR for the hooks/mcp bits.

[tybritten]

+1 on this on Mac. I'm using mise/uv to to manage python and home-brew has also installed python for some other deps and the python3 -m call ends up falling back to that one (which doesn't have the package). using the cli mempalace instead allows the user to manage the install location better

[web3guru888]

Confirming this affects us too on Linux with a uv-managed install. The python3 -m mempalace.mcp_server invocation in .mcp.json picks up whichever python3 is first on PATH, not the one in the active venv/project.

The fix we've been using locally: replace python3 -m mempalace.mcp_server with $(which mempalace) --mcp (or the full path to the venv's mempalace script). This works with uv, pipx, and standard venv installs because it uses the entry point that was installed alongside the package.

For the hooks (hooks/mempalace-stop-hook), same principle — use the mempalace CLI directly rather than python3 -m. The CLI entry point is already correctly wired to the installed package's interpreter.

A proper upstream fix would be for .mcp.json and plugin.json to use the mempalace entry point rather than python3 -m. This also has the benefit of being forward-compatible with PEP 668 environments. Happy to put together a small PR for this if maintainers confirm the approach.

[armujahid]

@web3guru888 I already have a linked open PR that you can check and upvote.