Feature Request: Store API Keys in Config File

[philippkant]

Feature Request: Store API Keys in Config File

Problem

Currently, API keys must be stored as environment variables (via .bashrc, .zshrc, or .env files). This creates a security concern because:

1. Environment variables are process-accessible: When API keys are set in .bashrc or .zshrc, they become available to all processes running in that shell session. Other applications can read these environment variables without explicit user consent.

2. Lack of isolation: There's no way to ensure that only summarize can access the API keys. Any script or application running in the same shell can access OPENAI_API_KEY, GEMINI_API_KEY, etc.

3. Security best practice: Applications should ideally manage their own credentials in isolated storage rather than relying on global environment variables.

Proposed Solution

Add support for storing API keys in ~/.summarize/config.json:

{
  "model": "openai/gpt-5-mini",
  "apiKeys": {
    "openai": "sk-...",
    "anthropic": "sk-ant-...",
    "google": "...",
    "openrouter": "sk-or-...",
    "xai": "...",
    "zai": "..."
  }
}

Benefits

• Isolation: Keys are only accessible to summarize when it reads its config file
• Consistency: Matches the pattern already used for other settings (model, theme, cache, etc.)
• Security: Reduces the attack surface compared to global environment variables
• User control: Users can explicitly choose which application has access to their keys

Precedence

If implemented, the precedence could be:

1. Environment variables (highest priority, for backward compatibility)
2. Config file apiKeys section
3. Error if key is missing when needed

This maintains backward compatibility while providing the new secure option.

Current Workaround

The only current workaround is using a .env file in the working directory, but this still has the same security issue if other tools read .env files, and it's less convenient than a centralized config.

---

Note: The daemon config (~/.summarize/daemon.json) already supports storing environment variables, but this is only for the Chrome extension daemon, not for regular CLI usage.