MCP startup UI stays at `0/5 connected` even though all servers are connected and usable

Summary

On Linux Mint 22.3, Kimi CLI startup UI keeps showing:

• MCP Servers: 0/5 connected, 0 tools
• connecting to mcp servers...

But the MCP servers are actually connected successfully, handshake completes, and tool calls work.

Environment

• Kimi CLI: 1.43.0
• OS: Linux Mint 22.3
• Working directory: /data/codeRepository/desmart/git/mdmNew
• Custom local MCP servers over stdio

What happens

At startup, the terminal UI remains in a connecting state and still displays 0/5 connected, but backend logs show all MCP servers connected normally.

Evidence

1. Kimi CLI backend log shows all 5 MCP servers connected

From ~/.kimi/logs/kimi.log for session 24fa57d2-37ef-4ea6-8371-307a5a1d0ee9:

• Connected MCP server: mdm-file-parser
• Connected MCP server: mdm-git
• Connected MCP server: mdm-mysql-metadata
• Connected MCP server: mdm-fetch
• Connected MCP server: mdm-code-intelligence

2. MCP protocol trace shows successful handshake

For all 5 servers, the following sequence completes successfully:

• initialize
• notifications/initialized
• tools/list

3. Real tool calls succeed

Using the same ~/.kimi/mcp.json config that Kimi CLI reads:

• mdm-git.branch_list returns branch data successfully
• mdm-code-intelligence.get_mcp_health returns loading first and then ready

Example final health result from mdm-code-intelligence:

{"status":"ready","index_ready":true,"build_in_progress":false,"total_nodes":35725}

Expected behavior

After MCP servers are connected, the startup UI should reflect the actual status instead of staying at 0/5 connected / connecting to mcp servers....

Actual behavior

The UI appears stuck in the connecting state, even though the logs and real tool calls show MCP is already working.

Notes

I have already ruled out local MCP server issues on my side:

• all servers complete stdio MCP handshake
• tools/list succeeds
• tool calls succeed
• startup stderr noise has been removed
• server launch config is direct script execution (not a bootstrap wrapper)

So this looks more like a Kimi CLI UI/state refresh issue than an MCP server connection failure.

If helpful, I can also provide a minimal reproduction trace of the MCP request/response sequence.

Reproduce the startup using the ~/.kimi/mcp.json configuration and compare the UI with ~/.kimi/logs/kimi.log, where the five successful connections are recorded. Trace how MCP handshake and tools/list results update the startup connection count and status, then verify that the UI reaches the connected state while real tool calls still succeed.