Kernel detection loop which causes high resource use

[Glampi42]

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

[Glampi42]

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

1. Open the folder in vscode; open both .tex and .ipynb documents in the Explorer menu
2. Select the .tex document tab as the active tab
3. Close vscode
4. Open the folder in vscode
5. Switch to the .ipynb document tab
6. Done. The bug happens, and the CPU usage rises

What doesn't cause the bug:

1. Open the folder in vscode; open both .tex and .ipynb documents in the Explorer menu
2. Select the .ipynb document tab as the active tab
3. Close vscode
4. Open the folder in vscode

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.