Problem
graphify currently discovers the Gemini backend key exclusively from two environment variables: GEMINI_API_KEY and GOOGLE_API_KEY. Security-conscious teams keep API keys out of shell environments entirely — storing them in macOS Keychain, 1Password, AWS Secrets Manager, HashiCorp Vault, or similar. These users either fall back to the (slower, more expensive) host-agent path on every run, or must break their secrets policy to get the Gemini fast path.
On macOS the idiomatic retrieval is:
```bash
security find-generic-password -s "GEMINI_API_KEY" -w
```
The key exists in Keychain but never appears in the environment, so graphify never sees it.
Proposed solution
Add a GRAPHIFY_GEMINI_KEY_CMD environment variable (or --gemini-key-cmd CLI flag) whose value is a shell command. When set and GEMINI_API_KEY/GOOGLE_API_KEY are absent, graphify runs the command and uses stdout as the key:
```bash
export GRAPHIFY_GEMINI_KEY_CMD="security find-generic-password -s GEMINI_API_KEY -w"
or: export GRAPHIFY_GEMINI_KEY_CMD="op read op://Personal/Gemini/credential"
```
This pattern is established in other tools (e.g. Git's credential.helper, Docker's credHelpers, aws --profile). It keeps the raw secret out of the environment while allowing graphify to retrieve it at invocation time.
Alternative
A ~/.config/graphify/config.toml (or .graphifyrc) that specifies a gemini_key_command field, evaluated at startup. This avoids even the intermediate env var.
Context
Discovered while running /graphify on two long-running research projects. The host-agent subagent path works correctly — this is purely a usability/cost issue for users following a secrets-manager discipline.
Problem
graphify currently discovers the Gemini backend key exclusively from two environment variables:
GEMINI_API_KEYandGOOGLE_API_KEY. Security-conscious teams keep API keys out of shell environments entirely — storing them in macOS Keychain, 1Password, AWS Secrets Manager, HashiCorp Vault, or similar. These users either fall back to the (slower, more expensive) host-agent path on every run, or must break their secrets policy to get the Gemini fast path.On macOS the idiomatic retrieval is:
```bash
security find-generic-password -s "GEMINI_API_KEY" -w
```
The key exists in Keychain but never appears in the environment, so graphify never sees it.
Proposed solution
Add a
GRAPHIFY_GEMINI_KEY_CMDenvironment variable (or--gemini-key-cmdCLI flag) whose value is a shell command. When set andGEMINI_API_KEY/GOOGLE_API_KEYare absent, graphify runs the command and uses stdout as the key:```bash
export GRAPHIFY_GEMINI_KEY_CMD="security find-generic-password -s GEMINI_API_KEY -w"
or: export GRAPHIFY_GEMINI_KEY_CMD="op read op://Personal/Gemini/credential"
```
This pattern is established in other tools (e.g. Git's
credential.helper, Docker'scredHelpers,aws --profile). It keeps the raw secret out of the environment while allowing graphify to retrieve it at invocation time.Alternative
A
~/.config/graphify/config.toml(or.graphifyrc) that specifies agemini_key_commandfield, evaluated at startup. This avoids even the intermediate env var.Context
Discovered while running
/graphifyon two long-running research projects. The host-agent subagent path works correctly — this is purely a usability/cost issue for users following a secrets-manager discipline.