Problem
Right now the practical choices for OPENAI_API_KEY are mostly:
- store it directly in
~/.config/shell_gpt/.sgptrc
- export it in the shell environment before running
sgpt
Both are awkward from a security perspective:
- plaintext in
.sgptrc is easy to leak accidentally
- globally exporting the key makes it available to unrelated subprocesses in that shell session
Narrow request
I am not asking for a full secret-management subsystem here. A smaller improvement could be:
- document password-manager-based runtime injection as a recommended pattern
- or add a minimal first-class mechanism for loading sensitive values at runtime
Current workaround
I am using pass and a shell wrapper so the key is injected only for the sgpt process:
if tty -s; then
export GPG_TTY="$(tty)"
fi
sgpt() {
local key
key="$(pass show api/openrouter/sgpt | head -n1)" || return
OPENAI_API_KEY="$key" command sgpt "$@"
}
This keeps secrets out of .sgptrc and avoids exporting them to the whole shell session.
In my case I originally tried putting command substitution directly into .sgptrc, but ShellGPT reads
that file literally, so something like:
OPENAI_API_KEY=$(pass show api/openrouter/sgpt | head -n1)
does not work.
Related existing issues
#709, #588
Problem
Right now the practical choices for
OPENAI_API_KEYare mostly:~/.config/shell_gpt/.sgptrcsgptBoth are awkward from a security perspective:
.sgptrcis easy to leak accidentallyNarrow request
I am not asking for a full secret-management subsystem here. A smaller improvement could be:
Current workaround
I am using
passand a shell wrapper so the key is injected only for thesgptprocess:This keeps secrets out of .sgptrc and avoids exporting them to the whole shell session.
In my case I originally tried putting command substitution directly into .sgptrc, but ShellGPT reads
that file literally, so something like:
OPENAI_API_KEY=$(pass show api/openrouter/sgpt | head -n1)does not work.
Related existing issues
#709, #588