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

[Jup33Q]

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.

[Jup33Q]

Update — this is already fixed on main, the fix just hasn't been released yet.

Findings while preparing a patch PR:

• Latest release @moonshot-ai/kimi-code@0.38.0 (2026-08-20) still contains the throwing code path reported above.
• On main, acpMcpServersToConfigRecord in packages/acp-server/src/convert.ts already accepts stdio entries without type and maps them to { transport: 'stdio', command, args, env, runtime_id: 'local' }. This was fixed in commit 2adc6a1 via PR fix(acp-server): restore local execution fallback, stdio MCP, and session reload #3183 ("fix(acp-server): restore local execution fallback, stdio MCP, and session reload", merged 2026-08-23) — three days after the 0.38.0 release was cut.

So no patch PR from my side is needed; the remaining ask is a release. Could you publish a release (0.38.1 / 0.39.0) that includes #3183? Xcode 26's ACP integration injects its xcode-tools server into every session/new, so every released version currently fails out of the box for Xcode users.

Workaround until then (verified working with Xcode 26.6): put a tiny stdio shim between Xcode and kimi acp that (a) strips authMethods from the initialize result and (b) removes the injected stdio entry from session/new mcpServers, then register the same server (xcrun mcpbridge) in ~/.kimi/mcp.json so kimi loads it from its own config instead. Happy to post the shim here if it helps anyone.