No supported way to give the autopilot daemon a provider key without writing it to disk

Summary

There is no supported way to give the autopilot daemon a provider key without writing that key to disk.

The runtime resolves keys from the process environment (process.env.VOYAGE_API_KEY in the gateway) or from the file plane (gbrain config set voyage_api_key …, which lands in config.json). The generated daemon wrapper sources the shell profiles and $GBRAIN_HOME/env, and --install prints that as the recommended place to put the key. Every one of those is a secret at rest in a plaintext file.

For hosts whose policy is that secrets live only in a manager (Doppler, 1Password, Vault, pass, the macOS keychain) and are injected per process, the only way to run the official daemon today is to wrap the baked CLI path in a launcher of one's own that shells out to the manager — which is exactly the kind of local mechanism the rest of gbrain's design avoids.

What would close it

A command-based credential source that the daemon resolves at start, for example:

• gbrain config set voyage_api_key_command "doppler secrets get VOYAGE_API_KEY --plain", or
• an auth_env_command block in config, or
• VOYAGE_API_KEY_CMD as an env-level convention,

with the same shape for every provider the gateway knows, resolved once per process start, never persisted, and redacted in diagnostics the way the existing key handling already is.

That keeps the wrapper and the plist untouched, works identically for launchd, systemd, cron and container targets, and lets a secret-manager host run the official daemon with no bespoke launcher.

Context

Filed alongside the brain-scoped job-name gap (the two meet when a host runs a second brain: it needs both a second job and a second set of credentials). Happy to test a patch — we run a Doppler-only policy on macOS with two brains.