Skip to content

Chatbook doesn't work with nb_conda_kernels (kernel names assumed to be chatbook / plain kernelspec names) #506

Description

@xhejtman

Environment: notebook-intelligence 6.1.0, nb_conda_kernels installed in the same conda env (default configuration), JupyterHub single-user server.

Problem

nb_conda_kernels lists kernelspecs from conda environments under its own names and removes the original names from the server's kernel list. chatbook becomes conda-base-chatbook ("Chatbook [conda env:base] *"), and python3 becomes conda-base-py. Chatbook fails with these names:

  1. Running any cell in a Chatbook notebook fails with Chatbook backend kernel 'conda-base-py' is not installed. Choose an installed kernelspec in Settings → Chatbook. Yet conda-base-py is what Settings → Chatbook offers. python3 isn't offered at all, because the server doesn't list it.
  2. When the backend does resolve (for example, the setting is empty and the kernel falls back to the plain python3 spec on disk), cells never finish. They stay at [*] with no output and no Run confirmation.

Cause

  • The Chatbook kernel lists and starts backend kernels with a plain jupyter_client.kernelspec.KernelSpecManager() (chatbook_kernel/backend.py: load_kernel_specs(), ChatbookBackend.start()). The Settings UI lists kernels from the server's configured kernelspec manager (nb_conda_kernels.CondaKernelSpecManager), so the two sides use different names.
  • The frontend and server extension recognize Chatbook only by the exact kernelspec name chatbook. In the frontend this covers session detection (the execute wrapper, IOPub handling, toolbar), the "New Chatbook" command (which requests kernel chatbook) and the backend dropdown filter. In the server extension it covers the execution-mode cap and NBI_CHATBOOK_POLICY=force-off. None of these apply to conda-base-chatbook.

What needs to be fixed

  1. Resolve and start backend kernels with the same kernelspec manager (class and config) as the Jupyter server, so backend names match the ones the UI offers.
  2. Identify Chatbook kernels by kernelspec language (chatbook) instead of by name, in both the frontend and the server extension. Create new Chatbooks by language, and exclude Chatbook kernels from the backend list.

I have a working patch for both and can open a PR.

Activity

  1. pjdoland commented on Sep 28, 2026

    @pjdoland
    Collaborator

    Thank you for the detailed report and the diagnosis. I checked it against main, and it holds up:

    • chatbook_kernel/backend.py lists backends with a plain KernelSpecManager() and starts them with a plain KernelManager, while Settings lists them from the server's configured manager.
    • nb_conda_kernels renames the specs in an environment's share/jupyter/kernels to conda-base-<name> (python3 becomes conda-base-py) and drops the original name when it points at the same directory. The chatbook spec NBI installs into the environment therefore surfaces only as conda-base-chatbook.
    • Chatbook is recognized by the exact name chatbook in the frontend (isChatbookKernelName, the New Chatbook command, the backend filter) and in the server extension (the execution-mode cap and the force-off hiding in extension.py). A renamed Chatbook kernel therefore also escapes NBI_CHATBOOK_POLICY=force-off and the admin execution-mode cap. That makes the language-based check worth having for policy reasons too.

    Your two fixes sound right to me. Please go ahead and open the PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions