Clearing Previous Kernels from JupyterLab History?

I’ve been running into an issue while authoring an extension where Jupyterlab will attempt to connect to kernels which don’t exist anymore, which has been slowing down startup times. If its helpful, I get errors like this:

[W 2026-06-03 23:16:35.510 ServerApp] wrote error: 'Kernel does not exist: 363dd351-cb08-4564-b83b-f55aa025e09e'
    Traceback (most recent call last):
      File "/Users/.../.virtualenvs/nod-ryhi/lib/python3.14/site-packages/tornado/web.py", line 1880, in _execute
        result = await result
                 ^^^^^^^^^^^^
      File "/Users/.../.virtualenvs/nod-ryhi/lib/python3.14/site-packages/jupyter_server/auth/decorator.py", line 73, in inner
        return await out
               ^^^^^^^^^
      File "/Users/.../.virtualenvs/nod-ryhi/lib/python3.14/site-packages/jupyter_server/services/kernels/handlers.py", line 75, in get
        model = await ensure_async(km.kernel_model(kernel_id))
                                   ~~~~~~~~~~~~~~~^^^^^^^^^^^
      File "/Users/.../.virtualenvs/nod-ryhi/lib/python3.14/site-packages/jupyter_server/services/kernels/kernelmanager.py", line 513, in kernel_model
        self._check_kernel_id(kernel_id)
        ~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^
      File "/Users/.../.virtualenvs/nod-ryhi/lib/python3.14/site-packages/jupyter_server/services/kernels/kernelmanager.py", line 544, in _check_kernel_id
        raise web.HTTPError(404, "Kernel does not exist: %s" % kernel_id)
    tornado.web.HTTPError: HTTP 404: Not Found (Kernel does not exist: 363dd351-cb08-4564-b83b-f55aa025e09e)

It seems like when JupyterLab restarts, it looks for previous connection files and tries to start them up again. How can I prevent this from happening? Is there a way to disable this within JupyterLab? It seems like this is originating from JupyterLab (or at least the client) because the Jupyter server reports the associated 404 error:

[W 2026-06-03 23:23:33.145 ServerApp] 404 GET /api/kernels/25994376-79eb-4b7e-a89b-a45a841e6521?1780554213141 (``596974b570b24182a540183b64f4a51a@127.0.0.1``) 0.84ms referer=http://localhost:8888/lab/workspaces/auto-t/tree/.nod/connection/moduleC.ipynb.

Any pointers would be really helpful! Happy to provide more context about my setup, but I figured this was the crucial info. Thank you so much!

I actually figured out what was going wrong – jupyter was not keeping a history at all, but I was generating and then quickly deleting notebook files that jupyter could see and was trying to load kernel sessions for. I’ll leave this in case its useful to anyone else.

Hi Erawn, could you please explain a little bit more your solution? I had same issue, my job running automatically, so I put extra steps (restore and reactivate customized kernel) before trigger the job. Could you please share your example? Thank you!