kimi acp rejects Xcode 26's injected stdio MCP server ("does not declare a runtime identity")

Summary

kimi acp (v0.38.0) cannot be used as a Custom ACP Agent in Xcode 26. session/new fails because Xcode injects its stdio MCP server (xcode-tools → xcrun mcpbridge) into mcpServers, and kimi rejects it with ACP stdio MCP server xcode-tools does not declare a runtime identity. The whole session creation fails, so the agent is unusable inside Xcode.

Environment

• kimi (kimi-code CLI): 0.38.0 (darwin-arm64)
• macOS 26, Apple Silicon
• Xcode 26.6 (17F113)

Steps to reproduce

1. Xcode → Settings → Intelligence → Agents → Add an Agent…
2. Register an ACP agent: Executable = /path/to/kimi, Arguments = acp (an interpreter wrapper works the same).
3. Open the coding assistant, select the agent, send any message.

Expected behavior

session/new succeeds. Ideally kimi accepts stdio MCP servers injected by the ACP client (ACP mcpCapabilities already advertises http/sse forwarding; stdio is the transport Xcode uses). At minimum, an unsupported entry should be dropped with a warning instead of failing the entire session/new.

Actual behavior

session/new returns:

{
  "jsonrpc": "2.0",
  "id": "...",
  "error": {
    "code": -32603,
    "message": "Internal error",
    "data": { "details": "ACP stdio MCP server xcode-tools does not declare a runtime identity" }
  }
}

The exact entry Xcode sends:

{
  "name": "xcode-tools",
  "command": "xcrun",
  "args": ["mcpbridge"],
  "env": [{ "name": "...", "value": "..." }]
}

Root-cause analysis

In acpMcpServersToConfigRecord the conversion of ACP mcpServers does:

if (!("type" in server)) throw new Error(`ACP stdio MCP server ${server.name} does not declare a runtime identity`);

Xcode's entry has no type field, so it throws. Worse, there is no client-side workaround at the protocol level: if the caller adds "type": "stdio" before sending, the field appears to be stripped by schema validation (unknown key) and the same error still occurs — verified by sending an entry that already contains "type": "stdio" and getting the identical error. So with 0.38.0 there is no way for an ACP client to pass any stdio MCP server through session/new without killing the session.

(Only an out-of-band shim that removes the entry from session/new before it reaches kimi acp works; the same server can then be loaded from ~/.kimi/mcp.json instead.)

Suggested fix

Any of:

1. Treat stdio entries (command present, type absent or "stdio") as valid and forward them like http/sse, gated by a trust/allowlist prompt if the rejection is intentional for security; or
2. Drop unsupported entries with a warning (the code path already does this for type: "acp") instead of throwing, so session/new succeeds.

Happy to provide the full ACP traffic log if helpful.

Start by locating acpMcpServersToConfigRecord and trace how session/new validates and converts the injected mcpServers entry. Reproduce the failure with Xcode's xcode-tools stdio server, then verify that supported or safely skipped stdio entries allow session creation without the current internal error.