Integration of roo code with sops for secret management

[lspecian]

What problem does this proposed feature solve?

Roo Code currently lacks a secure and scalable way to manage secrets like API keys and credentials for LLM providers (e.g. OpenAI, Claude, Mixtral, etc.). Most likely, environment variables or unencrypted config files are being used. This creates security risks, makes collaboration difficult, and doesn’t scale as users define more custom modes with different secrets.

A standardized and encrypted secrets management system is necessary to support secure, multi-profile configurations and improve enterprise readiness.

Describe the proposed solution in detail

Integrate SOPS into Roo Code as a native secret management option.

Users define secrets in encrypted .yaml, .json, or .env files.

Roo Code decrypts these at runtime using sops CLI or a helper process.

Support both project-specific and global config files.

Use .sops.yaml for encryption rules (e.g., PGP, age, AWS/GCP/Azure KMS).

Provide VSCode commands like:

Roo: Edit Secret File

Roo: Create Encrypted Secret

Roo: Initialize .sops.yaml

Secrets are decrypted in-memory only and tied to API configuration profiles or custom modes.

Technical considerations or implementation details (optional)

Use the sops CLI via Node.js child_process or create a small Go helper.

All secret files must be decrypted only when needed, never persisted in plaintext.

Optionally cache decrypted secrets in-memory with short TTLs.

Allow fallback to existing methods (env vars) for backwards compatibility.

Consider bundling the SOPS binary or guiding users through installation.

Describe alternatives considered (if any)

Env vars: not scalable, hard to share safely, no version control.

Cloud secret managers (AWS/GCP/Azure): good for runtime apps, not for Git-managed config.

HashiCorp Vault: overkill for most Roo users and not version control friendly.

SOPS offers the right balance between usability, security, and Git integration.

Additional Context & Mockups

This feature would improve collaboration in teams using custom Roo modes with separate API keys.
It would also align Roo Code with GitOps and DevSecOps best practices.
Encrypted files can safely be checked into Git, improving onboarding and reproducibility.

Roo Code could become the first LLM coding agent to ship with native encrypted secret handling out of the box.

Proposal Checklist

• I have searched existing Issues and Discussions to ensure this proposal is not a duplicate.
• This proposal is for a specific, actionable change intended for implementation (not a general idea).
• I understand that this proposal requires review and approval before any development work begins.

Are you interested in implementing this feature if approved?

• Yes, I would like to contribute to implementing this feature.

[mrubens]

For what it's worth we do store secret keys in VS Code's SecretStorage. It's not a perfect solution, but maybe we could restate the problem a little?

[lspecian]

I'm thinking here on a more generic secret storeage, but could be valid for the whole credentials storage

One of my concerns at the moment is about the mcp.json, it will often contain many credentials for different MCPs, also the sops files, are reasonably safe to commit to git with private projects and at the very least credentials can be shared and access to keys can managed if we use a cloud provider key like aws kms

[daniel-lxs]

The mcp_settings.json file now supports variable injection which might mitigate this issue a bit #3970.

[hannesrudolph]

@lspecian Thanks for your feature proposal. However, this proposal doesn't clearly identify the specific problem it's intended to solve. For a feature to be considered, it needs to address a genuine problem impacting Roo users or significantly enhance the overall user experience.

We typically avoid features that focus primarily on niche cases, best-practice refactoring, or theoretical improvements without clear, practical benefits. If you can demonstrate why the current implementation is problematic or insufficient, please clarify that clearly in your proposal.