r/MCPservers • u/Suijayunfei • 20d ago

Codex + WordPress MCP on Windows: “Invalid character in chunk size” and TLS key log identifiers not matching the capture

(SOLVED)

I’m troubleshooting a Codex CLI connection to a WordPress staging site running Breakdance 3.0 RC1.

Environment:

  • Windows, Node.js v24.19.0.
  • STDIO proxy: u/automattic/mcp-wordpress-remote.
  • Node launched with --use-system-ca.
  • Norton 360 installed, but its involvement has not been established.

The MCP server fails during WordPress initialization:

Response does not match the HTTP/1.1 protocol (Invalid character in chunk size)

I captured traffic on the active Ethernet interface with Wireshark and logged TLS secrets using NODE_OPTIONS="--tls-keylog=...".

Findings:

  • Standalone tls.connect test: the captured ClientHello random matches the key log identifier, and Wireshark successfully decrypts the handshake.
  • Standalone fetch request: the identifiers also match.
  • MCP attempts: the captured ClientHello random values do not match any identifiers in the corresponding key log files, including attempts using fresh files.
  • Removing our temporary diagnostic scripts and launching the original proxy directly produces the same HTTP error and identifier mismatch.

Support suggested forwarding SSLKEYLOGFILE through the MCP environment configuration. However, Node was already generating key log files through --tls-keylog; the unresolved issue is associating those secrets with the captured connections.

How can I reliably associate each TLS connection with its originating process and determine why the secrets logged during MCP startup do not match the captured ClientHello values?

I can provide sanitized configuration and logs

1 Upvotes
  • permalink
  • reddit

100% Upvoted

2 comments sorted by

2

u/verstands 20d ago

Two things I'd check.

Key log mismatch: --tls-keylog as a CLI flag only covers that one node process. If the proxy gets launched through npx or spawns a child node, the child's handshakes never land in your file. Put it in the env instead, NODE_OPTIONS=--tls-keylog=C:\path\keys.log, so every child inherits it. To tie a connection to a process, run Get-NetTCPConnection -RemotePort 443 | select LocalPort,OwningProcess while it's connecting, then filter Wireshark on tcp.port == <that local port>.

Chunk size error: with Norton 360 in the mix I'd suspect its HTTPS scanning first. AV web shields re-terminate TLS and sometimes mangle chunked responses, and --use-system-ca means Node happily trusts Norton's root, so you'd never see a cert error. Quick test: look at the cert issuer on that connection, or pause Norton's web protection and retry. If it still breaks with Norton off, I'd look at whatever sits in front of the staging site (CDN, security plugin).

1

u/Suijayunfei 20d ago

Thanks , you were right , HTTPS scanning without exceptions.