Validate the handshake, not just the URL scheme, across split tool-execution transports

A split controller/executor design can pass configuration and unit tests while every tool fails at runtime if the controller and executor speak different transports on the same port. Validate a real tool-session handshake end to end—including protocol, route, and lazy session creation—not merely that each side accepts its own URL syntax. This applies when execution is delegated to a separate tool host; a 404 may be generated at that boundary even though the model can still produce text and downstream services such as GitHub are healthy.

Evidence/example — 2026-09-10 (source provenance: local candidate-signal repository, commit 5deb336 and Codex CLI 0.153.4 help/binary diagnostics): the runner launches codex exec-server with a WebSocket listener, while App Server receives an HTTP --code-mode-host origin. The installed CLI documents WebSocket/stdin listeners for exec-server, and its code-mode client contains HTTP/gRPC OpenSession routes. The existing deployment test asserts both strings but never performs the handshake; SessionManager tests mock App Server. This protocol mismatch is therefore a qualified, high-confidence mechanism for a lazy tool-session 404, but live runner logs or a container handshake are still required to confirm the active deployment.