Use local environment variables rather than hub or secrets?

[mmynsted]

When I look in the documentation here -> https://docs.continue.dev/reference#config-yaml-reference
I see:

Local blocks utilizing mustache notation for secrets (${{ secrets.SECRET_NAME }}) can read secret values:

    globally, from a .env located in the global .continue folder (~/.continue/.env)
    per-workspace, from a .env file located at the root of the current workspace.

I have created a secret named OPENROUTER_KEY. I added it to ~/.continue/.env and then also to my local working directory's .env. It is never read.

I have attempted both

${{ secrets.OPENEROUTER_KEY }}

and

${{ inputs.OPENEROUTER_KEY }}

Here is an example from the documentation that is close to my config.yaml

name: myprofile/custom-model
models:
  - name: My Favorite Model
    provider: anthropic
    apiKey: ${{ inputs.ANTHROPIC_API_KEY }}
    defaultCompletionOptions:
      temperature: ${{ inputs.TEMP }}

I have also added OPENROUTER_KEY to the env directly using an Age - SOPS pipeline. I can see the variable when echo, but it does not get loaded to my ~/.continue/config.yaml.

My goal is to use environment variables for the keys using my Age - SOPS pipleline so that I have one mechanism for all AI tools using they same keys. I do not want to store the keys in the secrets or hub SaaS. What am I doing wrong? Maybe there is another way to debug this? I have messages showing in the developer console which does throw errors consistent with the OPENROUTER_KEY never being found/read.

I have reloaded the config many times. I have recycled VSCODE a number of times. My VSCODE and continue are the latest available.

[bdougie]

@mmynsted looking at your example. You need to add the model as well. Everything else should work as is.

name: myprofile/custom-model
models:
  - name: My Favorite Model
    provider: anthropic
    model: claude-sonnet-4-20250514 # this was missing in your example
    apiKey: ${{ inputs.ANTHROPIC_API_KEY }}
    defaultCompletionOptions:
      temperature: ${{ inputs.TEMP }}

Let me know if you are seeing these error messages below the extension (Assuming you are on VS Code)

Also put together a FAQ in this PR around it - #7209

[mmynsted]

Thank you it is working now. It was a scope issue.

When I decrypt the keys and store them in the shell globally, at shell start, then they are available to VS Code and so to continue.dev, because continue.dev finds them in the process's environment. To do what I was wanting, decrypt the values, just-in-time for Continue.dev I would need to modify (contribute) to the way continue.dev finds secrets and inputs on load. If I am correctly reading how this works. . .

I did not test more for why the ~/.continue/.env was not working for me, but I do not plan to use it that way anyway, until I sort out automated decryption with SOPS for continue.dev. (Which is what I think will require changes to how continue.dev finds and reads secrets.)

[boly38]

hi @bdougie

I was searching how to deal with MCP definition having secrets in request header.
I found usefull ticket #7595 describing the way to setup request header. I regret that requestOptions was not fully added to end-user documentation (or I just miss it).

I manage with success to deal with an header that rely on ${{ secrets.MY_TOKEN }}

