[BUG] HTTP (streamable) MCP server on Windows native build: (B) tools never register despite a successful connection + working `tools/list`, and (A) Bun runtime rejects a valid public TLS chain while ignoring `NODE_EXTRA_CA_CERTS`

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported as a single combined report.
• [x] These are two tightly related symptoms hit with the same HTTP MCP server; (B) is the primary bug and (A) is the secondary blocker I had to work around to even reach (B). Happy to split into two issues if maintainers prefer.
• [x] I am using the latest version of Claude Code.

---

Environment

| | |
|---|---|
| Claude Code | 2.1.195 |
| OS | Windows 11 Pro (10.0.26100) |
| Binary | claude.exe — Bun-compiled standalone native build |
| MCP transport | HTTP (streamable HTTP) |
| Test server | https://mcp.hiveintelligence.xyz/mcp (public, "meta-tool" MCP server) |
| System Node present | v24.15.0 (used only for the diagnostic clients / proxy below) |
| Proxy / VPN / TLS-inspection / AV | None — clean direct connection, Windows Defender only |

The target server is a public "meta-tool" MCP server: its tools/list returns 13 tools (search_tools, invoke_api_endpoint, get_api_endpoint_schema, plus 10 category-listing tools). It is stateless streamable HTTP: initialize returns no mcp-session-id (sid = null), and tools/list responds with Content-Type: application/json (not an SSE stream).

---

Summary

Adding this HTTP MCP server surfaces two distinct failures:

• Bug B (primary): The server connects — Claude Code loads its MCP instructions, and ListMcpResources / ReadMcpResource work (resources are reachable). But none of the server's 13 tools ever register with the agent: they do not appear in the tool list, cannot be found via tool search, and cannot be selected by exact name — across several full restarts. The server looks "connected" but is functionally unusable.
• Bug A (secondary / blocker): Connecting directly fails because the Bun runtime rejects a valid, public TLS certificate chain with UNKNOWN_CERTIFICATE_VERIFICATION_ERROR and ignores NODE_EXTRA_CA_CERTS. I worked around this with a local TLS-terminating proxy (details below). That workaround is also what let me isolate Bug B as client-side.

The proxy is the key piece of evidence: with Claude Code talking plain HTTP to a local proxy that re-originates HTTPS via system Node, the full MCP protocol flow is verified end-to-end (independent Node client sees initialize → 200, resources/list → resources, tools/list → all 13 tools). The server and its certificate are correct; both failures are on the Claude Code / Bun client side.

---

Bug B (PRIMARY): HTTP MCP server connects, but its tools never register

What's wrong

After the connection succeeds (see workaround section for how the connection is established), Claude Code treats the server as connected but exposes zero of its tools to the agent:

• The server's MCP instructions are loaded into the session.
• ListMcpResources and ReadMcpResource against this server work — resources are listed and readable.
• None of the 13 tools appear in the agent's tool list, in tool-search results, or are selectable by exact tool name.
• This persists across multiple full restarts of Claude Code.

In the same session, other MCP servers (stdio servers and other HTTP connectors) register their tools normally. Only this server's tools go missing — while its connection, instructions, and resources all work.

Steps to reproduce

1. Configure an HTTP (streamable) MCP server that is stateless and whose tools/list returns tools as Content-Type: application/json (not SSE). A public example is https://mcp.hiveintelligence.xyz/mcp (13 meta-tools).
2. Get Claude Code to connect to it. (On Windows native build this currently requires the TLS workaround in the Bug A section — e.g. point Claude Code at a local plain-HTTP proxy that re-originates HTTPS to the server.)
3. Confirm the server is connected: its instructions load and ListMcpResources / ReadMcpResource succeed.
4. Try to use any of the server's tools — list tools, search for them, or select one by exact name.

Observed

• Connection succeeds; instructions load; resources are listable and readable.
• No tools from this server are ever available to the agent. Not in the tool list, not via tool search, not by exact-name selection. Stable across full restarts.

Expected

• After a successful connection whose tools/list returns N tools, all N tools should be registered and callable by the agent — the same way every other connected MCP server's tools register in the same session.

Evidence that the server is correct and the bug is client-side

Through the local proxy, an independent Node MCP client drives the identical wire endpoint Claude Code uses and observes the complete, correct flow:

• initialize → HTTP 200 (stateless; response carries no mcp-session-id).
• resources/list → returns the server's resources.
• tools/list → returns all 13 tools with full schemas, Content-Type: application/json.

So at the protocol level the server is healthy and tools/list is well-formed and complete. Claude Code consumes the connection, the instructions, and the resources from the very same server over the very same transport — but drops the tools. This points at a client-side tool-registration gap for stateless streamable-HTTP servers that return tools/list as application/json (rather than SSE) and/or that omit mcp-session-id.

Hypotheses (for triage)

• Tool registration may be gated on a code path (SSE framing, or presence of mcp-session-id) that this stateless application/json server doesn't satisfy — while resource/instruction handling tolerates it.
• A "meta-tool" shape (a small fixed set of generic dispatch tools) should not matter, but is noted in case any client-side heuristic treats it specially.

