MoonshotAI / MoonshotAI/kimi-code
MCP client 收到 -32600 Unknown session id 后不自动 reinitialize,重试仍原样重发旧 session id(Streamable HTTP,server 重启后)
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 7.5k
- Forks
- 1.2k
- Avg merge
- 11h 53m
- Merged PRs (30d)
- 350
Description
What version of Kimi Code is running?
0.30.0(0.29.x 同现)
Which open platform/subscription were you using?
Kimi Code(managed:kimi-code,OAuth 登录)
Which model were you using?
kimi-code/k3-256k
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What issue are you seeing?
Streamable HTTP 的 MCP server 重启后,server 端 session 失效,对后续每个请求返回 -32600 Unknown session id(错误文案即协议原文 "client should reinitialize")。kimi-code client 不发起新的 initialize 握手,而是把同一个已失效的 session id 原样重发——实测连续 6 个请求(JSON-RPC id 72–77,跨度约 21 分钟)全部携带同一失效 session id,无一自愈。此后所有 MCP 调用持续失败,直到用户手动 /mcp 重连。
0.29.0 changelog 的 "Reconnect a dropped MCP server connection automatically when one of its tools is called, and retry the call once" 只覆盖传输层掉线;本 case 中 TCP/HTTP 层始终正常——server 返回了结构化的 JSON-RPC 错误响应,是应用层 session 失效,不在现有重连逻辑的触发条件内。
session wire 日志原始帧(已裁剪无关字段并脱敏;session id 为 server 端已失效的随机 hex):
{"jsonrpc": "2.0", "id": 72, "error": {"code": -32600, "message": "Unknown session id '0fbc7f3f46a19394ee69ba83d4a726ab' for 'tools/call'; client should reinitialize"}}
{"jsonrpc": "2.0", "id": 73, "error": {"code": -32600, "message": "Unknown session id '0fbc7f3f46a19394ee69ba83d4a726ab' for 'tools/call'; client should reinitialize"}}
{"jsonrpc": "2.0", "id": 74, "error": {"code": -32600, "message": "Unknown session id '0fbc7f3f46a19394ee69ba83d4a726ab' for 'tools/call'; client should reinitialize"}}
{"jsonrpc": "2.0", "id": 75, "error": {"code": -32600, "message": "Unknown session id '0fbc7f3f46a19394ee69ba83d4a726ab' for 'tools/call'; client should reinitialize"}}
{"jsonrpc": "2.0", "id": 76, "error": {"code": -32600, "message": "Unknown session id '0fbc7f3f46a19394ee69ba83d4a726ab' for 'tools/call'; client should reinitialize"}}
{"jsonrpc": "2.0", "id": 77, "error": {"code": -32600, "message": "Unknown session id '0fbc7f3f46a19394ee69ba83d4a726ab' for 'tools/call'; client should reinitialize"}}
对应本地时间戳(epoch ms):1785336079817 → 1785337347072,跨度约 21 分钟。client 侧工具报错原文:
Tool "mcp__unreal-mcp__call_tool" failed: Streamable HTTP error: Error POSTing to endpoint: {
"jsonrpc": "2.0",
"id": 72,
"error":
{
"code": -32600,
"message": "Unknown session id '0fbc7f3f46a19394ee69ba83d4a726ab' for 'tools/call'; client should reinitialize"
}
}
What steps can reproduce the bug?
mcp.json配置一个 HTTP(Streamable HTTP)MCP server(本例:Unreal Engine 5.8 编辑器内置的 Epic MCP server,http://127.0.0.1:8001/mcp;任何会随进程重启而清空 session 的 Streamable HTTP server 均应可复现)。- 正常调用若干工具——此时 client 持有 server 下发的 session id。
- 重启 server 进程(server 端 session 全部失效)。
- 再调用任意工具 → 必现
-32600,且重试不重新 initialize。
session id:da55c814-2250-4791-9e77-ffcefa3b8942(事发会话;context usage 当时未记录)。
What is the expected behavior?
client 识别 -32600 Unknown session id(或server 端明确表示 session 失效的 JSON-RPC 错误)为 session 失效信号 → 自动重发 initialize 握手获取新 session id → 重放原调用一次。至少应把「需要 /mcp 手动重连」作为显式错误提示透出,而不是静默重发同一旧 id。
Additional information
- 影响:无人值守自动化(定时心跳 + MCP 工具调用的 agent loop)在 server 重启后永久卡死且无法自愈,必须人工介入。MCP server 长驻进程重启是常态事件(编辑器重启、崩溃恢复、版本升级),该缺口使 HTTP 传输的 MCP 集成无法用于无人值守场景。
- Related:#2109 — stdio 侧同类重连缺口(server 进程意外死亡后不自动重连、调用挂起至
toolTimeoutMs);两条一起修可补齐完整的 MCP 重连矩阵(stdio 进程死亡 / HTTP session 失效)。#1942 — Streamable HTTP 启动超时(同传输、不同问题)。
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the mcp.json Streamable HTTP configuration and reproduce the failure against a restarted server at /mcp, then trace the MCP client's request and retry path. Done means recognizing the -32600 unknown-session response, reinitializing to obtain a new session id, and retrying the original call once; if that is unsupported, expose an explicit reconnect error instead of resending the stale id.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- cli, networking
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 58/100