/reload can resume before MCP tools are ready, leaving the first turn with an incomplete tool list

Summary

/reload can report success and resume the current session before initial MCP loading has completed. A prompt submitted immediately after the command may therefore be sent to the model with only built-in tools and none of the configured MCP tools.

This is a readiness race in the reload lifecycle, not an MCP server failure and not merely a prompting problem: the missing tool was absent from the actual request tool schema.

Environment

• Kimi Code CLI: 0.39.1
• Platform: Linux x86_64
• MCP transport: streamable HTTP
• Also inspected current upstream main at 0fd89695f5b6427fab53c5284e9eee4360ef15b8; the same asynchronous initialization pattern is still present

The issue occurs before model execution, so it should not depend on the selected model or subscription.

Observed behavior

Before /reload, the configured MCP server was connected and its tools were available.

After /reload:

1. A fresh SessionStart reminder was added to the resumed conversation.
2. The first outgoing model request contained only built-in tools and zero tools from the configured MCP server.
3. A following request still contained zero tools from that MCP server.
4. The model could not call the requested MCP tool because it did not exist in the supplied schema. It selected an unrelated built-in tool and subsequently produced unsupported state claims.
5. A full Kimi process restart restored the MCP tools in the first outgoing request.

No MCP server name, tool name, URL, or private request data is required to reproduce the lifecycle race.

Source-level cause

The reload path performs a full session runtime teardown and reconstruction:

• The TUI command awaits reloadSession(): https://github.com/MoonshotAI/kimi-code/blob/0fd89695f5b6427fab53c5284e9eee4360ef15b8/apps/kimi-code/src/tui/commands/reload.ts#L16-L24
• reloadSession() calls closeForReload(), removes the active session, and resumes it: https://github.com/MoonshotAI/kimi-code/blob/0fd89695f5b6427fab53c5284e9eee4360ef15b8/packages/agent-core/src/rpc/core-impl.ts#L681-L706
• closeForReload() shuts down all MCP connections: https://github.com/MoonshotAI/kimi-code/blob/0fd89695f5b6427fab53c5284e9eee4360ef15b8/packages/agent-core/src/session/index.ts#L579-L590
• The reconstructed Session starts MCP loading as fire-and-forget work via void this.loadMcpServers(): https://github.com/MoonshotAI/kimi-code/blob/0fd89695f5b6427fab53c5284e9eee4360ef15b8/packages/agent-core/src/session/index.ts#L354-L356

Unlike skill loading, MCP loading has no readiness promise awaited by session resume or by the /reload command. Consequently, the command can reload the view and accept the next prompt while MCP discovery is still pending.

Reproduction

1. Configure a streamable-HTTP MCP server that exposes at least one uniquely named read-only tool.
2. Start Kimi Code and verify that the server is connected and the tool is included in outgoing model requests.
3. Run /reload.
4. Immediately submit a prompt that requires the unique MCP tool.
5. Inspect the first post-reload request tool schema or the session wire.

The race is easier to observe when MCP initialization takes a non-zero amount of time.

Expected behavior

/reload should not report completion or accept the first resumed turn until initial MCP loading has reached a settled state for every configured server (connected, needs-auth, disabled, or a surfaced failure).

Possible approaches:

• Track an MCP readiness promise similarly to skillsReady and await it during resume/reload.
• Or gate the first post-reload turn until initial MCP discovery settles.

If an MCP server cannot initialize, the reload should surface that failure explicitly rather than silently proceeding with an incomplete tool schema.

Relation to #2742 and #2748

#2742 reports dropped streamable-HTTP sessions, disappearing tools, and unrelated tool selection. #2748 adds call-driven reconnect behavior for dropped sessions.

This report covers a different boundary: initial MCP readiness after an explicit /reload. Even with reconnect support, reloadSession() can currently return while loadMcpServers() is still running, so the first resumed request can still have an incomplete tool list.

Start with apps/kimi-code/src/tui/commands/reload.ts and packages/agent-core/src/rpc/core-impl.ts, then trace closeForReload() and the Session constructor in packages/agent-core/src/session/index.ts. Reproduce /reload with a streamable-HTTP MCP server whose initialization takes time, and inspect the first post-reload request. Done means reload does not complete or accept the resumed turn until every configured server reaches a settled state, with failures surfaced.