# Accept extra kernel options from user and pass it to session api in backend

**URL:** <https://discourse.jupyter.org/t/accept-extra-kernel-options-from-user-and-pass-it-to-session-api-in-backend/25753>\
**Category:** extensions\
**Tags:** jupyterlab, how-to, help-wanted\
**Created:** [May 17, 2024, 5:49am UTC](https://discourse.jupyter.org/t/accept-extra-kernel-options-from-user-and-pass-it-to-session-api-in-backend/25753 "2024-05-17T05:49:10Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Sneha\_Saharawat](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.jupyter.org/sneha_saharawat/32/13423_2.png) [@Sneha\_Saharawat](https://discourse.jupyter.org/u/Sneha_Saharawat)\
**Post date:** [May 17, 2024, 5:49am UTC](https://discourse.jupyter.org/t/accept-extra-kernel-options-from-user-and-pass-it-to-session-api-in-backend/25753/1 "2024-05-17T05:49:10Z")

</div>

I want to build a lab extension to make some UI changes in JupyterLab to accept extra arguments for spawning kernel. I then want to pass these extra arguments to POST /api/sessions so that backend can make use of it.

For example:  
Currently what happens is from the launcher when we click on ipykernel to create a notebook, command to create a notebook is executed. It further triggers two more command docmanager:new-untitled and docmanager:open. The docmanager:open command opens a file, create a sessionContext and call SessionManager to start a session. It is at this step that post call to /api/sessions is made and kernel is created.

In my extension, I want to add a dialogForm when user clicks on ipykernel to take kernel specific extra options. The rest of the flow would remain the same but I want to propagate these kernel options in the flow to pass it to /api/sessions.

I want to understand if there is any clean way to do it in my extension.

There are two approaches I have come up with so far:

- Create a session/kernel separately from the kernelOptions and kernel specs. Create a notebook with no-kernel. Attach the created session with the notebook later on. The cons of this approach is that there might be race conditions and user experience would also be not that optimal

- The second approach is to save the kernelOptions along with notebook identifier in IStateDB. Before making a post call to sessions api, I can check the IStateDB for kernelOptions against the notebook. If it is present, we can add it to body for POST /api/sessions.

Any suggestions or thoughts would be appreciated. I am also keen to hear if there is any better approach to do this.