fix(mcp): resolve absolute synthpanel launcher for mcp install (#539)#541
Merged
Conversation
`synthpanel mcp install` wrote `command: "synthpanel"` whenever
`shutil.which("synthpanel")` returned None — which happens when the
install is run from a venv whose bin dir is not on PATH. The MCP host
then can't launch the bare literal and the server silently fails to
start.
resolve_command now resolves a robust absolute path before the literal
fallback:
1. explicit --command (verbatim)
2. shutil.which("synthpanel") -> realpath
3. the running console script (realpath of argv[0]) when it names a
synthpanel launcher
4. a synthpanel launcher beside sys.executable (checking the literal
interpreter dir first, since a venv's python is a symlink whose
realpath points at the base interpreter and would miss the venv's
console script), then beside the realpath'd interpreter
5. literal "synthpanel" only as a last resort
Updates the --command help text and adds unit tests covering the
venv/not-on-PATH resolution, the which path, the interpreter-adjacent
path, and the final literal fallback.
Closes #539
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
claude-dataviking
requested review from
openclaw-dv and
the-data-viking
as code owners
Deploying synthpanel with
|
| Latest commit: |
e3a7b8d
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://51285905.synthpanel.pages.dev |
| Branch Preview URL: | https://fix-mcp-install-resolve-comm.synthpanel.pages.dev |
the-data-viking
approved these changes
Jun 3, 2026
the-data-viking
added a commit
that referenced
this pull request
Jun 3, 2026
Cuts the patch release containing the four bug fixes merged today (#540 cost hint, #541 mcp-install path, #542 dry-run vision guard, #543 report synthesize hint) plus the attachments docs (#535). Pre-bumps __version__.py and re-renders the version artifacts (render_site.py, render_site_markdown.py, render_server_card.py) so auto-tag.yml hits its "nothing to commit" path and only tags v1.5.6 — its direct version-bump push to main is currently rejected by branch protection (GH013), which is why applying semver:patch to a regular fix PR (#543) failed to release. Filing that pipeline issue separately. Co-authored-by: Wesley Johnson <wesley@dataviking.tech> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
synthpanel mcp installregistered a barecommand: "synthpanel"whenevershutil.which("synthpanel")returned None — which is exactly the case when the install is run from a venv whosebindir is not onPATH. The MCP host then can't launch the unqualified literal and the server silently fails to start.resolve_commandnow resolves a robust absolute path before the literal fallback:--command(verbatim)shutil.which("synthpanel")→realpathrealpath(sys.argv[0])) when it names asynthpanellauncher — the venv-installed entry point even when its bin is off PATHsynthpanellauncher besidesys.executable— canonical venv layout. The literalsys.executabledir is checked first because a venv'spythonis a symlink whoserealpathpoints at the base interpreter (and would miss the venv's own console script); the realpath'd dir is the fallback for non-venv layouts."synthpanel"only as a last resortVerified manually: with
PATHstripped and a non-synthpanelargv[0], resolution now yields the absolute venv path<venv>/bin/synthpanelinstead of the literal.Also updates the
--commandhelp text inparser.py.Tests
Added to
tests/test_mcp_install.py::TestHelpers:test_resolve_command_prefers_whichtest_resolve_command_uses_venv_argv0_when_not_on_path(the mcp install writes bare 'command: synthpanel' from a venv (PATH-fragile); resolve absolute path #539 repro)test_resolve_command_uses_synthpanel_next_to_interpretertest_resolve_command_falls_back_to_literal(tightened to control PATH/argv0/executable)Gates
ruff check ./ruff format --check .: passpytest tests/test_mcp_install.py tests/mcp: 84 passed, 1 skippedCloses #539
🤖 Generated with Claude Code