Repository navigation
[FEATURE]: Allow storage of secrets in system credential store. #4318
Description
Feature hasn't been suggested before.
- I have verified this feature I'm about to request hasn't been suggested before.
Describe the enhancement you want to request
Hi,
OpenCode currently stores auth tokens in a plaintext file (~/.local/share/opencode/auth.json). This works, but in my corporate environment we’re not allowed to keep access tokens unencrypted on disk, so I can’t use OpenCode. Would it be possible to add support for storing api keys in the system keyring instead?
Proposed approach:
Add opt-in keyring support using the @napi-rs/keyring library or Bun.secrets, which provides cross-platform access to system credential stores (GNOME Keyring/libsecret on Linux, Keychain on macOS, Credential Manager on Windows).
Implementation details:
- Opt-in only: Add a --keyring flag to opencode auth login that enables keyring mode. Default behavior remains unchanged.
- Config persistence: Once enabled, the setting persists in ~/.config/opencode/config.json so subsequent auth operations automatically use the keyring.
- Storage format: Store credentials in the system keyring with service name opencode, account name as the provider ID (e.g., anthropic, github-copilot), and the credential object as JSON.
Related issues:
#1703 - An implementation using Bun.secrets.
#2405 - Command-based API key loading (alternative approach using secret manager CLIs)
Activity
rekram1-node commentedon Nov 14, 2025
Yeah I think using Bun secrets would be rlly good
monostop commentedon Nov 14, 2025
I'll start on an implementation using Bun secrets. @rekram1-node, do you think it makes sense to keep old behavior (plain-text json file) as the default behavior for now and only enable the secrets implementation using the --keyring flag on the auth login command?
rekram1-node commentedon Nov 14, 2025
Yeah I think keeping both behaviors makes sense, I think there are some environments that the auth json would be better for (could be wrong would have to read the bun secrets stuff for to be sure)
I do think a flag is good but it also seems like a setting someone would always want on so maybe an option in their opencode config or something would be good too
bogorad commentedon Nov 14, 2025
Personally, I built this tiny win11-utility that translates calls to
/run/secretstosops decryptthat uses a key derived from my ssh key for decryption, so I can use{file:/run/secrets/api_keys/whatever}both for linux and windows :)https://github.com/bogorad/win-secrets
monostop commentedon Nov 17, 2025
I hit a few teething issues with Bun.secrets in my initial attempt (details here: oven-sh/bun#24711). I’ll take a closer look later this week. I do have a workaround using @napi-rs/keyring, but using Bun natively would make far more sense if I can get it working.
monostop commentedon Dec 1, 2025
The Bun maintainers have fixed the issue and it now the implementation with Bun.secrets works in the bun canary release. I'll continue with the development and create the PR when the fix is in the bun repo is officially released.
rekram1-node commentedon Dec 2, 2025
nice!
Brooooooklyn commentedon Feb 20, 2026
Can use https://github.com/Brooooooklyn/keyring-node
github-actions commentedon Apr 22, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.
theRoboxx commentedon Jun 25, 2026
I think this would be an essential enhancement to the tool. Any updates on it?
tkoop commentedon Sep 26, 2026
This is a good idea. We should do this. I would up-vote this if I could.