OPENAI_API_KEY env variable has precedence over OPENAI_API_KEY set in sgptrc
Using sgptrc should have higher value than exporting env variables. Eg. if I am exporting OPENAI_API_KEY from my shell for deafult openai endpoint but want to use some different in sgpt, I cannot override it in sgptrc.
Either I have to unset OPENAI_API_KEY or set OPENAI_API_KEY to value matching my alternative openai endpoint.
Also I am missing option to reference env variables from sgptrc, eg.:
OPENAI_API_KEY=${MY_ENDPOINT_API_KEY}
Also if USE_LITELLM is true, OPENAI_API_KEY in sgptrc seems ignored as well as API_BASE_URL.
UPDATE: Hmm, based on this it seems to be a "feature not a bug" 🤔 https://github.com/TheR1D/shell_gpt/blob/b7cad0bd8513728ee37f8a19d9444b36c449eb72/sgpt/config.py#L86
This is correct behavior in general, but most tools don't reuse environment variables from other tools to this extent. I would consider not exporting OPENAI_API_KEY or any credentials in this way, because if you e.g., run an npm install, that environment variable is passed to every lifecycle script defined in every dependency in your project. Could be quite a few completely unverified scripts with access to that key. Use a .env file or use a password manager with a cli helper to inject it at runtime, or write a shell function wrapper like this:
function sgpt() {
unset OPENAI_API_KEY
\sgpt "$@"
}
which will allow sgpt to manage it.
Yes, I am using similar approach as a workaround. But main issue for me is that sgpt is using something that should work as typical shell rcfile but it does not at all (env is not interpolated, even ~ in path does not expand to HOME, etc.) Either this should be fixed (to simulate shell behavior which was probably idea behind) or some other, more predictable, config approach should be picked.