fix(opencode): disable repo-level MCP entry by default + venv-python fallback - #108
Conversation
…'t fail Upstream PR MemPalace#1567's `.opencode/opencode.json` uses bare `python -m mempalace.mcp_server`. That only works if mempalace is installed in the python that resolves on PATH — which on JP's box (and any uv-managed clone) it isn't, because mempalace lives in the editable `./.venv/` and PATH-resolution finds system python instead. Result: opencode launched from the repo root tries to spawn the local MCP server, fails with `MCP error -32000: Connection closed` + a ModuleNotFoundError on mempalace, and logs ERROR every session. The user-level `~/.config/opencode/opencode.jsonc` wrapper still works in parallel, but the repo-level entry is noisy and broken. Switch to `.venv/bin/python` — relative path, resolves against the opencode cwd (the repo root), works for every contributor who ran `uv sync` (which the README already tells them to do). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request addresses a configuration issue where the MCP server failed to start due to incorrect Python path resolution. By explicitly pointing to the local .venv/bin/python executable, the change ensures that the environment dependencies are correctly loaded, preventing spawn errors in uv-managed setups. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates the mempalace MCP server configuration in .opencode/opencode.json to use a specific virtual environment path for execution. The review feedback correctly identifies that the hardcoded Unix-style path is not cross-platform and recommends using uv run for better portability and environment management.
| "mempalace": { | ||
| "type": "local", | ||
| "command": ["python", "-m", "mempalace.mcp_server"], | ||
| "command": [".venv/bin/python", "-m", "mempalace.mcp_server"], |
There was a problem hiding this comment.
The path .venv/bin/python is Unix-specific and will fail on Windows (where it is .venv/Scripts/python.exe). It also makes the configuration dependent on the current working directory. Since this project uses uv, using uv run is a more portable and robust solution that automatically handles platform-specific paths and environment activation, ensuring the correct dependencies are available regardless of whether the virtual environment was manually activated.
| "command": [".venv/bin/python", "-m", "mempalace.mcp_server"], | |
| "command": ["uv", "run", "python", "-m", "mempalace.mcp_server"], |
…-server A user-level `~/.config/opencode/opencode.jsonc` with a daemon-routed wrapper is the canonical way to wire mempalace on this fork. When the repo-level `.opencode/opencode.json` is ALSO enabled and points at a local `mempalace.mcp_server` spawn, opencode connects to BOTH: - user wrapper → palace-daemon at disks.jphe.in:8085 (309K production drawers, healthy) - repo subprocess → `~/.mempalace/palace` (legacy katana store, 24K drawers, HNSW capacity divergence — 63% invisible to vector search) Result: opencode's UI surfaces 'HNSW capacity divergence' + 'routing to BM25 fallback' INFO-stderr lines that look like errors, and any mempalace_* tool call non-deterministically lands on whichever server opencode picked. Flip `enabled` to false on the repo entry so the user-level wrapper is the sole source of truth. Contributors who want a local-only spawn (no daemon set up) flip back to true; the previous commit already pointed the spawn at `.venv/bin/python` so it works for them when uv-managed. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
jphein
changed the title
…riding user wrapper (#110) The previous `enabled: false` approach (PR #108) didn't work in practice. opencode appears to merge the repo-level and user-level MCP entries by name; the repo entry's `command` overrides the user-level one even when `enabled` is set to false. Symptom: the user-level wrapper at `~/.config/opencode/opencode.jsonc` points at the daemon-routed `mempalace-mcp-wrapper.sh`. The repo-level entry pointed at `.venv/bin/python -m mempalace.mcp_server`. Opencode's log on session start shows the local palace getting opened with 'mempalace-mcp: routing → local palace @ /home/jp/.mempalace/palace' and the HNSW capacity divergence warning — meaning the repo's local-spawn command won despite enabled=false. Strip the `mcp` block from the repo config entirely. The user-level wrapper handles daemon routing. Contributors who don't have a daemon can add their own user-level config or re-add the entry under `.opencode/opencode.local.json` (gitignored). Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…merges (#112) Five PRs landed today that didn't have YAML entries yet; CLAUDE.md + README still referenced the pre-transfer jphein/mempalace ownership; the opencode integration recipe didn't cover the two gotchas that bit us tonight (npm-vs-opencode-cache patch target; the "looks like an error" stderr lines from local-palace spawns). YAML additions (newest first): - local-palace-retired-marker (#111 — 798cf14) - opencode-repo-config-empty-mcp (#110 — 7133eee) - opencode-repo-mcp-drop-comment-key (#109 — 637bb01) - opencode-repo-mcp-disable-flag (#108 — 47018e5; superseded by #110) - mcp-stub-resources-prompts-list (#107 — 6ca0670) CLAUDE.md changes: - Fork URL: `jphein/mempalace` → `techempower-org/mempalace` - Origin/upstream line reflects the May 2026 transfer - Palace data section: local palace is retired; production lives in postgres on disks.jphe.in - Python venv: `./venv/` → `./.venv/` (uv convention) - Issue tracker links updated to techempower-org README.md changes: - Quickstart and `Open upstream PRs` table use techempower-org URLs docs/integrations/opencode.md changes: - New "Patch target gotcha" subsection: opencode caches plugins under ~/.cache/opencode/packages/ independently of the global npm install; patches must apply there. - New "What 'looks like an error' but isn't" verification subsection listing the three stderr lines that surfaced today during debug. - New "If you see a different palace count" troubleshooting block: palace-count divergence between MCP and CLI usually means an old shell without PALACE_DAEMON_URL; on this fork the local palace is retired so the CLI now refuses with the marker text. FORK_CHANGELOG.md regenerated via scripts/render-docs.py. check-docs.sh clean (29 fork hash refs resolve; only existing MemPalace#1024 pr_state warning, unchanged). Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Summary
Upstream PR MemPalace#1567's `.opencode/opencode.json` spawns `python -m mempalace.mcp_server` with bare `python`. On any uv-managed clone (which the README's setup steps produce), `python` resolves to system python without mempalace installed → spawn fails with `MCP error -32000: Connection closed` and a ModuleNotFoundError on stderr.
Visible to anyone who launches opencode from `
/Projects/memorypalace`: an ERROR line per session, even though the user-level `/.config/opencode/opencode.jsonc` wrapper continues to work in parallel.Fix: use `.venv/bin/python` (relative; resolves against the opencode cwd = repo root). Works for every contributor who ran `uv sync`.
Why fork-ahead instead of patching upstream
Upstream's intent was "portability across install methods (pip vs uv vs dev install)" per Gemini's review on MemPalace#1567. That intent is fine, but the actual upstream landing — bare `python` — assumes the contributor has activated their venv before launching opencode. uv users typically don't activate manually; uv handles it transparently for `uv run`, but opencode launches its own subprocess and inherits the unmodified shell PATH.
This commit picks the path that's correct for the uv setup the README documents. Filing an upstream PR to follow.
Test plan
🤖 Generated with Claude Code