Chat window works, but IPython magics do not

[sg-s]

Description

I installed jupyter, jupyterai and langchain-openai in a clean environment (using pixi). I entered my openAI api key and the chat window seems to work. however, using the %%ai magic in the notebook doesn't work

Reproduce

screenshot showing that the chat window works

screenshot showing that it knows about my openAI key:

error:

AuthenticationError: Error code: 401 - {'error': {'message': 'Incorrect API key provided: sk-QoS0U***************************************KCxR. You can find your API key at https://platform.openai.com/account/api-keys.', 'type': 'invalid_request_error', 'param': None, 'code': 'invalid_api_key'}}

Expected behavior

it to not throw an authenticationerror

Context

jupyter = ">=1.1.1,<2"
jupyterlab = ">=4.2.5,<5"
jupyter-ai = ">=2.28.1,<3"
langchain-openai = ">=0.1.25,<0.2"

[sg-s]

i found workaround: i had to manually specify my key in the notebook using:

env OPENAI_API_KEY = <my key>

the clue was that

'Incorrect API key provided: sk-QoS0U***************************************KCxR.

is not my key

no idea why it decides to use some randomn key instead of the one i entered in the notebook

[dlqqq]

@sg-s Jupyter AI magic commands can't read API keys from the chat settings in the UI. They only read from the set of environment variables. This is a known issue, and is due to a technical difficulty with passing data between the notebook kernel and the server.

What likely happened is that OPENAI_API_KEY was set to an outdated API key or an incomplete API key (e.g. perhaps you only copied the first 30 characters of the API key).

If you want to use both chat & magics simultaneously, we recommend setting the API key with both the environment variable OPENAI_API_KEY and through the chat settings for now.

This is definitely a usability issue that we should address in v3.0.0. I'll add it to our roadmap.

[sg-s]

thanks for the response!

[MaicoTimmerman]

Depending on the solution considered here, I think it's important to consider the use-case that kernels might not be running on the same machine as the JupyterLab server. An approach could be to use Jupyter's communication protocols to bring the API key to the kernel.

[dlqqq]

@MaicoTimmerman Thanks for the technical reference. I'm not very familiar with Jupyter kernels, so this helps.

[krassowski]

An approach could be to use Jupyter's communication protocols to bring the API key to the kernel.

Static-ish things like API can also be propagated by environment variables, the downside is that these are not updated after kernel starts (i.e. kernel needs to be restarted for the new one to take effect). Maybe this is what happened in the original issue?

[krassowski]

More generally JupyterLab, could benefit from having a first-class citizen Credentials Store. Someone recently brought up to my attention that Google Colab has a Secrets tab in the sidebar:

and that there is a (non-maintained) https://github.com/frankzickert/jupyterlab-credentialstore extension for JupyterLab implementing a similar approach.

We could pass the secrets via environment variables (we already pass JPY_SESSION_NAME down to the kernel to let user now the notebook name).

It feels like moving some of that logic out of jupyter-ai would be a good investment because we would have only one place where we need to validate the logic for security (rather than multiple implementations). The benefits of reuse would seem higher than in the current effort to reuse the chat component.

Any thoughts?

[krassowski]

I moved my above comment to a new issue #1237 with a better title.

[dlqqq]

Closing this issue since OP's issue was resolved. Let's use separate issues like #1237 to discuss how to unify the authentication mechanisms for both AI & magics.