Hooks and MCP server break in projects with Python venv (hardcoded `python3`)

[sergesha]

Problem

All hook scripts in .claude-plugin/hooks/ and the MCP server definition in plugin.json call bare python3:

Hooks (mempal-stop-hook.sh, mempal-precompact-hook.sh):

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

MCP server (plugin.json):

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

In projects with an active Python .venv, python3 resolves to .venv/bin/python3, which doesn't have mempalace installed. This causes the stop hook to fail on every session exit:

.venv/bin/python3: No module named mempalace

The MCP server also fails to start for the same reason.

Environment

• mempalace 3.3.1 (pip) / 3.3.0 (plugin)
• Python installed via mise, mempalace installed in mise python
• Project has its own .venv which shadows python3 in PATH

Proposed fix

Support a MEMPALACE_PYTHON environment variable with fallback to python3:

Hooks:

MEMPALACE_PYTHON="${MEMPALACE_PYTHON:-python3}"
echo "$INPUT" | "$MEMPALACE_PYTHON" -m mempalace hook run --hook stop --harness claude-code

plugin.json: Harder to fix since JSON is static. Options:

1. A wrapper script (mempalace-run) that reads MEMPALACE_PYTHON
2. Document that users with venvs need to set MEMPALACE_PYTHON in Claude Code settings.json → env

This lets users set MEMPALACE_PYTHON in Claude Code's settings.json → env to point to the python where mempalace is installed, without affecting other hooks or tools.

[mvalentsev]

This is already tracked in a cluster of issues: #378 is the broader canonical tracker, and #408 / #650 / #753 cover the same pattern from different angles. A few PRs are open against exactly these files:

• .claude-plugin/hooks/*.sh: fix(hooks): resolve Claude plugin hook runner cross-platform #942 (fatkobra) uses an installed mempalace CLI first and falls back to python3 / python
• plugin.json MCP command: fix: add mempalace-mcp entry point for pipx/uv compatibility #340 (messelink) and feat: add mempalace-mcp entry point for uv compatibility #805 (ichoosetoaccept) both add a mempalace-mcp entry point in pyproject.toml and switch plugin.json to invoke it directly
• hooks/*.sh legacy: fix(hooks): real python-resolution for .sh hooks, with MEMPAL_PYTHON override #833 (igorls) adds a MEMPAL_PYTHON env override with an import sanity check (note the existing naming precedent is MEMPAL_PYTHON, not MEMPALACE_PYTHON)

An entry-point install (pipx install mempalace or uv tool install mempalace) puts a mempalace binary on PATH that survives venv activation, which is the direction most of the fix PRs are taking. Once mempalace-mcp is registered, the plugin.json fix becomes a one-line switch with no user-side configuration.

[messelink]

Update: #340, #833, and #942 have all merged as of 2026-04-21.

[raphaelsamy]

Confirming this from a fresh pip install mempalace on PyPI 3.3.2 today: the v3.3.2 tag's pyproject.toml only declares mempalace = "mempalace.cli:main" — no mempalace-mcp entry point. The merged PRs #340 / #805 add mempalace-mcp on develop, but without a 3.3.3 cut, every fresh PyPI install hits the Claude Code plugin's "command": "mempalace-mcp" with no matching binary on PATH and the MCP server fails to start.

Local workaround that works: patch the installed plugin.json and .mcp.json so the mempalace MCP server uses {"command": "python3", "args": ["-m", "mempalace.mcp_server"]} — the same approach main currently uses.

A 3.3.3 release picking up the updated pyproject.toml would unblock first-time Claude Code plugin installs. Thanks for the fast merges.

[jphein]

@sergesha — this exact failure mode has been running on our fork (jphein/mempalace) since v3.3.0, and we've had a three-tier autodetect wrapper in production that fixes it cleanly. The shell wrapper resolves Python in this order:

1. $MEMPAL_PYTHON env var (explicit override, for users with non-standard venv locations)
2. Repo venv at $SCRIPT_DIR/../../venv/bin/python3 (plugin-local venv, if it exists)
3. System python3 from PATH (last resort)

That makes the hooks work even when the active shell's python3 resolves to a project .venv/bin/python3 that doesn't have mempalace installed — which is exactly the case you described. No extra install step, no config file change.

Current fork implementations, for reference:

• hooks/mempal_save_hook.sh
• .claude-plugin/hooks/mempal-stop-hook.sh
• .claude-plugin/hooks/mempal-precompact-hook.sh

Two things worth flagging before this goes to a PR:

1. This intersects with @sha2fiddy's #1069. That issue proposes consolidating hooks/mempal_*_hook.sh into thin wrappers that delegate to mempalace hook run — the console-script path added in #340 / #833. That's a cleaner architectural direction and eliminates the inline python3 -c "import json..." parsing our autodetect targets. Our approach and #1069's are complementary rather than conflicting: once the wrappers are thin, the Python-discovery problem shrinks from "which interpreter runs the inline parser" to just "does the mempalace console script resolve on the hook's PATH." The autodetect still applies to that narrower case (via a MEMPALACE_BIN equivalent), but the scope is much smaller.

2. MCP server in plugin.json. This part of your report is orthogonal — the MCP launcher ships via upstream #340 (mempalace-mcp console entry) / commit 48eb627 which also added MEMPAL_PYTHON override for the .sh hooks' internal python3 calls. If your plugin.json still reads "command": "python3", the plugin cache is stale; refreshing from the marketplace should pick up the fixed version.

I can open a PR of the fork's .sh wrapper autodetect today as an interim fix for the pre-#1069 world. But it would be in tension with @sha2fiddy's direction, so flagging both here rather than forcing the choice.

@bensig — would value your read on which to file first: our autodetect against current fat wrappers, or hold for #1069's consolidation to land. Happy to draft either way.

[jphein]

Quick threading note: @raphaelsamy's finding about v3.3.2's pyproject.toml shipping without the mempalace-mcp entry point is a distinct regression from sergesha's venv autodetection issue this thread is tracking — both real, both worth fixing, but cleaner as separate issues so neither gets buried.

Broke it out as #1093 with a reproducer and the proposed 3.3.3 cut. @raphaelsamy credited explicitly; their workaround patch is the linked fallback.

@sergesha — the bare-python3 / venv issue you originally filed stands unchanged. My comment above offering our fork's MEMPAL_PYTHON autodetect still applies regardless of how the v3.3.2 artifact gets fixed; both pieces ideally land in the same release. Still awaiting @bensig's arbitration between our autodetect and @sha2fiddy's consolidation direction in #1069.