Your MCP Config Was Fine. The Server Died Before the Handshake.

Sat, 23 May 2026 06:10:00 +0800

The short version

The misleading part of this incident was the surface error. Codex reported that an MCP client could not initialize and that the MCP server handshake failed. That naturally pushes you toward MCP configuration, JSON-RPC initialization, plugin settings, authentication, network transport, or stale tool caches. But the root cause was lower than the MCP protocol: one local MCP server binary was killed by the macOS dynamic linker before it could answer the initialize request. The client only saw a closed connection. The useful evidence was in the server stderr: dyld: Symbol not found, pointing at a missing Swift Concurrency runtime symbol.

In other words, MCP did not really get a chance to fail. The server process died first.

This article walks through a real troubleshooting pattern around Codex, MCP clients, and MCP servers. The failure looked like a protocol startup problem, but the root cause lived in a native macOS binary and its Swift runtime compatibility.

All private details have been removed. This article does not include real internal addresses, usernames, session IDs, full local paths, tokens, private repository names, or business system names. Paths use placeholders such as ~, <USER_HOME>, <PLUGIN_DIR>, and <PROJECT>. Log snippets keep only the technical fields needed to explain the diagnosis.

Swift on Margrop Blog

Your MCP Config Was Fine. The Server Died Before the Handshake.