#1099 Hosted MCP causes osctrl-api startup panic: /api/v1/mcp conflicts with GET / Issue created by pixel8ed Problem Enabling hosted MCP on osctrl v0.6.0 causes

osctrl-api

to panic during HTTP route registration, before its listener starts. This prevents the API process from becoming ready. Affected version • osctrl v0.6.0, commit

f0927d6643a4049836dc5ba67ce9a3fc276fbaac

. • Observed with the published API container image in Kubernetes. • Hosted MCP enabled with

MCP_ENABLED=true

. Our deployment also had

MCP_ALLOW_WRITES=true

. Steps to reproduce 1. Start with an otherwise working v0.6.0 API deployment and valid database, cache and authentication configuration. 2. Set

MCP_ENABLED=true

and start a replacement API process. For the exact observed configuration, also set

MCP_ALLOW_WRITES=true

. 3. Observe startup fail during registration of

/api/v1/mcp

, before the listener starts. No MCP client request is required. Actual behavior The replacement process exits with code 2. The relevant panic, with build paths omitted, is:

panic: pattern "/api/v1/mcp" (registered at cmd/api/main.go:1412)
conflicts with pattern "GET /" (registered at cmd/api/main.go:730):
/api/v1/mcp matches more methods than GET /, but has a more specific path pattern

Database and cache initialization succeeded before this failure. Existing API processes started with MCP disabled continued serving while the replacement process repeatedly failed. Expected behavior Enabling hosted MCP should allow the API to start and serve authenticated MCP requests at

/api/v1/mcp

, alongside its existing routes. Source findings The selected release registers both patterns on the same Go `http.ServeMux`: • Method-qualified root handler at line 730:

GET /

. • Conditional hosted MCP registration at lines 1410-1414: methodless

/api/v1/mcp

. This appears to be a route-pattern compatibility issue introduced with hosted MCP in #1023. The panic happens before requests reach authentication or MCP tool execution. The MCP route is conditional on `MCP_ENABLED`; its registration pattern does not depend on the write-tools setting. Workaround and regression coverage We are preparing to disable hosted MCP temporarily. Runtime recovery after that change has not yet been verified. A regression test that constructs the complete production API mux with MCP enabled would help catch this before startup. Please preserve the HTTP methods required by the hosted MCP transport when resolving the root/MCP pattern conflict. jmpsec/osctrl