chatboxai/chatbox · error · Error

Unknown transport type

Error message

Unknown transport type

What it means

Thrown at the end of createClient() when transportConfig.type matches neither 'stdio' nor 'http'. It is a defensive guard marking an unsupported/unknown transport configuration as a programming or config error rather than silently doing nothing.

Source

Thrown at src/renderer/packages/mcp/controller.ts:70

            type: 'sse',
            url: transportConfig.url,
            headers: transportConfig.headers,
          },
          onUncaughtError(error: unknown) {
            console.error('mcp:client:onUncaughtError', error)
          },
        })
      } catch (fallbackError) {
        const streamableMessage = err instanceof Error ? err.message : String(err)
        const fallbackMessage = fallbackError instanceof Error ? fallbackError.message : String(fallbackError)
        throw new Error(
          `Streamable HTTP connection failed: ${streamableMessage}\nLegacy SSE fallback failed: ${fallbackMessage}`,
          { cause: err }
        )
      }
    }
  }
  throw new Error('Unknown transport type')
}

export class MCPServer extends Emittery<{ status: MCPServerStatus }> {
  private _status: MCPServerStatus = { state: 'idle' }
  private client?: MCPClient
  private tools?: ToolSet

  constructor(private readonly transportConfig: TransportConfig) {
    super()
  }

  get status() {
    return this._status
  }

  set status(status: MCPServerStatus) {
    this._status = status
    this.emit('status', status)

View on GitHub (pinned to 81571269ad)

Solutions

1. Set transport.type to either 'stdio' (for local command-based servers) or 'http' (for remote HTTP/SSE servers).
2. If you need pure SSE, use type 'http' — the controller auto-falls back to SSE (see error 185).
3. Recreate the server entry through the UI rather than hand-editing JSON to avoid schema drift.

Example fix

// before
{ "transport": { "type": "sse", "url": "https://..." } }

// after
{ "transport": { "type": "http", "url": "https://..." } }

const SUPPORTED = ['stdio', 'http'] as const
type SupportedTransport = typeof SUPPORTED[number]
function assertSupportedTransport(t: string): asserts t is SupportedTransport {
  if (!SUPPORTED.includes(t as SupportedTransport)) {
    throw new Error(`transport.type must be one of ${SUPPORTED.join(', ')}, got: ${t}`)
  }
}
assertSupportedTransport(config.transport.type)

function isSupportedTransportType(t: unknown): t is 'stdio' | 'http' {
  return t === 'stdio' || t === 'http'
}

try {
  await createClient(config.transport)
} catch (e) {
  if (e instanceof Error && e.message === 'Unknown transport type') {
    // reset config.transport.type to 'http' or 'stdio' and re-prompt
  }
}

When it happens

Trigger: An MCP server config whose transport.type is a value other than 'stdio' or 'http' (e.g. a typo like 'sse' as a top-level type, 'ws', or undefined). The function's two if-blocks for 'stdio' and 'http' both fall through.

Common situations: Manual edit of MCP config JSON with a wrong transport type; migration from an older config schema that used a different type name; corrupted/defaulted config object with type undefined.

Related errors

• Failed to start server: ${server.status.state}
• Custom provider "${providerId}" conflicts with a builtin pro
• Streamable HTTP connection failed: ${streamableMessage}\nLeg
• Unsupported search provider: ${provider}
• No readable text content found in EPUB file

AI-assisted analysis of chatboxai/chatbox@81571269ad (2026-08-12). Data as JSON: /api/errors/dc011539c96782f7. Report an issue: GitHub.