ChatGPT no-auth tunnel plugin immediately enters reconnect loop

[channico]

Summary

A no-auth MCP plugin created through Secure MCP Tunnel is discovered successfully, but ChatGPT immediately reports that the connection has expired and repeatedly asks the user to reconnect.

The same tunnel and MCP tools work through the Responses API.

Environment

• macOS, Apple Silicon
• tunnel-client: v0.0.11+8d55683eeef80bc5e360d95abf4692454fafc615
• MCP transport: stdio
• MCP server: Python with FastMCP 3.4.7
• MCP SDK dependency: mcp 1.29.0
• ChatGPT developer-mode plugin
• Authentication supported: None
• Authentication used: None
• Tunnel and identifiers: redacted

Steps to reproduce

1. Start a local stdio MCP server with two read-only tools: search and fetch.
2. Start tunnel-client using an existing tunnel associated with the correct ChatGPT workspace.
3. Create a developer-mode ChatGPT plugin using that tunnel.
4. Confirm that ChatGPT discovers both tools and their input schemas.
5. Add the plugin to a new ChatGPT conversation.
6. Ask ChatGPT to call search and then fetch.
7. Click Reconnect when prompted.

Actual result

ChatGPT repeatedly displays:

Your connection has expired. Reconnect it before ChatGPT can use it for this request.

Clicking Reconnect returns to the same state.

The tunnel-client trace shows ChatGPT sending a server/discover request. The request is forwarded to the MCP target but fails before any tools/call request occurs.

With the Python stdio server, the MCP SDK rejects server/discover as an unsupported request.

The behavior was also reproduced using tunnel-client’s own embedded test server:

dispatcher received MCP upstream error; posted error response to control plane
rpc_method="server/discover"
status_code=400
failure_source="target_http"
transport_error_kind="http_status"
upstream_response_received=true
tunnel_client_version="0.0.11+8d55683eeef80bc5e360d95abf4692454fafc615"

Control tests

• The local stdio MCP client successfully lists and calls search and fetch.
• The OpenAI Responses API successfully invokes the same tools through the same tunnel.
• tunnel-client starts successfully and remains connected.
• The tunnel is associated with the correct ChatGPT workspace.
• Plugin creation succeeds and ChatGPT displays both discovered tools.
• The plugin reports no supported or used authorization.
• Replacing the Python MCP server with tunnel-client’s --embedded-mcp-stub does not resolve the ChatGPT reconnect loop.

Expected result

A no-auth plugin created from a healthy tunnel should remain connected and allow ChatGPT to invoke its discovered MCP tools.

Possibly related

Issue #35 reports another ChatGPT-specific tunnel endpoint compatibility problem, although its observed failure is an SSE GET probe returning 404 rather than this reconnect loop:

#35

[omarpinarecords]

Matching reproduction on current tunnel-client 0.0.12:

• macOS Apple Silicon, stdio MCP, ChatGPT developer-mode app, Authentication supported/used: None.
• The existing tunnel reports healthy and ready.
• App creation and Refresh both reach the MCP target for discovery/initialization, and ChatGPT lists five public read actions with their schemas.
• In a Work task created directly in ChatGPT Web, the first selected-app invocation immediately reports that the connection expired.
• Clicking Reconnect reports success, but the next invocation returns to the same expired state.
• No tools/call reaches the tunnel for those Work attempts.

The local profile already contains an explicit organization context, so this reproduction is not the separate tunnel_active_organization_required configuration error. The observed boundary remains ChatGPT Web Work after successful discovery and before tool invocation.

[kapunakap]

Reproduced a related but stronger failure mode on the official tunnel-client v0.0.12 on macOS/Apple Silicon with a healthy stdio MCP target.

Sanitized setup:

