v0.0.14: stdio tools/call times out when the target has not received initialization

[cvallottonv]

Environment
tunnel-client: 0.0.14+0f870e50a973fa820d4c409000059e181e8d242b
OS: Amazon Linux 2023
Architecture: ARM64 / aarch64
MCP target: Java 21 stdio server using the MCP Java SDK
Startup command:
tunnel-client run --profile pmpmc-src --mcp.stdio-send-initialized-notification
Observed behavior

The tunnel appears healthy:

tunnel-client doctor: PASS
/healthz: HTTP 200, live
/readyz: HTTP 200, ready
The Java MCP child process remains active.
Commands are successfully enqueued and polled.

However, every real tool call from ChatGPT—including one made from a new chat—fails with:

HTTP 504: MCP request timed out

The tunnel log records:

command response deadline reached; dropping without posting a response
Diagnostic evidence

A sanitized strace capture of the Java child during the first tool call after a controlled service restart shows:

Java reads the complete JSON-RPC tools/call request from stdin.
Example request properties:
id: 0
method: tools/call
tool: code_read
Java does not write a response to stdout.
No processing exception is written to stderr.
No initialize request or notifications/initialized notification was observed before the tools/call.
Standalone target tests

The same Java JAR was tested directly over stdio:

initialize + notifications/initialized + tools/list: works.
Numeric and string JSON-RPC IDs: both work.
initialize + notifications/initialized + the same tools/call: works.
notifications/initialized + the same tools/call: also works.
tools/call without initialization: ignored and no response is produced.

This indicates that the MCP server and the tool implementation are functional. The timeout appears to occur because the live stdio target receives tools/call while its MCP session has not been initialized.

Expected behavior

Before forwarding tools/call to a newly started or restarted stdio target, tunnel-client should establish the target's initialized state.

When --mcp.stdio-send-initialized-notification is enabled, the required initialization exchange or notification should reach the stdio target before normal tool requests are dispatched.

Restarting the local target should not leave the tunnel reporting ready while all subsequent MCP requests time out.

Reproduction notes
Reproduced after a controlled restart of tunnel-client.
Reproduced from a completely new ChatGPT conversation.
The production service remained healthy according to its health endpoints.
Tunnel IDs, request IDs, session metadata, organization identifiers, and other sensitive values have been redacted.
Sanitized logs and strace excerpts can be provided if needed.

[bpthevenot-hub]

?

[denyska-oai]

Can you confirm whether more than one tunnel-client process is using the same tunnel ID, possibly on another host, in another container, or briefly overlapping during a service restart?

Each instance launches its own stdio MCP child, and tunnel requests are not pinned to the instance that handled initialization. With multiple instances, initialize can reach one child while a later tools/call reaches another child that has not been initialized.

If multiple instances are running, could you retry with exactly one active instance and let us know whether the timeout still occurs? If your reported reproduction already used only one instance, please confirm that too. We have also reproduced the missing-initialization behavior with a single instance locally, so this question is to distinguish the deployment scenarios, not to assume concurrency is the cause.

[cvallottonv]

Thanks for checking. We can confirm that the reported reproduction used exactly one active tunnel-client instance for this tunnel ID.

The deployment was a single systemd-managed service on one host, with no container or second host configured to use the same tunnel ID.

During the controlled restart, systemd stopped the previous instance before starting the new one. The logs show:

• Previous process exited at 11:05:32.619
• New tunnel-client instance was created at 11:05:32.691
• The failing tools/call was received around 11:08
• The response deadline was reached at 11:10

Therefore, only the new instance was active when the timeout occurred.

As a temporary workaround, we implemented an external Python stdio compatibility adapter. We did not modify the tunnel-client binary. The adapter sits between tunnel-client and the Java MCP server and injects notifications/initialized before the first operational request when the child has not received MCP initialization.

With the same single-instance deployment, the previously failing code_read request succeeded after enabling the adapter. We then executed several consecutive code_find, code_search, and code_read requests without timeouts.

Disabling the workaround reproduced the original behavior, while enabling it restored normal operation. This strongly suggests that multiple instances were not required to reproduce the issue in our environment and that ensuring initialization reaches the active stdio child resolves the observed failure.

We can provide the sanitized adapter implementation and the relevant logs if that would be useful.