Feature request: env-var / credential-helper support for provider api_key (avoid plaintext keys in config.toml)

[xin-guo]

Problem

The provider api_key currently has to be a literal value in config.toml — there appears to be no environment-variable or credential-helper indirection for provider keys.

What I verified (on 0.14.2, by inspecting the bundled dist/*.mjs):

• No MOONSHOT_API_KEY / KIMI_API_KEY / generic *_API_KEY environment reads for the provider key — the only process.env.* reads are infra-related (proxy settings, KIMI_SHELL_PATH, KIMI_CRON_CLOCK, test flags).
• No ${...} interpolation / env expansion in the config loader.
• api_key is consumed as a literal config field, and the README documents no env override.

As of 0.23.0 the README still doesn't document one — apologies if a newer mechanism exists that I missed.

Request

Any one of these would solve it (in rough order of simplicity):

1. Environment variable for the provider key (e.g. MOONSHOT_API_KEY, or a per-provider form), taking precedence over the config literal.
2. ${VAR} interpolation in config.toml values.
3. Credential-helper field (e.g. api_key_command = "...") that runs a command and uses its stdout — this composes with macOS Keychain (security find-generic-password), 1Password (op read), pass, etc.

Motivation

• Keeps long-lived API keys out of plaintext on disk (the config file is otherwise a great place for tunables, and mixing secrets into it forces tight file-permission discipline onto users).
• On multi-agent developer machines, config.toml gets read by assorted tooling; a key indirection cleanly separates "settings tooling may read" from "secrets it must not".
• Parity with the common CLI pattern — most provider CLIs support at least the env-var form.

Current workaround

chmod 600 ~/.kimi-code/config.toml — works, but the key is still plaintext at rest.

Thanks for kimi-code!