Repository navigation
Kernel detection loop which causes high resource use #25815
Description
Type: Bug
General description
When opening an .ipynb document in vscode in the Explorer menu, it causes the kernel detection to run indefinitely, even though the kernel was already detected in the previous sessions and the Python code in the document can run just fine. Also, I have noticed that this kernel detection causes significant resource use.
Steps to reproduce
The following video shows me reproducing the issue:
https://youtu.be/CRF52A-vemc
Here are the steps I took in that video:
(1.) Create an .ipynb Jupyter Notebook project
(2.) Create a Python .venv in the folder of that project
3. Open that folder in vscode
4. Open the Explorer side-menu and open the .ipynb document there
5. Done. Observe the kernel detection indicator in the top-right corner
Detailed description
As one can see in the video, the reload arrows flickers, which indicates that vscode seemingly fails to detect the already set-up Python venv kernel. In my example, the .ipynb already contains Python code that got executed in previous sessions. When I create a new cell with new code, f.e. print("Test"), it runs and shows Test, meaning that the kernel is functioning. Even after executing the new cell, the flickering doesn't stop.
The action that causes this bug, as I have figured out, is opening the .ipynb document via the Explorer menu. When I instead closed vscode with the .ipynb document tab open before closing vscode, and then reopened vscode again, the aforementioned flickering didn't happen. So, the issue can be avoided if one first opens the .ipynb document via the Explorer menu, then closes vscode, and then opens it again, since the .ipynb document tab will be open on second launch. This doesn't solve the issue permanently, however: every time I restart vscode with that tab closed and open the .ipynb document with the Explorer menu, the bug happens again. I also experienced that bug happening even when the tab was open at vscode start, but I can't reliably reproduce it.
In addition to the visual annoyance that this bug causes, I have also observed significant resource usage. When I open the folder from the video above in vscode with 3 tabs (.tex, .ipynb and .pdf) open, the CPU usage is somewhere around 2% (see figures 1, 2):
However, when I open the folder in vscode with the .ipynb tab closed before I closed vscode, and then when I repeat the Steps to reproduce, the CPU is used at about 20%, with the heaviest processes being from vscode (see figures 3, 4):
This implies that this kernel detection loop isn't just a visual issue that causes flickering of the loading arrows, but is actually trying to locate the kernel and uses a lot of resources for that. To repeat myself, the kernel actually works fine both when the .ipynb document is launched with the Explorer menu, as well when the tab is already open at vscode launch.
Extension version: 2025.10.2026010601
VS Code version: Code 1.109.5 (072586267e68ece9a47aa43f8c108e0dcbf44622, 2026-02-19T19:43:32.382Z)
OS version: Linux x64 6.17.0-14-generic snap
Modes:
System Info
| Item | Value |
|---|---|
| CPUs | 13th Gen Intel(R) Core(TM) i9-13900H (20 x 754) |
| GPU Status | 2d_canvas: unavailable_software GPU0: VENDOR= 0xffff [Google Inc. (Google)], DEVICE=0xffff [ANGLE (Google, Vulkan 1.3.0 (SwiftShader Device (Subzero) (0x0000C0DE)), SwiftShader driver-5.0.0)], DRIVER_VENDOR=SwANGLE, DRIVER_VERSION=5.0.0 ACTIVE Machine model name: Machine model version: direct_rendering_display_compositor: disabled_off_ok gpu_compositing: disabled_software multiple_raster_threads: enabled_on opengl: disabled_off rasterization: disabled_software raw_draw: disabled_off_ok skia_graphite: disabled_off trees_in_viz: disabled_off video_decode: disabled_software video_encode: disabled_software vulkan: disabled_off webgl: unavailable_software webgl2: unavailable_software webgpu: disabled_off webnn: unavailable_software |
| Load (avg) | 2, 1, 0 |
| Memory (System) | 15.24GB (9.73GB free) |
| Process Argv | --no-sandbox /home/marko-havryshko/Documents/University/Praktikum/PAP2.2/Versuch 251 --ozone-platform=x11 --crash-reporter-id f5c3b367-4b45-4c56-9182-ba053bd281d0 |
| Screen Reader | no |
| VM | 0% |
| DESKTOP_SESSION | plasma |
| XDG_CURRENT_DESKTOP | KDE |
| XDG_SESSION_DESKTOP | KDE |
| XDG_SESSION_TYPE | wayland |
A/B Experiments
vsliv368cf:30146710
binariesv615:30325510
nativeloc1:31344060
dwcopilot:31170013
dwoutputs:31242946
copilot_t_ci:31333650
e5gg6876:31282496
pythonrdcb7:31342333
6518g693:31463988
aj953862:31281341
82j33506:31327384
6abeh943:31336334
envsactivate1:31464700
cloudbuttont:31379625
aihoversummaries_t:31453032
3efgi100_wstrepl:31403338
use-responses-api:31390855
ec5jj548:31422691
cp_cls_t_966_ss:31454198
4je02754:31466945
a5gib710:31434435
7a04d226_do_not_restore_last_panel_session:31438103
cp_cls_c_1081:31454833
a43f0575b:31442825
e9c30283:31461165
idci7584:31464702
edit_mode_hidden:31461530
864ei723_large_tool_results_to_disk:31460878
showingstats:31457202
i54ji102:31458073
chat:31457767
Activity
Glampi42 commentedon Feb 26, 2026
Update: I have found another reproducible way to trigger the bug described above.
Steps to reproduce
(-1.) Create a folder with a .tex and a .ipynb document
(0.) Create a venv Python envo in that folder
What doesn't cause the bug:
So, when the .ipynb document is the one that is active before closing vscode, then the bug doesn't happen. However, if one starts vscode with a different tab being active before closing vscode in the previous session, and then switches to the .ipynb document tab, the kernel detection loops.
david-cortes commentedon Mar 7, 2026
For me a similar issue happens also when restoring saved interactive windows, right when launching vscode.
Bump version to 2026.2.0 in package.json (#25801)
eleanorjboyd commentedon Mar 11, 2026
Thanks for the issue report! To help us investigate, could you please include logs from the Python output and the Jupyter channel? Here's how to get them for python (same process but different output panel for Jupyter:
🐍 How to Get Logs from the Python Output Channel
Ctrl+Shift+PorCmd+Shift+Pon Mac).Most likely root cause: An event feedback loop between the Jupyter extension's kernel resolution and the Python environments extension's onDidChangeEnvironments events. The resolve() method in venvManager.ts calls addEnvironment() which fires change events even if the environment already exists, potentially causing Jupyter to re-request resolution in a loop. Investigating this theory
Glampi42 commentedon Mar 12, 2026
Pythonoutput panel logs:^ seems nominal to me.
Python Environmentsoutput panel logs:^ seems to resolve the environment non-stop.
Jupyteroutput panel logs:^ doesn't produce logs non-stop like Python Environments does.
Glampi42 commentedon Mar 12, 2026
The start of the
Python Environmentsoutput panel log, before it starts the infinite loop:Glampi42 commentedon Mar 12, 2026
The logs above were made with info log level, didn't know it resets to the info-level every new session. Here is the start of
Python Environmentsoutput panel logs in log level trace:Glampi42 commentedon Apr 27, 2026
As of the latest VSCode version, the issue seems to have been resolved since I can't reproduce the bug anymore. Thanks, I'm closing this issue.