v1.15.1 — the host-exec stdio MCP opt-in finally reaches the agent

Highlights

A stdio MCP server opted into hostExecInDocker never reached the agent (#3018, PR #3036)

The documented opt-in that runs a stdio MCP server on the host while the Docker sandbox is on had never worked, for any server, since it shipped in #1421 Phase B (2026-05-18). The shim logged stdio→http shim ready, /api/diagnostics/report listed the server, and the agent got zero tools.

Two independent defects, either one enough on its own:

• The spec named the wrong transport. supergateway serves the legacy HTTP+SSE transport for --stdio — a GET stream at /sse, POSTed messages at /message. The spec said type: "http" (Streamable HTTP), so the CLI POSTed initialize to the stream path, took a 404, and registered the server with no tools.
• The readiness probe consumed the gateway's only session. supergateway keeps a single MCP Server and connects it on every GET /sse; the second connect throws inside an Express handler and takes the gateway down. The probe opened that stream and never released it, so the agent's connect was always the fatal second one. Readiness is now proven by POST /message without a sessionId.

Why both signals looked healthy: the shim ready log came from a probe that validated the SSE endpoint while the caller labelled the spec http, and "MCP servers" in the diagnostics report reads config/mcp.json — it reports what is configured, never what is connected.

Nothing to change in your config. A config/mcp.json entry that was correct before is correct now.

Verified end to end against @modelcontextprotocol/server-memory: status: "connected" with all nine tools.

---

Also in this release: the publishGeneration host-call signature follow-up, and @mulmoclaude/core 4.6.0 / 4.7.0 (a custom view's staging base is decided per slug — #3031).

Ships @mulmoclaude/core@4.7.0 and the twelve other scoped packages listed in the changelog.

📦 npm: mulmoclaude@1.15.1

Full changelog: v1.15.0...v1.15.1