[Feature] MCP SSE/HTTP: allow ignoring TLS verification (self-signed / SAN-missing certs) in enterprise environments

Feature Requests
,
1

Summary

Please add an option to skip TLS certificate verification (or supply a custom CA / SNI override) for MCP servers configured with SSE or Streamable HTTP transport. This is essential for enterprise/intranet deployments where MCP servers are hosted behind internal CAs or legacy certificates.

Problem

When connecting Qoder to a remote MCP server over HTTPS inside a corporate network, the connection fails at the TLS layer and there is currently no way to work around it from the client side:

failed to initialize MCP client for production_mongodb_mcp:
failed to connect to SSE stream: Get "https://<internal-host>:8443/mongo-mcp":
tls: failed to verify certificate: x509: certificate is not valid for any names,
but wanted to match <internal-host>

The error format (tls: ... x509: ...) indicates the MCP client is built on Go’s crypto/tls, whose hostname verification cannot be disabled via any standard environment variable. Specifically:

  • NODE_TLS_REJECT_UNAUTHORIZED=0 → has no effect (not a Node.js TLS stack).
  • SSL_CERT_FILE / SSL_CERT_DIR → only adds trusted CAs; does not bypass SAN/hostname mismatch.
  • There is no documented Qoder setting (insecureSkipVerify, ignoreTLS, caFile, etc.) exposed in mcpServers JSON.

Common real-world triggers in enterprise environments:

  1. Certificate has no SAN, only CN — Go rejects since 1.15.
  2. Self-signed / internal-CA certificate not in system trust store.
  3. Hostname mismatch (e.g. short hostname vs FQDN, IP access).
  4. Expired internal certs during migration windows.

For STDIO transport this can be worked around by bridging via mcp-remote and setting NODE_TLS_REJECT_UNAUTHORIZED=0 in the env block, but SSE / Streamable HTTP is handled by Qoder’s own (Go) HTTP client, so the env block does not apply.

Why this matters

  • Enterprise adoption blocker: Many corporate MCP servers are only reachable via internal HTTPS with private-CA or legacy certs; today Qoder simply cannot connect to them.
  • Precedent: Cline, Continue, Claude Code (via NODE_EXTRA_CA_CERTS), MCP Inspector (via NODE_TLS_REJECT_UNAUTHORIZED), and third-party bridges (e.g. qoder2api already ships QODER_INSECURE_SKIP_VERIFY) all support similar options.
  • Workarounds are painful: Users are currently forced to run a local reverse proxy (mitmproxy / nginx with proxy_ssl_verify off) just to strip TLS — increases attack surface and adds an extra hop.

Environment
Version: 1.11.1
VSCode Version: 1.106.3 (user setup)
Commit: 536aa8ec4d2520cf68492eecce53b8b8ebff3121
Date: 2026-06-30T13:15:59.557Z
Electron: 37.7.0
Chromium: 138.0.7204.251
Node.js: 22.20.0
V8: 13.8.258.32-electron.0
OS: Windows_NT x64 10.0.26100