• I add MY_TOKEN definition in "Continue Mission Control" ( cloud account settings: https://www.continue.dev/settings/secrets )
• I need to sign in and that's ok

But do you know if ${{ input.MY_TOKEN }} is supported for a mcp server configuration

I would like to share MCP config with my team and rely in local custom ".continue/.env" file instead of (cloud-dependent) secrets ? (so without relying on the cloud secrets)

Thanks 🙏

context + MCP definition example

Context: - IntelliJ Ultimate 2025.3.3 | Continue-dev 1.0.50 | Ubuntu 24.04
.continue/mcpServers/team_mcp_server.yaml

name: New MCP server
version: 0.0.1
schema: v1
mcpServers:
  - name: Browser search
    command: npx
    args:
      - "@playwright/mcp@latest"
  - name: IntelliJ
    type: sse
    url: http://localhost:64342/sse
  - name: Local MCP server
    type: streamable-http
    url: http://localhost:9000/mcp
    # https://github.com/continuedev/continue/issues/7595
    requestOptions:
      headers:
        # +secrets well defined |  OK
        X-API-KEY: ${{ secrets.MCP_LOCAL_API_KEY }}
        # +.continue/.env | Failed
        # X-API-KEY: ${{ input.MCP_LOCAL_API_KEY }}

[AreYouLoco]

Is there still now way for local ENV VARS?

[mmynsted]

On macOS, the solution I am using for local configuration and secrets is to get them injected by the OS for GUI apps. It is a bit heavy-handed but works for secrets. @AreYouLoco, I have not made an effort to handle regular ENV VARS. I just use OpenRouter presets, to do what I would have used ENV VARS for, but you could simplify the following for non-secret VARS.

I will describe secrets detail here in case it is of use to anybody. (I do not know if this is documented anywhere.) I do this for several variables. I will show it for one. If your ENV variables are not secrets, you can simplify how you obtain the VARS in your set-continue-env.sh.

GOAL: Provide secrets to Continue.dev local configuration, config.yaml using placeholders, like secrets.OPENROUTER_API_KEY, so that the configuration file its self never contains secrets. This works for macOS users.

---

1 Add secrets to macOS Keychain (login) and verify.

# Replace placeholders with your real keys
security add-generic-password -a openrouter -s OPENROUTER_API_KEY \
  -w 'sk-or-xxxxxxxx' -U ~/Library/Keychains/login.keychain-db

# Verify retrievable from login.keychain-db
security find-generic-password -s OPENROUTER_API_KEY   -w ~/Library/Keychains/login.keychain-db

# Ensure login keychain is in the user search list
security list-keychains -d user -s ~/Library/Keychains/login.keychain-db

2 Make a small script to export the ENV from Keychain

set-continue-env.sh

#!/usr/bin/env bash
set -euo pipefail
OR=$(/usr/bin/security find-generic-password -s OPENROUTER_API_KEY   \
  -w ~/Library/Keychains/login.keychain-db 2>/dev/null || true)

[ -n "${OR:-}" ] && /bin/launchctl setenv OPENROUTER_API_KEY "$OR"

Make sure to set it executable.

chmod +x ~/bin/set-continue-env.sh

3 Install a LaunchAgent to set ENV at login and validate

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>Label</key><string>local.continue.setenv</string>
    <key>ProgramArguments</key>
    <array>
      <string>/bin/sh</string>
      <string>-lc</string>
      <string>~/bin/set-continue-env.sh</string>
    </array>
    <key>RunAtLoad</key><true/>
    <key>StandardOutPath</key><string>/tmp/local.continue.setenv.log</string>
    <key>StandardErrorPath</key><string>/tmp/local.continue.setenv.err.log</string>
  </dict>
</plist>

# Reload and validate
launchctl unload ~/Library/LaunchAgents/local.continue.setenv.plist 2>/dev/null || true
launchctl load -w ~/Library/LaunchAgents/local.continue.setenv.plist

# Expect print non-empty
launchctl getenv OPENROUTER_API_KEY   || echo "unset"

4 Verify inside VSCodium with a Task (Optional)

The for loop is in case you have multiple keys to test.

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "Print Continue API keys",
      "type": "shell",
      "command": "for v in OPENROUTER_API_KEY; do printf \"%s=\" \"$v\"; printenv \"$v\" | sed -E 's/.(?=.{4})/*/g' || echo unset; done",
      "problemMatcher": []
    }
  ]
}

A) Developer: Reload Window.

B) Terminal → Run Task → “Print Continue API keys”.

You should see masked values.

5 Update Continue config to use ENV

I have a keys section at the top of my config.yaml like the following.

keys:
  openrouter_key: &openrouter_key ${{ secrets.OPENROUTER_API_KEY }}

Then every place I need the key, I just refer to it.

    apiKey: *openrouter_key