Storing Claude Code API keys in KeePassXC instead of plaintext config(mareksuppa.com)
mareksuppa.com
Storing Claude Code API keys in KeePassXC instead of plaintext config
https://mareksuppa.com/til/keepassxc-claude-code-api-keys/
3 comments
Author here. I wrote this after setting up Claude Code with MiniMax and Z.AI and realizing their docs all tell you to paste API keys into settings.json in plaintext -- which is risky given that Claude Code has been known to read .env files and leak contents into session transcripts. I already use KeePassXC, so I wrote a shell wrapper that fetches the key at invocation time and passes it as an inline env var. Nothing is written to disk. The same pattern works with any password manager CLI -- op read for 1Password, bw get password for Bitwarden, pass show for pass. Happy to answer questions.
You might like https://varlock.dev (free and open source) - it has a plugin system so you can follow this pattern but pull from many different backends. Plus it provides a lot more... like being able to import shared config/schema from other files, validation, log redaction, composing values together with functions.
Keepass plugin is in an open PR, should be merged soon!
Keepass plugin is in an open PR, should be merged soon!
good catch on the leakage risk - the pattern of "agent reads .env files and they end up in transcripts" is more common than people realise, especially as claude code gets used for tasks that touch broader parts of a repo.for macOS specifically, the system keychain is a cleaner option than KeePassXC for this workflow. `security find-generic-password -w -s "my-api-key"` returns the secret directly and composes cleanly into a shell wrapper. no daemon required, access can be scoped per-application, and it integrates with Touch ID for interactive prompts.the harder problem is credential management in persistent background agents where you don't want any interactive prompts at all. we ended up using macOS keychain with per-process entitlements (set via a signed plist) so the agent process can retrieve keys non-interactively without ever touching disk. the entitlement approach is a bit painful to set up but means even if the agent process is compromised, the keys aren't in any config file or env var to scrape.(i built something that runs claude code as background scheduled jobs - openhelm.ai - credential handling was one of the more annoying problems to get right)