Remote SSH Linux: Cursor installs universal ms-python.python — missing PET binary, Python Environments broken

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

On Remote SSH (Linux x64), Cursor installs the universal build of ms-python.python, which is missing the native PET (python-env-tools/bin/pet) binary.

  • Python Environments fails to initialize; interpreter paths cannot be validated even when the bench venv exists and works in the terminal.
  • Cursor Pyright reports that ms-python.python is missing or broken (hard dependency).
  • Installing the same extension version via the linux-x64 VSIX from the Microsoft Marketplace fixes the issue immediately.

Old (Cursor default install on Remote SSH Linux):

cursor --install-extension ms-python.python

(or auto-install on reconnect) deploys a universal package, e.g. ms-python.python-2025.4.0.

Extension folder has no python-env-tools/ directory.

Output panel (Python Environments):

spawn .../ms-python.python-2025.4.0/python-env-tools/bin/pet ENOENT
Failed to initialize environment managers: Python extension not found

Output panel (Cursor Pyright):

Cursor Pyright depends on the `ms-python.python` extension, which is not installed.

Bench Python at /home/frappe/frappe-bench-15/env/bin/python works in shell; extension still marks it unresolvable.

New (manual linux-x64 VSIX install — expected Cursor behavior):

Install ms-python.python with targetPlatform=linux-x64 from VS Marketplace.

Extension folder includes executable python-env-tools/bin/pet (~35 MB).

Output panel (Python Environments):

[pet] Starting Python Locator .../python-env-tools/bin/pet server
Resolved Python Environment /home/frappe/frappe-bench-15/env/bin/python
Environment discovery complete: 2 environments found (Global: 1, venv: 1)

Cursor Pyright and Ruff work; no PET / missing-extension errors.

Steps to Reproduce

  1. Connect to a Linux x64 host via Cursor Remote SSH.

  2. Open a workspace folder (e.g. Frappe bench apps/).

  3. Install Python stack:

cursor --install-extension anysphere.cursorpyright --force
cursor --install-extension ms-python.python --force
cursor --install-extension charliermarsh.ruff --force
  1. Reload window.

  2. Open OutputPython Environments and Cursor Pyright.

  3. Observe pet ENOENT and/or “Python extension not found”.

  4. On the server, confirm missing binary:

find ~/.cursor-server/extensions/ms-python.python-* -path '*/python-env-tools/bin/pet'
# universal build: no output
  1. Workaround verification — download linux-x64 VSIX and reinstall:
TMPDIR=$(mktemp -d) && cd "$TMPDIR"
curl -fsSL -o python.vsix.gz \
  "https://marketplace.visualstudio.com/_apis/public/gallery/publishers/ms-python/vsextensions/python/2026.5.2026070801/vspackage?targetPlatform=linux-x64"
gunzip -c python.vsix.gz > python.vsix
unzip -l python.vsix | grep 'python-env-tools/bin/pet'
cursor --install-extension "$TMPDIR/python.vsix" --force
  1. Reload window → PET starts; bench venv resolves.

Expected Behavior

  • On Remote SSH, when host platform is linux-x64, Cursor should install the platform-specific ms-python.python VSIX (with python-env-tools/bin/pet), not the universal build.
  • Or bundle/serve pet for the remote host arch when resolving ms-python.python / anysphere.python extension packs.
  • Python Environments should initialize successfully on Remote SSH Linux without manual VSIX workarounds.
  • Cursor Pyright should not report ms-python.python as missing when it is installed.

Screenshots / Screen Recordings

Attach screenshots of:

  1. Output → Python Environments — spawn …/ms-python.python-2025.4.0/python-env-tools/bin/pet ENOENT
  2. Output → Cursor Pyright — “Cursor Pyright depends on the ms-python.python extension, which is not installed.”
  3. Terminal on SSH host — find ~/.cursor-server/extensions/ms-python.python-* -path '*/python-env-tools/bin/pet' returning no output
  4. Terminal on SSH host — unzip -l python.vsix | grep 'python-env-tools/bin/pet' confirming linux-x64 VSIX has the binary
  5. Output → Python Environments — [pet] Starting Python Locator …/python-env-tools/bin/pet server (after VSIX install)

Operating System

Windows 10/11

Version Information

IDE (local — Menu → About Cursor → Copy):

Version: 3.13.10 (system setup)
VS Code Version: 1.128.0
Commit: 4f02290ccd9304f0e6bf8ee85f6e9106f02ac1f0
Date: 2026-07-23T21:41:07.333Z
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
OS: Windows_NT x64 10.0.26200

Remote SSH server:

Cursor server: 3.13.10 (commit 4f02290ccd9304f0e6bf8ee85f6e9106f02ac1f0, x64)
OS: Ubuntu 22.04.5 LTS
Host: vps.contaboserver.net (Contabo VPS)
Workspace: /home/frappe/frappe-bench-15/apps
Python venv: /home/frappe/frappe-bench-15/env/bin/python (3.10.12)

Extensions involved (remote):

[email protected]
[email protected] (broken — universal, installed by Cursor)
[email protected] (works — linux-x64, manual VSIX)
[email protected]
[email protected]
[email protected]

For AI issues: which model did you use?

