Problem
For local / OpenAI-compatible embedding providers, headless runtimes may not inherit shell startup env such as ~/.zshrc.
This makes a setup work in an interactive shell but fail from agents, cron, launchd, or service contexts.
Concrete setup:
{
"embedding_model": "ollama:Qwen3-Embedding-4B-4bit-DWQ",
"embedding_dimensions": 1536,
"provider_base_urls": {
"ollama": "http://localhost:8000/v1"
},
"embedding_api_key": "..."
}
The local OpenAI-compatible endpoint requires an API key. ~/.gbrain/config.json contains embedding_api_key, but current buildGatewayConfig() only passes env: { ...process.env } into the AI gateway. It does not inject the file-plane embedding_api_key into the provider env (OLLAMA_API_KEY, etc.).
Result from a non-login runtime:
[embed(ollama:Qwen3-Embedding-4B-4bit-DWQ)] Invalid API key
The same endpoint works if OLLAMA_API_KEY is manually exported in the process env.
Expected
If a user stores an embedding provider key in gbrain config, gbrain should be able to use it in non-interactive / headless contexts.
Suggested behavior:
- Keep env vars highest priority.
- If env var is missing, use a file-plane config key such as
embedding_api_key or provider-scoped keys.
- For provider-scoped keys, something like:
{
"provider_api_keys": {
"ollama": "...",
"litellm": "..."
}
}
or preserve current simple field:
{
"embedding_api_key": "..."
}
Local workaround tested
A small local patch in src/cli.ts fixed the issue for an ollama:* embedding model:
const env = { ...process.env };
if (c.embedding_api_key && c.embedding_model?.startsWith('ollama:') && !env.OLLAMA_API_KEY) {
env.OLLAMA_API_KEY = c.embedding_api_key;
}
After this, gbrain put from the agent runtime succeeds and embeddings are written normally.
Why this matters
This makes local embedding setups much easier to run reliably under OpenClaw / cron / launchd / background agents, where shell profile env is often absent.
Problem
For local / OpenAI-compatible embedding providers, headless runtimes may not inherit shell startup env such as
~/.zshrc.This makes a setup work in an interactive shell but fail from agents, cron, launchd, or service contexts.
Concrete setup:
{ "embedding_model": "ollama:Qwen3-Embedding-4B-4bit-DWQ", "embedding_dimensions": 1536, "provider_base_urls": { "ollama": "http://localhost:8000/v1" }, "embedding_api_key": "..." }The local OpenAI-compatible endpoint requires an API key.
~/.gbrain/config.jsoncontainsembedding_api_key, but currentbuildGatewayConfig()only passesenv: { ...process.env }into the AI gateway. It does not inject the file-planeembedding_api_keyinto the provider env (OLLAMA_API_KEY, etc.).Result from a non-login runtime:
The same endpoint works if
OLLAMA_API_KEYis manually exported in the process env.Expected
If a user stores an embedding provider key in gbrain config, gbrain should be able to use it in non-interactive / headless contexts.
Suggested behavior:
embedding_api_keyor provider-scoped keys.{ "provider_api_keys": { "ollama": "...", "litellm": "..." } }or preserve current simple field:
{ "embedding_api_key": "..." }Local workaround tested
A small local patch in
src/cli.tsfixed the issue for anollama:*embedding model:After this,
gbrain putfrom the agent runtime succeeds and embeddings are written normally.Why this matters
This makes local embedding setups much easier to run reliably under OpenClaw / cron / launchd / background agents, where shell profile env is often absent.