Opening this as a new issue since #1407 ("Jupyter kernel startup delayed 30s when extension is installed (pixi environment)") is locked and can no longer receive comments, despite being closed only due to staleness rather than resolution — multiple users in that thread confirmed the bug persisted across many extension versions right up until the lock. I'm hitting the identical issue on a platform not yet represented there (WSL2; prior reports were macOS/Windows), so filing this to keep it tracked.
Environment:
- VS Code: 1.130.0 (WSL, desktop)
ms-python.python: 2026.4.0ms-python.vscode-python-envs: 1.36.0ms-toolsai.jupyter: 2025.9.1- Platform: linux x64 (WSL2)
- Package manager: pixi
Symptoms match #1407 exactly:
10:04:29.821 [warn] Failed to get activated env vars for ~/project/.pixi/envs/default/bin/python in 35151ms
In my case it compounds further — the kernel gets disposed and reselected between different interpreters multiple times in a row (seemingly automatic, not user-initiated), and each reselection re-triggers the same ~30-35s stall, making it look like an indefinite hang rather than a one-time delay. The Python Environments output channel shows the same conda-detection fallback (pet_conda::package: Unable to find conda package Python in ".../pixi/envs/default", trying slower approach) re-firing repeatedly against the identical path over the course of hours in a single session — I have logs showing the same non-conda path being re-probed via this fallback continuously from session start to +17,800 seconds later, rather than the negative result being cached after the first check.
I confirmed this isn't pixi/shell being slow — pixi shell-hook for the same environment completes in under a second when run directly. This lines up with the root cause identified by Jan Ivar Korsbakken (@korsbakken) in #1407: the underlying command uses pixi shell (which starts an interactive shell that never returns on its own) rather than pixi run, so the &&-chained follow-up commands never execute and the whole thing stalls until timeout.
Workaround (confirmed by multiple users in #1407): setting "python.useEnvironmentsExtension": false, or disabling ms-python.vscode-python-envs entirely.
Related: #1407, renan-r-santos/pixi-code#21, renan-r-santos/pixi-code#28, renan-r-santos/pixi-code#43
Opening this as a new issue since #1407 ("Jupyter kernel startup delayed 30s when extension is installed (pixi environment)") is locked and can no longer receive comments, despite being closed only due to staleness rather than resolution — multiple users in that thread confirmed the bug persisted across many extension versions right up until the lock. I'm hitting the identical issue on a platform not yet represented there (WSL2; prior reports were macOS/Windows), so filing this to keep it tracked.
Environment:
ms-python.python: 2026.4.0ms-python.vscode-python-envs: 1.36.0ms-toolsai.jupyter: 2025.9.1Symptoms match #1407 exactly:
In my case it compounds further — the kernel gets disposed and reselected between different interpreters multiple times in a row (seemingly automatic, not user-initiated), and each reselection re-triggers the same ~30-35s stall, making it look like an indefinite hang rather than a one-time delay. The Python Environments output channel shows the same conda-detection fallback (
pet_conda::package: Unable to find conda package Python in ".../pixi/envs/default", trying slower approach) re-firing repeatedly against the identical path over the course of hours in a single session — I have logs showing the same non-conda path being re-probed via this fallback continuously from session start to +17,800 seconds later, rather than the negative result being cached after the first check.I confirmed this isn't pixi/shell being slow —
pixi shell-hookfor the same environment completes in under a second when run directly. This lines up with the root cause identified by Jan Ivar Korsbakken (@korsbakken) in #1407: the underlying command usespixi shell(which starts an interactive shell that never returns on its own) rather thanpixi run, so the&&-chained follow-up commands never execute and the whole thing stalls until timeout.Workaround (confirmed by multiple users in #1407): setting
"python.useEnvironmentsExtension": false, or disablingms-python.vscode-python-envsentirely.Related: #1407, renan-r-santos/pixi-code#21, renan-r-santos/pixi-code#28, renan-r-santos/pixi-code#43