## 问题：MCP 子进程 stderr 日志泄漏到 TUI 界面（regression） || ## Problem: MCP subprocess stderr log leaks to TUI interface (regression)

What version of Kimi Code CLI is running?

1.43.0

Which open platform/subscription were you using?

/login

Which model were you using?

k2.6

What platform is your computer?

linux fedora 43 workstation

What issue are you seeing?

描述

今天更新 Kimi CLI 后，stdio 类型的 MCP 服务器子进程的 stderr 日志直接显示在 TU
I 界面上，严重干扰使用。此前没有这个问题。

从代码分析，Kimi CLI 有 StderrRedirector 机制（通过 dup2 把 fd=2 重定向到
pipe，再由后台线程写入日志文件），但该机制没有实际生效——子进程的 stderr 输出仍
然直接到达了终端/TUI。

环境

• Kimi CLI: 1.43.0 (2026-05-12 更新，包含 FastMCP 3.2.4 升级)
• OS: Linux
• MCP 工具: mcp-remote 0.1.38

复现

1. 配置任意 stdio MCP 服务器（如 mcp-remote）
2. 启动 Kimi CLI
3. 观察 TUI：子进程的 [PID] ... 格式日志直接刷屏

What steps can reproduce the bug?

复现

1. 配置任意 stdio MCP 服务器（如 mcp-remote）
2. 启动 Kimi CLI
3. 观察 TUI：子进程的 [PID] ... 格式日志直接刷屏

根因分析

Kimi CLI 在 cli/__init__.py 中调用 redirect_stderr_to_logger()，意图捕获 M
CP 子进程的 stderr。但 StderrRedirector._drain 读取 pipe 内容后调用 logger. log("ERROR", text)，而 enable_logging() 中 logger.add() 只配置了文件 sink
——理论上日志应该只进入文件，不应显示在 TUI 上。
实际却显示在界面上，说明 stderr 重定向链路存在漏洞。可能原因：

• FastMCP 3 升级后，stdio_client 创建子进程的方式变化，导致子进程没有继承被
  重定向的 fd=2
• 或 StderrRedirector 与 FastMCP 3 的 log_file=sys.stderr 默认行为冲突

What is the expected behavior?

期望

MCP 子进程的 stderr 输出应被静默捕获到日志文件，不在 TUI 界面上显示。

临时 workaround

用户目前只能通过 shell hack 尝试抑制，但在 Kimi CLI 内部无效：

"command": "sh",
"args": ["-c", "exec npx -y mcp-remote ... >/dev/null 2>&1"]

建议 Kimi CLI 在创建 StdioTransport 时显式传递 log_file 参数，将子进程 stderr
重定向到 /dev/null 或日志文件，而不是依赖全局的 StderrRedirector。

### Additional information

_No response_
<!--This is a translation content dividing line, the content below is generated by machine, please do not modify the content below-->
---
### What version of Kimi Code CLI is running?

1.43.0

### Which open platform/subscription were you using?

/login

### Which model were you using?

k2.6

### What platform is your computer?

linux fedora 43 workstation

### What issue are you seeing?

### Description
After updating Kimi CLI today, the stderr log of the stdio type MCP server subprocess is directly displayed in TU
On the I interface, it seriously interferes with use. There was no such problem before.

From code analysis, Kimi CLI has a `StderrRedirector` mechanism (redirecting fd=2 to
pipe, and then the background thread writes to the log file), but this mechanism does not actually take effect - the stderr output of the child process still
Then it went directly to the terminal/TUI.

### Environment
- Kimi CLI: 1.43.0 (updated on 2026-05-12, including FastMCP 3.2.4 upgrade)
- OS: Linux
- MCP tool: mcp-remote 0.1.38

### Recurrence
1. Configure any stdio MCP server (such as `mcp-remote`)
2. Start Kimi CLI
3. Observe the TUI: the `[PID]...` format log of the child process directly refreshes the screen.




### What steps can reproduce the bug?

### Recurrence
1. Configure any stdio MCP server (such as `mcp-remote`)
2. Start Kimi CLI
3. Observe the TUI: the `[PID]...` format log of the child process directly refreshes the screen.
### Root cause analysis
Kimi CLI calls `redirect_stderr_to_logger()` in `cli/__init__.py` with the intention of capturing M
CP The stderr of the child process. But `StderrRedirector._drain` calls `logger.
log("ERROR", text)`, and `logger.add()` in `enable_logging()` only configures the file sink
——**Theoretically the log should only go to the file and should not be displayed on the TUI**.
It is actually displayed on the interface, indicating that there is a vulnerability in the stderr redirection link. Possible reasons:
- After the FastMCP 3 upgrade, the way `stdio_client` creates a child process has changed, resulting in the child process not inheriting the
redirected fd=2
- or `StderrRedirector` conflicts with FastMCP 3's default behavior of `log_file=sys.stderr`

### What is the expected behavior?

### Expectations
The stderr output of the MCP child process should be silently captured to the log file and not displayed on the TUI interface.

### Temporary workaround
Users can currently only attempt suppression via a shell hack, which does not work inside the Kimi CLI:
```json
"command": "sh",
"args": ["-c", "exec npx -y mcp-remote ... >/dev/null 2>&1"]

It is recommended that Kimi CLI explicitly pass the log_file parameter when creating the StdioTransport to change the subprocess stderr
Redirect to /dev/null or a log file instead of relying on the global StderrRedirector.

### Additional information

_No response_

Start in cli/init.py with redirect_stderr_to_logger(), then trace StderrRedirector._drain and enable_logging() to determine why child stderr reaches the TUI. Inspect how stdio_client or StdioTransport creates the MCP subprocess after the FastMCP 3.2.4 upgrade. Reproduce with mcp-remote and verify that stderr is captured in the log file without appearing in the TUI.