providers.json API key from env_var not resolved unless keyring is set

[hugosenari]

Describe the bug

When defining a custom provider in providers.json with an env_var for the API key, vix fails to resolve the key from that environment variable unless the keyring value is set (with with random stuff).

To reproduce

1. Create a ~/.vix/providers.json (or ./.vix/providers.json) registering a custom provider with an env_var:

   {
      "credential_methods": [
        {
          "env_var": "GEMINI___API_KEY",
          "keyring": "opencode-api-key", # fails without it but get info from env_var
          "kind": "api_key"
        }
      ],
      "display_name": "Google",
      "id": "google",
      "inference": {
        "auth_header": "x-goog-api-key",
        "auth_scheme": "x-api-key",
        "base_url": "https://generativelanguage.googleapis.com/v1beta/interactions"
      },
      "model_prefix": "google",
      "models": [
        {
          "context_window": 200000,
          "display_name": "Gemini3",
          "spec": "google/gemini-3.5-flash"
        }
      ],
      "wire_format": "chat_completions"
    },
   

2. Set export MY_CUSTOM_API_KEY=sk-... in your shell — no .env, no keychain entry.
3. Run vix, select the model myprovider/my-model.
4. Observe that vix reports no credential for myprovider or fails at request time with an auth error.

Expected behavior

Per the credential resolution order, environment variables should take highest priority and be resolved regardless of whether the OS keychain is available or configured. A custom provider's env_var should work identically to the built-in providers' env vars (e.g. ANTHROPIC_API_KEY, OPENAI_API_KEY).

Actual behavior

The env var is only consulted when the keychain is reachable and/or contains at least one entry for that provider. On systems without a usable keychain (e.g. headless servers, containers, WSL without gnome-keyring), the env var is silently ignored and the credential is reported as missing.

Environment

• OS: (any headless/container/WSL setup without a functioning keyring daemon)
• Vix version: (please fill in)
• Keychain availability: none / unreachable

Additional context

The built-in providers (Anthropic, OpenAI, etc.) resolve their env vars (ANTHROPIC_API_KEY, OPENAI_API_KEY) independently of the keychain, which works fine. The bug seems specific to custom providers defined via providers.json — the credential resolution logic for custom env_var fields may be gated on a prior keychain lookup.

[kirby88]

Thank you for reporting, this will be fixed in the next version v0.5.6. Keeping the issue open in the meantime to keep track.

[hugosenari]

I'm not sure if is but when adding new provider (LLMGateway), using anthropic/haiku, vix, returns a error that no ANTROPIC_API_KEY is set even, setting env_key in proviter as LLMGTWAY_API_KEY

[kirby88]

@hugosenari This one is actually a separate thing from the bug this issue tracks, and it's a configuration/routing detail rather than a bug.

vix picks the provider for a model purely from the model spec's prefix, not from which provider you added. So a model named anthropic/haiku always routes to the built-in Anthropic provider (whose credential is ANTHROPIC_API_KEY), your custom LLMGateway provider and its LLMGTWAY_API_KEY are never consulted, because the spec doesn't start with that provider's model_prefix.

To route through your gateway, give it a unique model_prefix and reference the model by it:

{
  "id": "llmgateway",
  "display_name": "LLM Gateway",
  "model_prefix": "llmgateway",
  "wire_format": "chat_completions",
  "inference": { "base_url": "https://your-gateway/v1" },
  "credential_methods": [
    { "kind": "api_key", "env_var": "LLMGTWAY_API_KEY" }
  ],
  "models": [
    { "spec": "llmgateway/haiku", "display_name": "Haiku (via gateway)" }
  ]
}

Then select llmgateway/haiku (not anthropic/haiku) and it'll use LLMGTWAY_API_KEY.

Note you can't reuse anthropic as your gateway's model_prefix, vix rejects duplicate prefixes at load with a model_prefix ... collides between providers error.

If switching to a distinct prefix fixes it for you, this is working as intended. The original bug in this issue (env var ignored unless a keyring value is set) is a different problem and is already fixed for the next release.