ChatGPT Web stops issuing Secure MCP Tunnel commands after ~59 minutes while tunnel and MCP remain healthy

[ODtian]

Summary

In the same long-running ChatGPT Web conversation using a developer-mode app backed by OpenAI Secure MCP Tunnel, two independent tool-heavy workflows stopped making progress after approximately 59 minutes.

In both incidents, ChatGPT Web remained on a tool-call state and did not continue automatically. The user could manually resume the conversation later, which began another workflow.

At the failure boundary, the local Streamable HTTP MCP server had already completed its work, tunnel-client remained live and ready, control-plane polling continued, the command queue was empty, and no response deadline, rejected response, response POST failure, EOF, 401/403, synthesized 502, process exit, or restart was recorded.

This report does not claim that Secure MCP Tunnel has a universal one-hour cutoff. Other workflows in the same local log exceeded one hour. I am asking whether ChatGPT Web/Work has a server-side turn or workflow lease that can expire around this boundary, and whether tunnel-client can expose the upstream termination reason when the control plane simply stops issuing commands for an otherwise active-looking ChatGPT turn.

Environment

• Client product: ChatGPT Web, Work mode, developer-mode app
• Browser: Microsoft Edge 152.0.4191.53
• Host: Windows 11 x64, build 26200
• tunnel-client: 0.0.14+0f870e50a973fa820d4c409000059e181e8d242b
• Local MCP transport: Streamable HTTP on loopback
• Local MCP authentication: no application-layer OAuth or expiring bearer
• Control-plane route: HTTPS through a local HTTP proxy
• mcp.connection_max_ttl: 8760h
• Tunnel ID, client instance ID, command IDs, account details, local paths, and repository contents are omitted

Incident timeline

All timestamps below are UTC+08:00.

Incident	First forwarded command	Last forwarded command	Observed duration	Forwarded MCP commands
A	2026-09-03 05:13:34.959	2026-09-03 06:13:24.700	3,589.741 s / 59m 49.741s	190
B	2026-09-04 11:46:09.020	2026-09-04 12:44:49.509	3,520.489 s / 58m 40.489s	294

The incidents have very different command counts but closely clustered elapsed durations.

Incident A

The ChatGPT UI appeared to stop at an apply_patch tool card. The local MCP runtime shows that this call did not hang:

2026-09-03T06:13:11.463+08:00
tool=apply_patch
status=error
code=PATCH_CONTEXT_NOT_FOUND
duration_ms=0

The error was an ordinary patch-context mismatch returned immediately. tunnel-client then forwarded later MCP requests at:

2026-09-03T06:13:12.118+08:00
2026-09-03T06:13:24.700+08:00

This shows that the locally displayed/stale tool card was not a still-running local apply_patch, and that the remote workflow continued to issue at least one later request before stopping.

Telemetry sampled from 06:12:35 through 06:13:45 reported:

diagnosis=healthy
local proxy process/listener=up
OpenAI direct reachability=ok
OpenAI proxy reachability=ok
independent direct canary=ok
independent proxy canary=ok
tunnel health=live
tunnel readiness=ready
deadline_drops=0
rejected_responses=0
control_plane_errors=0
eof_events=0

Incident B

The last real operating-system command completed successfully before ChatGPT stopped progressing:

2026-09-04T12:42:17.279+08:00 command started
2026-09-04T12:43:04.168+08:00 command completed
exit_code=0
elapsed_ms=46889
stdout_bytes=5825
stderr_bytes=0
output_persisted=true

After that completion, tunnel-client continued forwarding requests through 12:44:49.509. No later request for that workflow appeared.

Telemetry around the stop remained healthy:

12:44:42  enqueued=1717  polled=1717  queue=0  worker_occupancy=0  live=1  ready=1
12:45:42  enqueued=1718  polled=1718  queue=0  worker_occupancy=0  live=1  ready=1
12:46:52  enqueued=1718  polled=1718  queue=0  worker_occupancy=0  live=1  ready=1

From 12:44:22 through 12:45:12, every local and remote reachability probe remained healthy. The tunnel-client process and the local MCP host remained running and did not restart.

The log contains no failure at the 12:44:49 boundary matching any of the following:

command response deadline reached
failed to post response
rejected response
unexpected EOF
client_internal 502
transport closed
401 / 403
process exit or restart

Why this does not appear to be a universal local one-hour cutoff

The same tunnel-client log contains other workflows with the following first-to-last-command durations:

102.82 minutes / 208 commands
100.82 minutes / 408 commands
79.91 minutes  / 244 commands
75.62 minutes  / 198 commands
68.64 minutes  / 202 commands
68.56 minutes  / 231 commands
65.42 minutes  / 148 commands
61.21 minutes  / 197 commands

