Skip to content

fix(claude-code-mcp): resolve venv interpreter in the Windows Scripts/ layout (#1758, 3a)#2066

Open
eldar702 wants to merge 1 commit into
vectorize-io:mainfrom
eldar702:fix/1758-windows-venv-scripts-path
Open

fix(claude-code-mcp): resolve venv interpreter in the Windows Scripts/ layout (#1758, 3a)#2066
eldar702 wants to merge 1 commit into
vectorize-io:mainfrom
eldar702:fix/1758-windows-venv-scripts-path

Conversation

@eldar702

@eldar702 eldar702 commented Jun 8, 2026

Copy link
Copy Markdown

Problem

hindsight-integrations/claude-code/scripts/run_mcp.sh resolves the plugin venv interpreter via resolve_py(), which only probes ${VENV}/bin/python and ${VENV}/bin/python.exe. A standard Windows CPython venv — produced by the python.org installer, the Windows Store Python, and py -m venv — puts the interpreter at ${VENV}/Scripts/python.exe, never under bin/.

So on the common Windows setup resolve_py returns an empty $PY, the launcher falls through to venv re-creation, and re-creation then fails whenever python/python3 aren't on the spawning process's PATH (frequent when Claude Code's VS Code extension host spawns the server) → "MCP server never starts, no useful error".

This is sub-item 3a of #1758. The prior fix (#1564/#1565) only added the msys2/mingw bin/python.exe layout; this composes cleanly with it.

Fix (scripts/run_mcp.sh)

  • Add one elif branch to resolve_py() for the ${VENV}/Scripts/python.exe layout (with the matching Scripts/pip.exe).
  • Update the now-misleading venv create failed: no python interpreter at ${VENV}/bin/ message to also mention ${VENV}/Scripts/.

POSIX behaviour is unchanged — the new branch only matches Windows-layout venvs, and the existing bin/ branches still take precedence.

Test (RED-first)

New tests/test_run_mcp.py invokes the real bash resolve_py function (extracted from the script so none of its top-level side effects run) against a fabricated venv tree:

  • test_windows_scripts_layout_is_resolved — venv has Scripts/python.exe and no bin/. RED on main (resolve_py returns empty $PY), GREEN after the elif.
  • test_posix_bin_layout_is_resolved — regression guard asserting the POSIX bin/python path still wins.

Verification

$ python -m pytest tests/test_run_mcp.py -v   # pre-fix
test_windows_scripts_layout_is_resolved FAILED   # got: '' (the bug)
test_posix_bin_layout_is_resolved        PASSED

$ python -m pytest tests/                      # post-fix
183 passed in 0.61s
$ bash -n scripts/run_mcp.sh                    # syntax OK

Scope: 2 files, +105/-1, no new dependencies, scoped to 3a only.

🤖 AI-assistance: drafted with Claude (Opus 4.8), reviewed for correctness

…yout

run_mcp.sh's resolve_py() probed only <venv>/bin/python and
<venv>/bin/python.exe. A standard Windows CPython venv (python.org
installer, Windows Store Python, `py -m venv`) puts the interpreter at
<venv>/Scripts/python.exe, so resolve_py returned empty, the launcher
fell through to venv re-creation, and re-creation failed whenever
python/python3 were not on the spawning process's PATH (issue vectorize-io#1758, 3a).

Add a Scripts/ elif branch and update the now-misleading "venv create
failed" message to mention both layouts. POSIX behaviour is unchanged.

Adds a hermetic pytest that invokes the real bash resolve_py against a
fabricated venv tree: RED on the Scripts/ layout before this change,
plus a bin/ regression guard for the POSIX path.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@eldar702 eldar702 marked this pull request as ready for review June 10, 2026 22:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant