[Bug]

提交前确认 · Pre-submission checklist

• 我已搜索过现有 issue，确认这不是重复 / I searched existing issues and confirmed this isn't a duplicate.
• 我已阅读 CONTRIBUTING.md / I've read CONTRIBUTING.md.

问题类别 · Category

工具调用 / MCP · Tool use / MCP

涉及的 Agent 框架 · Agent framework

ZCode Agent（自研）

严重程度 · Severity

影响体验 · Major (功能可用但体验受损 / works but degraded)

复现频率 · Reproducibility

必现 · Always

问题描述 · Description

When a Streamable-HTTP MCP server is restarted (process/container restart) while a ZCode chat session is active, the agent's transport for that server keeps a stale server-side session id. Every subsequent tool call to that server fails for the remainder of the session. The only recovery is to start a brand-new chat; reconnecting/toggling the server in Settings → MCP does not help.

This report covers two sides of the same problem:

1. Bug — the in-UI "reconnect" does not refresh the current session's transport.
2. Feature request — a way to hot-reload an MCP server's transport for the current session (and ideally a per-session transport-health indicator), plus agent-side self-healing.

复现步骤 · Steps to reproduce

1. Start a ZCode chat session with a Streamable-HTTP MCP server connected (e.g. a FastMCP server at http://localhost:6003/mcp). Confirm its tools work (e.g. an execute_query call succeeds).
2. Restart the MCP server process/container (the server forgets its MCP session id).
3. In the same chat session, call any tool of that server again → it fails (see Actual behavior).
4. Open Settings → MCP, reconnect / toggle the server off and on. It shows as connected and its tools are re-listed.
5. Back in the same chat session, call the tool again → still fails, identically.
6. Start a new chat → auto-connect creates a fresh transport → the tool works again.

期望表现 · Expected behavior

Reconnecting an MCP server in Settings → MCP (or any explicit "reload server" action) should give the currently active session a fresh, working transport — so tool calls recover without discarding the conversation. At minimum, there should be a documented one-click action that rebuilds a server's transport for the current session.

实际表现 · Actual behavior

• All tool calls to the affected server return, for the rest of the session:
  Streamable HTTP error: Error POSTing to endpoint: {"jsonrpc":"2.0","id":"server-error","error":{"code":-32600,"message":"Session not found"}}
• Reconnecting in Settings → MCP shows the server as connected and re-enumerates its tools, but the active session keeps failing. Starting a new chat is the only fix.
• An MCP-provided "restart" tool (e.g. restart_1c_session) is useless here: it rides the same dead transport, so it returns the same error — the agent cannot self-heal.

ZCode 版本 · ZCode version

0.15.2

设备 / 系统 / 浏览器 · Device / OS / Browser

Windows 10.0.26200 (x64)

截图 / 录屏 / 日志 · Screenshots / Recordings / Logs

Root-cause evidence (from ZCode runtime logs)

From ~/.zcode/cli/log/zcode-2026-07-30.jsonl:

• The active session is sess_0d2e97b4-9665-4835-9773-473ec8109e27. After the server restart, every tool.call.failed for that trace carries the -32600 Session not found payload above.
• mcp.server.* events carry a sessionId field (= ZCode session id, not the server-side MCP session id). The session's transport for the affected server was established once at session start and was never recreated.
• The UI reconnects recorded in the logs arrive with sessionId: null; each yields a successful mcp.server.connected (tools re-listed), but none of them binds to the live agent session sess_0d2e97b4-…. That is why toggling the server in Settings has no effect on the running conversation.
• A control server whose container was not restarted kept working in the same session — confirming the failure is scoped to the server whose transport holds a stale session id.

Note: the behavioral picture is unambiguous from the logs. The internal client logic (why a UI reconnect is sessionId: null and does not update the agent session's transport) is inferred from log behavior, not from reading client source.

Impact

• Any external event that restarts an MCP server (Docker restart, deploy, host reboot, server crash) silently bricks that server for the entire ongoing conversation.
• Loss of conversation context: the workaround forces a new chat, discarding the working context — costly for long, in-depth sessions.
• No in-session recovery path exists, and the agent cannot fix it itself.

Feature request (solution direction)

1. In-session MCP transport reload. Add an explicit action (e.g. "Reload for current session" / "Reconnect to active session" in Settings → MCP, or a command) that recreates the transport bound to the live session, acquiring a fresh server-side session id — distinct from the current reconnect which only refreshes the UI-side connection.
2. Automatic detection & recovery. On a persistent -32600 Session not found / transport-level failure for a server, automatically re-handshake and rebuild that session's transport (bounded retry/backoff), so a server restart is transparent to the user.
3. Per-session transport health. Surface per-server, per-session health (last tool result, stale-session detection) in the UI, so the failure mode is visible instead of appearing as generic tool errors.
4. Agent-side hook (optional). Allow the agent to trigger a transport reload for a named server (without leaving the session), so workflows can recover programmatically.

Start by reproducing the failure with the FastMCP server at http://localhost:6003/mcp, then trace the Settings → MCP reconnect flow alongside the active chat's MCP transport and session lifecycle. Done means restarting the server no longer requires a new chat: reconnecting or automatic recovery restores tool calls for the current session.