Dashboard defaults to keychain in containers; silent failure leaves models configured but unusable

Summary

When Abbenay runs as a container (e.g. APME/OpenShift sidecar image ghcr.io/redhat-developer/abbenay:v2026.8.7), the web dashboard defaults API key storage to Keychain. Keytar is unavailable in the container, the /api/secrets POST fails, and the dashboard swallows the error, still saving provider + enabled models to config.yaml. The Models tab then shows “No models enabled” even though models are present in config, because the provider is configured: false (no resolvable API key).

File secret store (secretStore: "file" → secrets.json on the config volume) works when called explicitly via the API, but the dashboard never offers or defaults to it.

Environment

• Image: ghcr.io/redhat-developer/abbenay:v2026.8.7
• Deploy: OpenShift sidecar via APME operator (XDG_CONFIG_HOME=/etc/abbenay-config, writable PVC for config)
• Dashboard accessed via oc port-forward to 127.0.0.1:8787
• Keychain log on startup: keytar not available: ... Keychain storage disabled.

Steps to reproduce

1. Run Abbenay in a container with a writable config dir (no OS keychain / no working keytar).
2. Open the web dashboard → Add Provider.
3. Leave API Key Source as the default Keychain, enter an API key, discover models, move a model to Enabled, Save.
4. Open the Models tab / general status.

Expected

• Container-friendly default (File and/or Env), or
• Clear error that Keychain storage failed and the key was not saved.
• Models that were enabled should appear as usable once the key is stored successfully.

Actual

1. Startup: keychain disabled (keytar missing / no D-Bus session — documented in docs/CONTAINER.md).
2. Save: [Web] /api/secrets POST error: Keychain storage not available
3. Dashboard continues and writes provider config with models, e.g.:

providers:
  openai:
    engine: openai
    api_key_keychain_name: OPENAI_API_KEY
    base_url: https://...
    models:
      some-model: {}

4. /api/providers → configured: false; /api/models → []; UI: “No models enabled.”
5. /api/secrets shows OPENAI_API_KEY with hasValue: false.

Workaround

Explicitly use the file store (works on this image when the config volume is writable):

curl -X POST "http://127.0.0.1:8787/api/secrets/OPENAI_API_KEY" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"value":"...","secretStore":"file"}'

curl -X POST "http://127.0.0.1:8787/api/provider/openai/configure" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"secretName":"OPENAI_API_KEY","secretStore":"file"}'

Env (api_key_env_var_name + injected env) also works per container docs; the dashboard Env path only helps if the env var is actually set on the container.

Why this is surprising

• docs/CONTAINER.md already states keychain does not work in containers and recommends env.
• File store exists (APME docs: Abbenay ≥ v2026.8.6) and persists on the same config volume as config.yaml.
• The dashboard still defaults to Keychain, has no File option, and hides the failure (catch {} around the secrets POST in packages/daemon/static/index.html).

Suggested fixes (Abbenay)

1. Dashboard: add a File API key source (and/or default to File/Env when keychain is unavailable).
2. Do not swallow /api/secrets failures on Save — surface an error and abort provider save if the key was required.
3. API: consider refusing or warning when defaulting omitted secretStore to keychain if keychain is disabled at runtime.
4. Optional: when keytar fails to load, prefer file as the writable default backend in container-like environments.

Related

• Container docs: no keytar / use api_key_env_var_name — docs/CONTAINER.md
• File store used successfully in-cluster writes <configDir>/secrets.json (mode 0600)

Start with the save flow and the catch {} around the secrets POST in packages/daemon/static/index.html, then read docs/CONTAINER.md and trace /api/secrets plus /api/provider/openai/configure. Done means the dashboard offers a container-usable secret path or clearly reports a failed key save, and enabled models remain usable after saving.