MoonshotAI / MoonshotAI/kimi-code
Feature request: env-var / credential-helper support for provider api_key (avoid plaintext keys in config.toml)
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 7.5k
- Forks
- 1.2k
- Avg merge
- 11h 53m
- Merged PRs (30d)
- 350
Description
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_KEYenvironment reads for the provider key — the onlyprocess.env.*reads are infra-related (proxy settings,KIMI_SHELL_PATH,KIMI_CRON_CLOCK, test flags). - No
${...}interpolation / env expansion in the config loader. api_keyis 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):
- Environment variable for the provider key (e.g.
MOONSHOT_API_KEY, or a per-provider form), taking precedence over the config literal. ${VAR}interpolation inconfig.tomlvalues.- 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.tomlgets 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!
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing the config loader and the provider api_key consumption described in the bundled dist/*.mjs, then review the current README and its documented config.toml behavior. Compare the requested environment-variable, interpolation, and credential-helper approaches, including precedence over literal values; done means one supported mechanism is defined, implemented, and documented without plaintext keys being required.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- cli, security
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100