Validations
Problem
Currently, when ${{ secrets.some_env_var }} is used in config.yaml, the Continue extension only checks:
- .continue/.env
- Workspace .env files
- User account secrets (via Continue’s API)
However, it does not check the system’s environment variables (process.env). This is problematic because:
- Security policies (e.g., corporate environments) may block external API calls to Continue’s secrets service.
- DevOps workflows often rely on OS-level env vars (e.g., CI/CD, Docker, VS Code tasks).
- Local development becomes harder when forced to duplicate vars in .env files.
Impact:
- Blocks enterprise adoption (IT policies forbid API secrets). (my case btw)
- Forces redundant configs (e.g., duplicating OPENAI_API_KEY in .env).
- Breaks standard 12-factor app practices (config via env vars).
Solution
Add fallback support for process.env when resolving ${{ secrets.var_name }}. For example:
- Check .env files (current behavior).
- Check account secrets (current behavior).
- New: Fall back to process.env if not found elsewhere or request failed.
This maintains backward compatibility while adding flexibility for secure/local workflows.
Workaround (for now):
Users must manually sync env vars to .env files or use config.ts with process.env hacks (which is brittle, and I am currently doing that).
Validations
Problem
Currently, when ${{ secrets.some_env_var }} is used in config.yaml, the Continue extension only checks:
However, it does not check the system’s environment variables (process.env). This is problematic because:
Impact:
Solution
Add fallback support for process.env when resolving ${{ secrets.var_name }}. For example:
This maintains backward compatibility while adding flexibility for secure/local workflows.
Workaround (for now):
Users must manually sync env vars to .env files or use config.ts with process.env hacks (which is brittle, and I am currently doing that).