Feature request: environment-variable support in MCP HTTP headers (Codex-style env_http_headers)

Problem

MCP HTTP/SSE server headers in mcp.json only accept static strings. The only environment-variable-aware field is bearerTokenEnvVar, which covers authentication tokens only.

This makes it impossible to inject per-process identity headers into MCP requests when multiple agent processes on the same machine share the same user-level ~/.kimi-code/mcp.json.

Use case

We run multiple named agent workers on one machine via an orchestrator (Raft). Each worker process gets its own identity via an environment variable (e.g. NMEM_AGENT_ID=octopus), and the MCP server (Nowledge Mem) resolves the session identity from the X-Nmem-Agent-Id request header.

Codex solves this with:

[mcp_servers.nowledge-mem]
env_http_headers = { "X-Nmem-Agent-Id" = "NMEM_AGENT_ID" }

With Kimi Code there is currently no equivalent: the env var reaches the worker process (verified — Bash tool calls inside the session see it), but it can never be forwarded into MCP request headers, so all workers share one anonymous identity.

What we tried (verified workarounds that don't work)

1. Project-level .kimi-code/mcp.json with a static identity header per workspace: in headless mode (kimi -p), a project-level mcp.json in an untrusted folder causes all MCP servers (including user-level ones) to be disabled, and the workspace-trust prompt cannot be answered non-interactively. So per-workspace static headers are not usable for unattended agents either.
2. bearerTokenEnvVar: only maps to Authorization: Bearer ..., not arbitrary headers.

Request

Either of:

1. Allow environment variable interpolation in header values, e.g. "X-Nmem-Agent-Id": "${NMEM_AGENT_ID}", or
2. Add an envHeaders field mapping header names to env var names (Codex-style):

{
  "mcpServers": {
    "nowledge-mem": {
      "url": "http://127.0.0.1:14242/mcp/",
      "envHeaders": { "X-Nmem-Agent-Id": "NMEM_AGENT_ID" }
    }
  }
}

And ideally: a way to pre-trust project-level MCP servers for headless/unattended runs (e.g. a trusted-folders list in config.toml), so per-project mcp.json works without an interactive prompt.

Environment

• kimi-code 0.39.1, Linux x64
• Verified: the MCP server honors the identity header when set (curl direct), and Kimi Code's Bash tool inherits the env var — the gap is strictly in MCP header forwarding.

Start by locating the mcp.json configuration handling and the existing bearerTokenEnvVar path, then trace how configured headers reach MCP HTTP/SSE requests. The issue describes two possible header designs plus project trust for headless runs, so clarify the intended scope and finish by verifying environment-derived headers work for unattended processes.