Impact

An HTTP MCP server can present as fully connected (instructions + resources working) yet expose no usable tools, with no error surfaced. The server is silently useless, and the failure is easy to misattribute to the server.

---

Bug A (SECONDARY / blocker): Bun runtime rejects a valid public TLS chain and ignores NODE_EXTRA_CA_CERTS

What's wrong

Adding the HTTP MCP server over direct HTTPS fails with:

UNKNOWN_CERTIFICATE_VERIFICATION_ERROR

The certificate is valid and public — no proxy, no MITM, no corporate CA involved:

• Chain: leaf CN=hiveintelligence.xyz → Google Trust Services WE1 → GTS Root R4 → cross-signed by GlobalSign Root CA.
• System Node v24.15.0 (tls.connect) validates the same host: authorized = true.
• curl (Windows schannel, with --ssl-no-revoke) and mainstream browsers accept the certificate.

Only Claude Code's bundled Bun runtime rejects it.

NODE_EXTRA_CA_CERTS is ignored

Setting NODE_EXTRA_CA_CERTS (User environment variable) to a PEM bundle containing WE1 + GTS Root R4 + GlobalSign Root CA does not help — even after a full reboot. The same PEM is honored by system Node against the same host. This indicates Claude Code's Bun runtime does not read NODE_EXTRA_CA_CERTS for this connection path.

Steps to reproduce

1. On the Windows native build, add an HTTP MCP server whose chain Bun's bundled path-building doesn't construct (here: a Google Trust Services leaf cross-signed up to GlobalSign Root CA): https://mcp.hiveintelligence.xyz/mcp.
2. Observe UNKNOWN_CERTIFICATE_VERIFICATION_ERROR.
3. Set NODE_EXTRA_CA_CERTS to a PEM containing WE1 + GTS Root R4 + GlobalSign Root CA; reboot; retry.
4. Compare with system Node v24.15.0 (tls.connect → authorized: true) and curl (accepts the cert) against the same host.

Observed

• Bun rejects a publicly valid certificate (UNKNOWN_CERTIFICATE_VERIFICATION_ERROR).
• NODE_EXTRA_CA_CERTS has no effect, even after reboot.
• System Node and curl accept the same certificate/chain from the same machine.

Expected

• Bun should validate any publicly valid chain that system Node / curl / browsers accept.
• If a CA must be supplied manually, NODE_EXTRA_CA_CERTS should be honored for the HTTP MCP transport, consistent with system Node and with Claude Code's documentation.

Impact

MCP servers whose chains the bundled Bun CA store / path-builder can't construct (e.g. the GTS R4 ↔ GlobalSign cross-signing here) are unreachable over direct HTTPS, with no working escape hatch, even though the certificate is valid in every other client on the machine.

Likely relation to prior cert work

This looks like the same Bun-doesn't-honor-NODE_EXTRA_CA_CERTS family as the parent #20194 and the OAuth-initiation slice #55760 (fixed 2.1.133 by threading a CA-aware fetchFn into the MCP SDK auth() call). The difference here: it is not a MITM/corporate-CA scenario — it's a valid public chain on a clean connection, failing in the HTTP MCP transport's own connection path (not just the OAuth-initiation path), and NODE_EXTRA_CA_CERTS is still ignored on 2.1.195. So the CA-awareness gap appears to persist on at least one streamable-HTTP code path on the Windows native build.

---

Workaround (and why it is strong evidence)

To get past Bug A, I run a local TLS-terminating proxy and point Claude Code at it:

Claude Code  →  http://127.0.0.1:8799  (plain HTTP, local)
                     │
                     ▼
             local proxy (system Node)
                     │  re-originates HTTPS, validates chain successfully
                     ▼
             https://mcp.hiveintelligence.xyz/mcp

• With this proxy, Bug A disappears (the local hop is plain HTTP; the HTTPS leg runs under system Node, which validates the chain) → confirms the certificate is valid and the failure is Bun-side, not server-side.
• Through the same proxy, an independent Node MCP client sees the full, correct MCP flow (initialize 200 → resources/list → tools/list returning all 13 tools) → confirms the server speaks MCP correctly.
• Yet Claude Code, talking to that same verified endpoint, connects, loads instructions, serves resources — but never registers the tools → confirms Bug B is client-side.

Net: both failures reproduce against a server and certificate that are provably correct, isolating both to the Claude Code / Bun client on the Windows native build.

---

Related issues

• #20194 — Native Claude Code not using system certs (parent Bun CA / NODE_EXTRA_CA_CERTS issue). Bug A is the same family but a valid public chain on a clean (non-MITM) connection, still failing on 2.1.195.
• #55760 — Hosted MCP OAuth initiation ignored NODE_EXTRA_CA_CERTS (fixed 2.1.133). Bug A is a different code path: the HTTP MCP transport's own connection, not OAuth initiation.
• #2682 — "MCP Tools Not Available Despite Successful Connection" (Claude Desktop, stdio): same shape as Bug B (server connects, tools/list returns tools, tools never become usable), but a different product/transport. Cross-referenced in case the root cause is shared.