• official tunnel-client v0.0.12
• macOS arm64
• MCP transport behind tunnel: stdio
• local target starts successfully
• managed runtime status: process_running=true, healthy=true, ready=true
• control plane connected; authenticated metadata lookup returned HTTP 200; repeated poll cycles succeeded
• local MCP initialization and tool discovery succeed
• local end-to-end browser-backed tool smoke test succeeds (https://example.com -> Example Domain)

ChatGPT plugin creation itself now fails before the plugin is created:

• ChatGPT returns HTTP 424
• tunnel upstream returns 502
• tunnel trace shows ChatGPT sending MCP server/discover
• the downstream path does not complete discovery successfully
• no plugin is created

The tunnel remains running, healthy, and ready after the failed creation attempt, so this does not appear to be tunnel availability, workspace association, target startup, or ordinary MCP initialize/tools/list failure.

Current tunnel-client source still pins github.com/modelcontextprotocol/go-sdk v1.4.1, which predates MCP 2026 server/discover support. This looks consistent with the compatibility gap discussed here and in #40, but in this case the symptom has moved earlier in the ChatGPT lifecycle: server/discover prevents connector/plugin creation entirely rather than producing a reconnect loop after successful creation.

No tunnel IDs, API keys, browser profile data, or other credentials are included here.

[cvallottonv]

Additional reproduction on the official tunnel-client v0.0.12, using a different MCP transport and SDK.

Environment

• Linux / systemd
• tunnel-client: 0.0.12+881c9a8fed7cccbe6607cd419863bbca506b8215
• MCP transport behind the tunnel: Streamable HTTP, stateless
• MCP target: Java 21
• MCP SDK: io.modelcontextprotocol.sdk:mcp:2.0.0
• Authentication supported/used: None
• ChatGPT Business developer-mode app
• Tunnel, workspace, request IDs, and infrastructure identifiers: redacted

Confirmed working locally

Before attempting app creation:

• tunnel-client doctor passed.
• The tunnel control-plane poller started successfully.
• Tunnel metadata was fetched successfully.
• /healthz returned live.
• /readyz returned ready.
• The tunnel client initialized the HTTP MCP session successfully with protocol version 2025-06-18.
• Direct local tests of initialize, tools/list, and tools/call all passed.
• The read-only MCP tools worked locally through the same HTTP endpoint.

ChatGPT app creation failure

Creating the developer-mode app with Connection: Tunnel and Authentication: None failed with the generic ChatGPT message:

Something went wrong.

Each creation attempt reached the tunnel and the local HTTP MCP target. ChatGPT sent:

method: server/discover
id: openai-mcp-discover

The Java MCP SDK rejected the request because no handler exists for that method:

Missing handler for request type: server/discover

The tunnel logged the resulting upstream failure three times:

rpc_method="server/discover"
status_code=500
failure_source="target_http"
transport_error_kind="invalid_mcp_error"
upstream_response_received=true
upstream_status=500
response_content_type="application/json;charset=UTF-8"

No app was created.

Why this reproduction may be useful

This reproduces the server/discover compatibility failure with:

• Streamable HTTP instead of stdio;
• a stateless MCP server;
• Java MCP SDK 2.0.0 instead of Python or Node;
• a target where normal MCP initialize, tools/list, and tools/call are already confirmed working.

This suggests the failure is not specific to the stdio lifecycle or to the MCP implementations used in the earlier reports. The remaining compatibility boundary appears to be the ChatGPT app-creation server/discover request forwarded through the tunnel to an otherwise functional MCP server.

[kapunakap]

Targeted real-ChatGPT validation of the stdio compatibility candidate at 2183a1eec38c0a6b5ec87ace750482fe017ead1e found two hosted-client lifecycle problems.

Using legacy stdio targets that immediately reject server/discover:

• -32601 Method not found: app creation succeeds.

• -32602 Invalid params: app creation succeeds.

• In both cases the downstream sequence is:

  server/discover → initialize → initialize → notifications/initialized → tools/list

The two initialize requests arrived as separate control-plane commands with different JSON-RPC IDs (1 and 0). The tunnel candidate does not synthesize initialize; it only classifies discovery and returns the legacy negotiation error upstream.

Control test with MCP Go SDK v1.7.0 against the same targets:

server/discover → initialize → notifications/initialized → tools/list

That control sends exactly one initialize for both error codes.

A separate real-ChatGPT timeout probe returned 424 Connection timed out and ChatGPT sent no subsequent initialize.

This isolates the remaining behavior to hosted ChatGPT:

1. discovery timeout does not enter the legacy lifecycle;
2. immediate legacy discovery errors do enter it, but issue two initializations on the shared stdio target.

No further tunnel-client changes were made from this result. Real acceptance has not passed, and I am not claiming #41 fixed.

Candidate branch:
https://github.com/kapunakap/tunnel-client/tree/codex/fix-server-discover-legacy-compat

[kapunakap]

Hosted ChatGPT acceptance now passes with a narrow legacy stdio compatibility wrapper.

Tested setup:

• tunnel-client candidate 0.0.13-dev+2183a1e
• BrowserJack legacy stdio MCP target
• wrapper intercepts server/discover, returns JSON-RPC -32601 Method not found immediately, and does not forward that request
• every other MCP message is forwarded unchanged

Observed hosted action-refresh sequence:

server/discover -> initialize -> initialize -> notifications/initialized -> tools/list

The action refresh succeeded and exposed the BrowserJack tools. In a fresh hosted ChatGPT conversation, a real tool invocation reached the local MCP target and navigated the existing Chrome to example.com. ChatGPT returned the expected title, Example Domain. The local trace confirmed real tools/call requests, and the managed runtime remained running, healthy, and ready afterward.

The duplicate initialize requests were harmless in this test, so no initialization dedupe or cached initialization response was added.

Merged implementation and tests:
kapunakap/chatgpt-chrome-bridge#3

This is a verified local workaround, not an upstream tunnel-client or hosted ChatGPT fix.