MoonshotAI / MoonshotAI/kimi-code

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

Open
#1,447 0 comments 0 reactions 0 assignees View on GitHub

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_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!

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.