Therefore neither a universal tunnel-client 60-minute cutoff nor a universal 300-command cutoff fits the observed data.

The narrower observation is that two failures in the same ChatGPT conversation clustered at 58m40s and 59m50s despite substantially different command counts.

Publicly reported adjacent behavior

A separate local-tools bridge reported a closely related symptom: its MCP handler returned, pending tool count returned to zero, the local background result remained healthy and readable, but ChatGPT issued no follow-up poll and the turn remained stuck as generating. The reporter concluded that the evidence pointed to the ChatGPT turn/tool orchestrator rather than the local MCP process:

• v2.0.2: turn can stay generating for 10+ minutes after tool result; watchdog reports no visible progress but cannot recover totec448-spec/chat-on-steroids#27

I also compared this incident against known tunnel-client reports:

• stdio response deadline can close shared transport and shut down tunnel-client #34: response deadline closes shared stdio transport and the client exits
• stdio can remain live/ready while all MCP commands fail with client_internal 502 #46: live/ready remain green while subsequent commands repeatedly fail with synthesized 502
• Frequent unexpected EOF during control-plane long polling #51: proxied long-poll unexpected EOF, followed by automatic recovery
• Intermittent 502 errors with stdio MCP on v0.0.10 #53: intermittent stdio 502 on older releases

The present incidents do not have those signatures, use loopback Streamable HTTP rather than stdio, and occurred on v0.0.14.

Reproduction pattern

1. Run tunnel-client v0.0.14 against a loopback Streamable HTTP MCP server.
2. Use the resulting developer-mode app in a ChatGPT Web Work conversation.
3. Keep one tool-heavy workflow active for roughly an hour, with many short MCP calls and some bounded background-command polling.
4. Observe that ChatGPT stops issuing commands and the Web UI remains at the last visible tool state.
5. Observe locally that the last command completed, the tunnel queue drained, /healthz and /readyz remain successful, and control-plane polling continues.
6. Manually resume the same conversation; tool use can continue in a new workflow.

This has occurred twice in the same conversation. It is not yet a deterministic synthetic reproducer.

Expected behavior

At least one of the following should occur:

1. The ChatGPT workflow continues after the terminal MCP result is accepted.
2. If the ChatGPT turn/workflow is intentionally bounded, the Web UI exposes an explicit terminal state instead of remaining on a stale tool card.
3. The control plane exposes a privacy-safe, machine-readable reason such as workflow_completed, workflow_expired, caller_disconnected, turn_cancelled, or response_not_consumed.
4. tunnel-client diagnostics make it possible to distinguish "the control plane has no more commands because the workflow ended" from "the workflow is still active but its tool loop is stalled."

Questions

1. Is there a ChatGPT Web/Work server-side turn, workflow, tool-orchestrator, or connector-binding lease near 60 minutes that is separate from mcp.connection_max_ttl?
2. Can maintainers inspect the two exact workflow IDs privately and determine their server-side terminal reason?
3. Does a successful terminal-response POST only acknowledge receipt by the tunnel service, or is there any observable acknowledgement that the ChatGPT workflow consumed that result?
4. Is there an existing control-plane field, endpoint, debug mode, or support archive entry that records why a workflow stopped issuing commands?
5. If this belongs to a ChatGPT Web/Work tracker rather than tunnel-client, what is the correct public or private reporting channel for preserving the workflow IDs and timestamps?

Available evidence

I can provide privately or in a further sanitized attachment:

• the two complete workflow IDs;
• command request IDs around both stop boundaries;
• a redacted tunnel-client log slice;
• the local MCP runtime lifecycle slice;
• per-10-second network and tunnel telemetry;
• process start/uptime evidence;
• queue, worker-pool, liveness, readiness, and poll-success metrics.

No prompt text, source code, command output, local repository path, API key, bearer token, tunnel ID, account identifier, or private network endpoint needs to be disclosed.

[denyska-oai]

Thanks for the detailed report. We haven't established the cause yet. To help correlate the affected requests with the upstream workflow, please submit the command request IDs privately through OpenAI Support.

Open help.openai.com and use the chat bubble in the bottom-right corner to start a support request. This is the route documented in OpenAI's official support instructions.

Please include:

• The last command request_id from the tunnel-client logs before each incident stopped, plus nearby command IDs if available.
• The two workflow IDs you mentioned.
• The incident timestamps and time zone.
• A link to this issue: ChatGPT Web stops issuing Secure MCP Tunnel commands after ~59 minutes while tunnel and MCP remain healthy #55.
• If available, a short redacted log slice around each stop.

Please send these identifiers through Support rather than posting them publicly here, and omit API keys or bearer tokens from any logs. Once submitted, you can reply here to confirm without sharing the IDs. We'll keep this issue open pending further investigation.