Hook scripts should use venv python in it's hooks

[semide]

What happened?

Installed on a Mac/Tahoe system using pipx. Failed to run because newer python (3.14) threw errors with database. Downgraded to 3.13, installed correctly. Ran set up and initial tests. Configured Claude CLI and had ran specifying path to older python. Hooks failed due to incorrect path call.

What did you expect?
Once installed, hooks work normally

How to reproduce:

1. Install via pipx,
2. Workaround database call not working correctly by installing using older python
3. complete install
4. configure in Claude
5. See Hook errors, ask Claude to fix, it succeeds and says: Fixed. Both hook scripts were using bare python3 (which resolves to Python 3.14), but mempalace is installed in a pipx venv
   under Python 3.13. Updated both hooks to use the explicit pipx path:
   /Users/xxxxxxxxxxxxxxx/.local/pipx/venvs/mempalace/bin/python3.13.

Environment:

• OS: Mac Tahoe
• Python version: 3.13
• MemPal version: mempalace 3.1.0, installed using Python 3.13.13

[web3guru888]

This is a known friction point with pipx installs — it isolates mempalace in its own venv, so the hooks need to call that venv's Python, not the system python3.

The cleanest fix is to have the hooks use mempalace the CLI entry point directly (which pipx puts on your PATH and wires to the right venv Python):

# Instead of:
python3 -m mempalace.hooks.stop ...

# Use:
mempalace hooks stop ...

If the CLI entry point isn't available in the hook environment, you can hardcode the venv path like Claude suggested (~/.local/pipx/venvs/mempalace/bin/python3.13), or use this more portable form that works regardless of Python version:

~/.local/pipx/venvs/mempalace/bin/python3 -m mempalace.hooks.stop ...

The underlying issue is that hooks are generated with bare python3 — they should either use the entry point or detect the pipx venv at install time. Worth tracking as a proper fix in setup-hooks.

[aaronbieber]

This will also fix hooks when mempalace was installed with ux tool, which I have done and seems like the "most modern" way to install global Python programs now? (Question mark because I'm not an expert here).

[web3guru888]

This is a known friction point with mempalace init. The hook script is generated at init time and bakes in whatever Python interpreter is active in that moment — if you're inside a venv or a pipx-managed environment, that path gets hardcoded into the script. When Claude Code later runs the hook, it uses the system default shell (no venv activation), so the hardcoded interpreter path either doesn't exist on PATH or resolves to the wrong Python.

Workarounds until a proper fix lands:

1. Manually edit the generated hook script — find the hook file (usually in your project root or ~/.claude/), locate the interpreter line, and replace it with the full absolute path to your intended Python. Run which python3 inside your venv to get it.

2. Use python3 -m mempalace instead of a hardcoded path — if you edit the hook to use python3 -m mempalace and ensure python3 resolves correctly in the shell Claude Code uses, this is more portable.

3. Activate the venv inside the hook — prepend source /path/to/venv/bin/activate before the mempalace call in the hook script. Brittle but explicit.

Worth checking PR #513 (minimal hook subcommand) — if it generates hooks differently it may handle venv paths more gracefully. Haven't confirmed whether it solves this specific case.

On the Python 3.14 issue: that's separate from the hook path problem. 3.14 is still pre-release and several indirect dependencies haven't published compatible wheels yet. 3.13 is the right call for now — good instinct to downgrade.

---

[MemPalace-AGI integration — production stats at https://milla-jovovich.github.io/mempalace/integrations/mempalace-agi/]

[jphein]

Fixed in #562 — added _mempalace_python() that resolves the venv interpreter via __file__ path traversal, with MEMPALACE_PYTHON env var override. All three subprocess spawn sites in hooks_cli.py now use it instead of sys.executable.

[web3guru888]

_mempalace_python() via __file__ traversal is the robust approach — it works regardless of how the package was installed (pipx, uv tool, editable install, system package). The MEMPALACE_PYTHON override covers edge cases like conda or custom venvs. Fixed in #562.

[jphein]

Thanks @web3guru888 — the MEMPALACE_PYTHON override is also now in the shell hooks (save + precompact) for parity with the Python-side detection.

[z3tz3r0]

Addressed in #670. All hook shell scripts now use a find_python() function that checks MEMPALACE_PYTHON env var first, then falls back to python3, then python. This covers:

• Windows where python3 doesn't exist
• pipx/uv-tool installs where python3 resolves to system Python instead of the install venv
• Non-standard environments with custom interpreter paths

The MEMPALACE_PYTHON env var provides an explicit override for cases where auto-detection isn't sufficient.

Note: the plugin config files (.claude-plugin/plugin.json, .mcp.json) still use "command": "python3" — those would need a cross-platform entry point like mempalace mcp serve to fully fix, which is a larger change. The hook scripts are the immediate fix.