ACP: stdio MCP servers rejected in session/new, session/load, session/resume since v0.37.0 (regression from #2961)

Summary

Since v0.37.0, any ACP session/new, session/load, or session/resume request that carries a stdio-type MCP server declaration fails with:

-32603 Internal error: ACP stdio MCP server <name> does not declare a runtime identity

This breaks every ACP client that forwards stdio MCP servers — including Zed, whose context servers are stdio by default and are sent with session/new. ACP treats stdio as the implied baseline transport (the kimi-code agent itself only advertises mcpCapabilities: { http: true, sse: true } because stdio needs no capability flag), so clients send stdio declarations unconditionally.

Reproduction

With any ACP client (e.g. Zed) connected to kimi-code >= 0.37.0:

v0.36.1 accepts both stdio spellings. First bad release is v0.37.0; still broken on current main (d4e0ad4b2).

Root cause

Regression introduced by 84da6629b / PR #2961 ("refactor(agent-core-v2): decouple workspace from session DI via runtime binding"), which made two changes:

1. packages/acp-server/src/convert.ts:179 — the stdio branch of acpMcpServersToConfigRecord (which in 0.36.1 mapped stdio entries to { transport: 'stdio', command, args, env }) was replaced with throw new Error('ACP stdio MCP server ... does not declare a runtime identity').
2. packages/agent-core-v2/src/workspace/workspaceMcp/workspaceMcpService.ts:128 — the session-overlay McpConnectionManager gained requireStdioRuntimeId: true, so ephemeral per-session stdio servers without an explicit runtime_id are refused (connection-manager.ts:393: "MCP stdio requires runtime_id and runtime binding").

The ACP wire protocol cannot express a runtime_id, so the two changes together categorically reject ACP stdio MCP servers.

Note on the explicit "type": "stdio" case: @agentclientprotocol/sdk@1.3.0's zMcpServerStdio schema has no type field, so zod strips it during request parsing and both spellings land in the same !('type' in server) branch. But even without the stripping, convert.ts no longer has any stdio handling — the missing branch is the bug, not the SDK.

The same commit also updated tests (test/convert.test.ts, test/lifecycle.test.ts) to assert the rejection, i.e. the behavior change was deliberate but protocol-breaking.

Suggested fix (minimal)

1. convert.ts: restore the 0.36.1 stdio mapping branch.
2. workspaceMcpService.ts: drop requireStdioRuntimeId: true from the session-overlay manager (it already defaults runtimeId: 'local', matching the baseline manager, which does not set the flag — user-config-file stdio MCP still works today). Fixing only (1) would just move the failure to engine connect time.
3. Restore the three affected tests to assert stdio servers are accepted/mapped.

Impact

• All ACP clients + stdio MCP servers (Zed included): session creation/loading fails outright.
• Affected versions: v0.37.0, v0.37.1, v0.37.2, v0.38.0, and main.
• Baseline (user config-file) stdio MCP servers are unaffected; only ACP ephemeral session-level servers are blocked.

Start with packages/acp-server/src/convert.ts and packages/agent-core-v2/src/workspace/workspaceMcp/workspaceMcpService.ts, then inspect the related connection-manager behavior. Run test/convert.test.ts and test/lifecycle.test.ts; done means ACP stdio declarations are accepted and session-level stdio servers no longer fail due to a required runtime identity.