N/A — extension install / Remote SSH bug, not model-specific.

For AI issues: add Request ID with privacy disabled

N/A — extension install / Remote SSH bug, not model-specific.

Additional Information

Workaround (current):

  • Do not rely on cursor --install-extension ms-python.python alone on Remote SSH Linux.
  • Always install ms-python.python linux-x64 VSIX from Microsoft Marketplace (?targetPlatform=linux-x64).
  • Query latest version:
curl -fsSL -X POST "https://marketplace.visualstudio.com/_apis/public/gallery/extensionquery" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json;api-version=7.1-preview.1" \
  -d '{"filters":[{"criteria":[{"filterType":7,"value":"ms-python.python"}],"pageNumber":1,"pageSize":1,"sortBy":0,"sortOrder":0}],"assetTypes":[],"flags":914}'
  • Set "python.languageServer": "None" in workspace settings so Cursor Pyright handles analysis (optional; avoids duplicate language servers).
  • Do not delete ~/.cursor-server expecting a clean auto-install — it often reinstalls the same broken universal build.

Related upstream issue:

microsoft/vscode-python#25820 — universal VSIX missing PET on Open VSX / non-Microsoft marketplaces.

Does this stop you from using Cursor

Yes - Cursor is unusable

Hey, thanks for the detailed report and for getting to a working setup via a VSIX.

[email protected] is a universal build without the PET binary. The reliable way to make sure you get linux-x64 on the remote host is to install a VSIX with an explicit targetPlatform=linux-x64:

  1. Remove the stale extension folder:
rm -rf ~/.cursor-server/extensions/ms-python.python-2025.4.0*
  1. Install the linux-x64 VSIX directly:
TMPDIR=$(mktemp -d) && cd "$TMPDIR"
curl -fsSL -o python.vsix.gz \
  "https://marketplace.visualstudio.com/_apis/public/gallery/publishers/ms-python/vsextensions/python/2026.5.2026070801/vspackage?targetPlatform=linux-x64"
gunzip -c python.vsix.gz > python.vsix
cursor --install-extension "$TMPDIR/python.vsix" --force
  1. Reload the window and check:
find ~/.cursor-server/extensions/ms-python.python-* -path '*/python-env-tools/bin/pet'

You should see the PET binary. After that, Python Environments and Cursor Pyright should come up. Note that an extension installed via this VSIX won’t auto update. If you want to update later, just repeat the manual install.

One more detail. On the same server build on our side commit 4f02290 the normal cursor --install-extension ms-python.python --force resolves to 2025.6.1-linux-x64 with PET, not universal. If your reinstall keeps coming back as 2025.4.0 universal, it looks like something in the VPS environment, for example marketplace egress or a stale cache on Contabo’s side. If you can, send the install lines from Output > Log (Remote Server) during the install. I want to see where it switches to universal. The VSIX steps above should unblock you right now either way.

Confirming this isn’t limited to Remote SSH on x64. We hit it in a Cursor devcontainer on linux-arm64 this week.

What matched your report: universal ms-python.python / ms-python.vscode-python-envs (no PET); platform VSIX from MS Marketplace fixed it; ms-python.debugpy installed as linux-arm64 while python/envs did not.

Extra failure mode: even with a platform python-envs VSIX, activation failed when Cursor kept ms-python.python at 2025.6.1 alongside a newer envs build (Cannot read properties of undefined (reading 'onDidChangeEnvironment')). Both extensions need matching platform builds.

Devcontainer constraints: can’t uninstall python-envs (Ansible 26.x depends on it); python.useEnvironmentsExtension: false avoids one crash but breaks interpreter validation; extensions.json can point at a removed universal dir after manual repair.

Workaround: postAttachCommand script installs both platform VSIXes via MS Marketplace API on attach, removes stale universal dirs.

@deanrie - on our side (devcontainer, arm64, Cursor 3.13.21) cursor --install-extension ms-python.python --force did not resolve to a platform build with PET, so the behaviour you see on 4f02290 (linux-x64) doesn’t seem consistent across arch/environments.

@user544 thanks, this is a valuable data point. It confirms the issue is broader than Remote SSH on x64. You see the same behavior on devcontainer / linux-arm64, and --install-extension --force does not land in the platform build with PET. On our linux-x64 build 4f02290, force-install consistently resolves to 2025.6.1-linux-x64 with PET, so the arch or environment difference is exactly what we need to dig into.

The key detail from your report is Cannot read properties of undefined (reading 'onDidChangeEnvironment'). This happens when ms-python.python and ms-python.vscode-python-envs are installed from mismatched builds. So your approach via postAttachCommand to install both platform VSIX files on attach and remove stale universal folders is correct. Both extensions must be the same platform version, otherwise activation crashes even if PET is set up correctly.

To figure out why --force falls back to universal only for you, can you share the install lines from Output > Log (Remote Server / devcontainer) while running cursor --install-extension ms-python.python --force on arm64 3.13.21. I want to see where targetPlatform gets resolved. That will show whether this is an arch resolution issue or something environment specific.

I’ve logged the bug internally. I can’t give an ETA for the fix yet. For now, the VSIX workaround with matching platform builds of both extensions unblocks both x64 and arm64.