fix(plugin): restore venv-aware Python resolution for hooks + MCP

[jphein]

Summary

Three recent .claude-plugin/ changes regressed hook and MCP invocation for installs that depend on a local venv:

• 5fe0c1c — mempal-stop-hook.sh → PATH-only (command -v mempalace / bare python3 -m mempalace)
• be9214a — mempal-precompact-hook.sh → same regression
• 9f5b8f5 — .mcp.json → bare "mempalace-mcp" command

All three assume a system-wide install via pipx/uv/pip-global — fine for that path, but they break:

1. Editable dev installs (pip install -e . inside a repo venv). mempalace / mempalace-mcp and the module only live in the repo venv, not on PATH. The stop/precompact hooks fall through all three checks and print:

   MemPalace hook error: could not find a runnable mempalace command or module
   

   MCP fails to spawn because bare mempalace-mcp isn't on PATH.

2. Claude Code plugin installs that create a per-plugin venv at ${CLAUDE_PLUGIN_ROOT}/venv/. Neither the hooks nor .mcp.json look there, so anything that isn't also system-installed breaks.

Fix

Restore the three-tier resolution:

1. MEMPALACE_PYTHON env var (user override)
2. $PLUGIN_ROOT/venv/bin/python3 (covers dev installs AND Claude Code's per-plugin venv)
3. System python3 (pip --user / pipx / uv as system install — preserves the original intent of the regressing commits)

.mcp.json goes back to ${CLAUDE_PLUGIN_ROOT}/venv/bin/python -m mempalace.mcp_server. ${CLAUDE_PLUGIN_ROOT} is expanded by Claude Code before spawn, so this works for dev installs (via venv symlink) and packaged plugin installs alike.

Test plan

• Editable dev install (pip install -e . in repo venv): both hooks return {} from a neutral cwd; MCP initialize handshake returns serverInfo = {name: mempalace, version: 3.3.1}; tools/list returns all 29 tools.
• Fallback to system python3: confirmed by inspection — if neither MEMPALACE_PYTHON nor $PLUGIN_ROOT/venv/bin/python3 resolves, the hook executes the same python3 -m mempalace hook run ... invocation the regressing commits used.
• ${CLAUDE_PLUGIN_ROOT}/venv/ packaged install path — works by construction (Claude Code's plugin manager creates the venv at that exact location), but not re-tested in this PR.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Restores venv-aware invocation for MemPalace’s Claude Code hooks and MCP server startup to support installs where mempalace isn’t available system-wide on PATH (e.g., per-plugin venv).

Changes:

• Update stop/precompact hook scripts to resolve a Python interpreter via MEMPALACE_PYTHON, plugin venv, then system python3.
• Switch MCP server launch in .claude-plugin/.mcp.json to use the plugin venv Python with -m mempalace.mcp_server.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.

File	Description
.claude-plugin/hooks/mempal-stop-hook.sh	Adds interpreter resolution logic and runs hook via python -m mempalace ....
.claude-plugin/hooks/mempal-precompact-hook.sh	Same interpreter resolution change for precompact hook.
.claude-plugin/.mcp.json	Launch MCP server via ${CLAUDE_PLUGIN_ROOT}/venv/bin/python -m mempalace.mcp_server.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The hook currently reads all stdin into INPUT=$(cat) and then pipes it back via echo. This can change the payload (trailing newlines are stripped by command substitution; echo is not safe for arbitrary content) and unnecessarily buffers the entire request in memory. Prefer streaming stdin directly into the Python invocation so JSON is preserved exactly.

Suggested change

	INPUT=$(cat)
	echo "$INPUT" | "$PYTHON" -m mempalace hook run --hook precompact --harness claude-code
	"$PYTHON" -m mempalace hook run --hook precompact --harness claude-code

[Copilot]

The previous implementation emitted a clear, consistent error when no runnable mempalace command/module was available. With the current logic, if python3 is missing (or if the selected interpreter can't import mempalace), the script will fail with a generic shell/Python error and may not be obvious to users how to fix it. Consider restoring explicit checks (e.g., command -v and a quick -c "import mempalace") and printing the hook-specific error message to stderr before exiting non-zero.

[Copilot]

The script no longer verifies that the resolved interpreter exists on PATH and can import mempalace before invoking it. If python3 isn't installed (or the chosen interpreter lacks the package), the hook will error with a generic shell/Python message rather than the prior explicit "could not find a runnable mempalace command or module" guidance. Consider adding back explicit checks and a clear stderr error before exiting.

Suggested change

	fi
	fi
	if [[ "$PYTHON" == */* ]]; then
	if [ ! -x "$PYTHON" ]; then
	echo "mempal-precompact-hook: could not find a runnable mempalace command or module" >&2
	exit 1
	fi
	elif ! command -v "$PYTHON" >/dev/null 2>&1; then
	echo "mempal-precompact-hook: could not find a runnable mempalace command or module" >&2
	exit 1
	fi
	if ! "$PYTHON" -c 'import mempalace' >/dev/null 2>&1; then
	echo "mempal-precompact-hook: could not find a runnable mempalace command or module" >&2
	exit 1
	fi

[Copilot]

The hook currently slurps all stdin into a shell variable and re-emits it via echo. Command substitution strips trailing newlines and echo can subtly transform input, which can corrupt the JSON payload that mempalace hook run expects. Prefer passing stdin through directly to the Python process (no intermediate buffering) so the payload is preserved and large inputs don't get loaded into memory.

Suggested change

	INPUT=$(cat)
	echo "$INPUT" | "$PYTHON" -m mempalace hook run --hook stop --harness claude-code
	"$PYTHON" -m mempalace hook run --hook stop --harness claude-code