anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 10:15:31 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

[FEATURE]: Allow storage of secrets in system credential store. #2853

New Issue
Open
opened 2026-02-16 17:37:32 -05:00 by yindo · 7 comments
yindo commented 2026-02-16 17:37:32 -05:00
Owner
Copy Link
Copy Source

Originally created by @monostop on GitHub (Nov 14, 2025).

Originally assigned to: @monostop on GitHub.

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)

Originally created by @monostop on GitHub (Nov 14, 2025). Originally assigned to: @monostop on GitHub. ### Feature hasn't been suggested before. - [x] 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)
yindo added the discussion label 2026-02-16 17:37:32 -05:00
yindo commented 2026-02-16 17:37:32 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Nov 14, 2025):

Yeah I think using Bun secrets would be rlly good

@rekram1-node commented on GitHub (Nov 14, 2025): Yeah I think using Bun secrets would be rlly good
yindo commented 2026-02-16 17:37:32 -05:00
Author
Owner
Copy Link
Copy Source

@monostop commented on GitHub (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?

@monostop commented on GitHub (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?
yindo commented 2026-02-16 17:37:32 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (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

@rekram1-node commented on GitHub (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
yindo commented 2026-02-16 17:37:32 -05:00
Author
Owner
Copy Link
Copy Source

@bogorad commented on GitHub (Nov 14, 2025):

Personally, I built this tiny win11-utility that translates calls to /run/secrets to sops decrypt that 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

@bogorad commented on GitHub (Nov 14, 2025): Personally, I built this tiny win11-utility that translates calls to `/run/secrets` to `sops decrypt` that 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
yindo commented 2026-02-16 17:37:32 -05:00
Author
Owner
Copy Link
Copy Source

@monostop commented on GitHub (Nov 16, 2025):

I hit a few teething issues with Bun.secrets in my initial attempt (details here: https://github.com/oven-sh/bun/issues/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 commented on GitHub (Nov 16, 2025): I hit a few teething issues with Bun.secrets in my initial attempt (details here: https://github.com/oven-sh/bun/issues/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.
yindo commented 2026-02-16 17:37:32 -05:00
Author
Owner
Copy Link
Copy Source

@monostop commented on GitHub (Nov 30, 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.

@monostop commented on GitHub (Nov 30, 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.
yindo commented 2026-02-16 17:37:32 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Dec 2, 2025):

nice!

@rekram1-node commented on GitHub (Dec 2, 2025): nice!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label discussion
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#2853
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?