Skip to content

ChatGPT Manual Refresh fails after successful main/server/discover; no main/tools/list follows on v0.0.14 #57

Open
Open
ChatGPT Manual Refresh fails after successful main/server/discover; no main/tools/list follows on v0.0.14#57

Description

@fighy2021
fighy2021
opened on Sep 5, 2026

English

Summary

A ChatGPT Web developer-mode app backed by OpenAI Secure MCP Tunnel can be created successfully with OAuth, but the app does not expose any usable MCP actions and the manual Refresh operation fails.

The reproduction uses the official tunnel-client v0.0.14 Windows binary together with its official --embedded-mcp-stub.

OAuth completes successfully through Google and the app can be created and installed. The tunnel remains live and ready.

During the final targeted debug capture, the ChatGPT-hosted side issued server/discover to the customer MCP main channel three times. Each request reached the official embedded MCP stub, received a successful response, and that final response was successfully delivered back to the OpenAI control plane:

rpc_method="server/discover"
rpc_request_id="openai-mcp-discover"
channel="main"
status_code=200
has_error=false
finalResponse=true

However, no subsequent main/tools/list or main/tools/call was observed in the capture, and the ChatGPT app still exposed no usable actions.

The official v0.0.14 embedded MCP stub defines three tools:

server_info
echo
uppercase

They are registered in:

cmd/client/dev_mcp_stub.go
tag: v0.0.14

This report does not claim that the root cause has been established. The observable failure boundary is after a successful main/server/discover response has been delivered to the OpenAI control plane and before usable tool definitions become available in ChatGPT.

Environment

  • Client product: ChatGPT Web

  • Workspace: Personal / Plus

  • Developer Mode: enabled

  • Host: Windows 11 x64

  • Browser: Chrome desktop

  • tunnel-client: 0.0.14+0f870e50a973fa820d4c409000059e181e8d242b

  • Official Windows amd64 binary

  • Binary SHA-256:

    784AB8DA7B5A88F0109F1FD8AAF0A1C86067430B896DDDF307EF7E3CC49FA1A5

  • ChatGPT app connection: Secure MCP Tunnel

  • Authentication: OAuth

  • OAuth client registration: user-defined OAuth client

  • OAuth provider: Google

  • MCP target: official --embedded-mcp-stub

  • MCP transport behind the tunnel: Streamable HTTP on loopback

  • Control-plane route: direct HTTPS

  • --harpoon.allow-plaintext-http enabled only for the trusted loopback development target

  • Raw HTTP logging: disabled

  • Tunnel status during reproduction:

    Health: live
Ready: ready
Logs: connected

Tunnel ID, client instance ID, command/request IDs, OAuth client ID, OAuth client secret, API keys, bearer tokens, account identifiers, local usernames, and local repository paths are omitted from this public report.

Relevant startup configuration

The official binary was started approximately as follows, with identifiers and local paths redacted:

tunnel-client.exe run ^
  --embedded-mcp-stub ^
  --control-plane.tunnel-id tunnel_REDACTED ^
  --harpoon.allow-plaintext-http ^
  --health.listen-addr 127.0.0.1:0 ^
  --health.url-file <REDACTED>

The control-plane API key was supplied through an environment variable and is not included here.

Local health verification

Immediately before the targeted reproduction, the running tunnel-client instance returned:

GET /readyz
HTTP 200
ready

and:

GET /healthz
HTTP 200
live

The support diagnostics also reported:

main.enabled = true
main.probe_status = ok
main.transport = http-streamable
raw_http_logging_enabled = false
http_raw_unsafe = false
harpoon.capture_payloads = false

The runtime log level had been changed to debug before the reproduction.

OAuth control result

OAuth itself can complete successfully:

  1. The ChatGPT developer-mode app can be created.
  2. ChatGPT redirects to Google authorization.
  3. Google login and authorization complete.
  4. The browser returns to ChatGPT.
  5. The app appears in ChatGPT.
  6. The app information page reports OAuth as both supported and used authorization.

This report is therefore focused on the subsequent MCP action/tool discovery path, not on initial OAuth or PKCE setup.

Steps to reproduce

  1. Start the official tunnel-client v0.0.14 binary with --embedded-mcp-stub.

  2. Confirm:

    /healthz -> 200 live
/readyz  -> 200 ready

  3. Create a ChatGPT developer-mode app using:

    • Connection: Tunnel
    • Authentication: OAuth
    • User-defined OAuth client
    • Google as the OAuth provider

  4. Complete OAuth successfully.

  5. Confirm that the app is created and visible in ChatGPT.

  6. Open:

    Settings
→ Apps
→ the developer-mode app

  7. Use the manual Refresh action.

  8. Observe that the refresh does not produce usable app actions. In reproduced attempts the UI has shown the generic error:

    Something went wrong.

  9. Inspect the tunnel-client debug trace for the same operation.

Final targeted reproduction

The final debug capture was taken on:

2026-09-05
UTC+08:00

Target window:

19:49:14 - 19:49:54

Three separate successful main/server/discover responses were observed.

Attempt 1

2026-09-05T19:49:14.786+08:00
dispatcher received response from MCP server
rpc_method="server/discover"
rpc_request_id="openai-mcp-discover"
has_error=false

2026-09-05T19:49:15.001+08:00
dispatcher delivered response to control plane
channel="main"
rpc_method="server/discover"
rpc_request_id="openai-mcp-discover"
status_code=200
has_error=false
finalResponse=true

Attempt 2

2026-09-05T19:49:38.976+08:00
dispatcher received response from MCP server
rpc_method="server/discover"
rpc_request_id="openai-mcp-discover"
has_error=false

2026-09-05T19:49:39.188+08:00
dispatcher delivered response to control plane
channel="main"
rpc_method="server/discover"
rpc_request_id="openai-mcp-discover"
status_code=200
has_error=false
finalResponse=true

Attempt 3

2026-09-05T19:49:53.780+08:00
dispatcher received response from MCP server
rpc_method="server/discover"
rpc_request_id="openai-mcp-discover"
has_error=false

2026-09-05T19:49:53.994+08:00
dispatcher delivered response to control plane
channel="main"
rpc_method="server/discover"
rpc_request_id="openai-mcp-discover"
status_code=200
has_error=false
finalResponse=true

All command IDs, tunnel request IDs, tunnel IDs, and client instance IDs have been intentionally removed from the public excerpts.

Main-channel observation

For the supplied debug capture, the customer MCP main channel shows:

main/server/discover: 3 successful final responses
main/tools/list:      0 observed
main/tools/call:      0 observed

OAuth/Harpoon control traffic also occurred during the wider session and includes MCP-like methods such as tools/list, but those requests use the harpoon control channel and are intentionally not counted here as customer MCP main traffic.

Embedded MCP control

The target is not a custom CAT-RV MCP implementation.

It is the official MCP test server built into tunnel-client v0.0.14.

The official source registers:

server_info
echo
uppercase

Therefore this reproduction does not depend on CAT-RV repository code, a third-party MCP framework, or a custom tool implementation.

ChatGPT-side result

The app is created and visible in ChatGPT, but:

  • the app page reports no available app actions;
  • ChatGPT can identify the app/namespace;
  • the three official embedded tools are not available for invocation;
  • asking ChatGPT to use server_info, echo, or uppercase does not result in a main/tools/call reaching the tunnel;
  • manual Refresh does not make the tools available.

Why this does not currently look like a local MCP availability failure

During the reproduction:

  • the official tunnel-client process remained running;
  • /healthz returned 200 live;
  • /readyz returned 200 ready;
  • the main channel remained enabled;
  • the main probe remained ok;
  • control-plane connectivity remained active;
  • OAuth had successfully allowed the app to be created;
  • main/server/discover reached the official embedded MCP;
  • the embedded MCP returned a non-error response;
  • tunnel-client successfully POSTed that response to the control plane;
  • the final response was recorded with status_code=200, has_error=false, and finalResponse=true.

The observable boundary is after that successful discovery response and before usable customer MCP actions appear in ChatGPT.

Related reports

This appears related to, but is not the same reproduction as:

  • Tool definitions may remain stale until manual refresh #42 — Tool definitions may remain stale until manual refresh

    In the closing maintainer response, it was stated that ChatGPT uses a frozen tool snapshot and that manual Refresh is the supported tool-catalog update path.

    The same response specifically noted that if manual Refresh itself fails to fetch a current tools/list result, that would be a separate actionable bug and should be reported with the workspace plan, exact UI path, tunnel-client version, and a sanitized tunnel trace.

  • ChatGPT no-auth tunnel plugin immediately enters reconnect loop #41 — ChatGPT no-auth tunnel plugin immediately enters reconnect loop

    That issue contains real-ChatGPT investigation of hosted lifecycle behavior around server/discover, initialization, tools/list, and later tool invocation.

    This reproduction differs because it uses official v0.0.14, OAuth can complete, the app can be created, and server/discover itself succeeds with a final HTTP 200 response.

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

    That report describes an adjacent hosted-client boundary in which ChatGPT stops issuing later MCP commands while the tunnel and local MCP remain healthy.

    The present reproduction occurs much earlier, during app action/tool discovery and manual Refresh.

Expected behavior

After a successful Refresh against the official v0.0.14 embedded MCP stub, ChatGPT should expose the demo tools:

server_info
echo
uppercase

If the current hosted protocol does not require a subsequent tools/list after server/discover, then the equivalent discovery path should still result in these tool definitions becoming available to the app.

If the hosted workflow cannot continue after successful discovery, the UI or diagnostics should expose a privacy-safe, machine-readable failure reason instead of only a generic refresh failure.

Questions

  1. After a successful main/server/discover response from the official v0.0.14 embedded stub, what hosted ChatGPT lifecycle is expected to register the app's tools?
  2. Is a subsequent main/tools/list expected, or are the tool schemas obtained through another hosted discovery path?
  3. Why would three successful final server/discover responses be accepted by the control plane while the app still exposes no actions?
  4. Is there a hosted workflow state or terminal reason that can explain why the action Refresh stops at this boundary?
  5. Which command/request/workflow identifiers would be most useful to provide privately through OpenAI Support for correlation?
  6. Is this a known ChatGPT hosted-app issue, or is there an additional tunnel-client diagnostic that would help isolate the boundary further?

Available evidence

I can provide privately through OpenAI Support, if useful:

  • the complete command request IDs for all three server/discover attempts;
  • their corresponding tunnel request IDs;
  • the client instance ID;
  • the tunnel ID;
  • exact timestamps and time zone;
  • the complete redacted debug capture;
  • the generated tunnel-client support archive;
  • tunnel metrics and status snapshots;
  • screenshots of the failed manual Refresh and the app showing no available actions.

I am intentionally not posting those internal identifiers publicly.

No prompt text, CAT-RV source code, repository contents, API key, OAuth client secret, access token, refresh token, bearer token, browser cookie, or other credential is required to reproduce the observable boundary.

中文版

摘要

透過 OpenAI Secure MCP Tunnel 建立的 ChatGPT Web 開發者模式應用程式，可以成功完成 OAuth 並建立，但是應用程式沒有出現任何可用的 MCP 動作，而且手動執行「重新整理」會失敗。

本次重現使用的是 OpenAI 官方 Windows 版 tunnel-client v0.0.14，以及該執行檔內建的官方 --embedded-mcp-stub 測試 MCP。

Google OAuth 可以成功完成，應用程式也能建立並安裝，Tunnel 全程維持正常。

在最後一次針對性的除錯紀錄中，ChatGPT 託管端總共三次向客戶 MCP 的 main 通道送出 server/discover。三次請求都成功抵達官方 embedded MCP stub、取得正常回覆，並且成功把最終回覆送回 OpenAI 控制端：

rpc_method="server/discover"
rpc_request_id="openai-mcp-discover"
channel="main"
status_code=200
has_error=false
finalResponse=true

但是在這份紀錄中，沒有觀察到後續的 main/tools/list 或 main/tools/call，而 ChatGPT 中的應用程式仍然沒有任何可用動作。

官方 v0.0.14 內建測試 MCP 明確定義了三個工具：

server_info
echo
uppercase

它們註冊於：

cmd/client/dev_mcp_stub.go
tag: v0.0.14

這份回報不是宣稱已經確認真正根因。目前能從直接證據確認的故障邊界，是成功的 main/server/discover 最終回覆已送到 OpenAI 控制端之後，到 ChatGPT 真正出現可用工具定義之前。

環境

  • 使用產品：ChatGPT Web

  • 工作區：個人 / Plus

  • 開發者模式：已啟用

  • 主機：Windows 11 x64

  • 瀏覽器：桌面版 Chrome

  • tunnel-client：0.0.14+0f870e50a973fa820d4c409000059e181e8d242b

  • OpenAI 官方 Windows amd64 執行檔

  • 執行檔 SHA-256：

    784AB8DA7B5A88F0109F1FD8AAF0A1C86067430B896DDDF307EF7E3CC49FA1A5

  • ChatGPT 應用程式連線方式：Secure MCP Tunnel

  • 驗證方式：OAuth

  • OAuth 用戶端註冊方式：使用者自訂 OAuth 用戶端

  • OAuth 提供者：Google

  • MCP 目標：官方 --embedded-mcp-stub

  • Tunnel 後方 MCP 傳輸方式：本機 loopback Streamable HTTP

  • 控制端路徑：直接 HTTPS

  • --harpoon.allow-plaintext-http：僅針對受信任的本機 loopback 開發目標啟用

  • 原始 HTTP 紀錄：關閉

  • 重現期間 Tunnel 狀態：

    Health: live
Ready: ready
Logs: connected

公開內容刻意省略 Tunnel ID、client instance ID、命令／請求識別碼、OAuth Client ID、OAuth Client Secret、API key、bearer token、帳號識別資料、本機使用者名稱與本機 repository 路徑。

相關啟動設定

官方執行檔大致以以下方式啟動；所有識別資料與本機路徑均已遮罩：

tunnel-client.exe run ^
  --embedded-mcp-stub ^
  --control-plane.tunnel-id tunnel_REDACTED ^
  --harpoon.allow-plaintext-http ^
  --health.listen-addr 127.0.0.1:0 ^
  --health.url-file <REDACTED>

控制端 API key 透過環境變數提供，沒有包含在本回報中。

本機健康狀態驗證

在最後一次重現前，實際執行中的 tunnel-client 回覆：

GET /readyz
HTTP 200
ready

以及：

GET /healthz
HTTP 200
live

支援診斷資料同時顯示：

main.enabled = true
main.probe_status = ok
main.transport = http-streamable
raw_http_logging_enabled = false
http_raw_unsafe = false
harpoon.capture_payloads = false

重現前已將執行期間紀錄層級切換至 debug。

OAuth 對照結果

OAuth 本身可以成功完成：

  1. ChatGPT 開發者模式應用程式可以建立。
  2. ChatGPT 正確跳轉至 Google 授權。
  3. Google 登入與授權完成。
  4. 瀏覽器成功返回 ChatGPT。
  5. 應用程式出現在 ChatGPT 中。
  6. 應用程式資訊頁顯示 OAuth 同時為支援及實際使用的驗證方式。

因此這份回報的焦點是之後的 MCP 動作／工具探索流程，而不是一開始的 OAuth 或 PKCE 設定。

重現步驟

  1. 使用官方 tunnel-client v0.0.14 並啟用 --embedded-mcp-stub。

  2. 確認：

    /healthz -> 200 live
/readyz  -> 200 ready

  3. 建立 ChatGPT 開發者模式應用程式：

    • 連線：Tunnel
    • 驗證：OAuth
    • 使用者自訂 OAuth 用戶端
    • OAuth 提供者：Google

  4. 成功完成 OAuth。

  5. 確認應用程式已建立且可在 ChatGPT 中看到。

  6. 開啟：

    設定
→ 外掛程式
→ 該開發者模式應用程式

  7. 執行一次手動「重新整理」。

  8. 觀察重新整理後仍沒有可用的應用程式動作。在已重現的嘗試中，介面會顯示：

    Something went wrong.

  9. 查看同一操作對應的 tunnel-client debug 紀錄。

最後一次針對性重現

最後一份 debug capture 時間為：

2026-09-05
UTC+08:00

目標時間窗：

19:49:14 - 19:49:54

總共觀察到三次成功的 main/server/discover 最終回覆。

第一次

2026-09-05T19:49:14.786+08:00
dispatcher received response from MCP server
rpc_method="server/discover"
rpc_request_id="openai-mcp-discover"
has_error=false

2026-09-05T19:49:15.001+08:00
dispatcher delivered response to control plane
channel="main"
rpc_method="server/discover"
rpc_request_id="openai-mcp-discover"
status_code=200
has_error=false
finalResponse=true

第二次

2026-09-05T19:49:38.976+08:00
dispatcher received response from MCP server
rpc_method="server/discover"
rpc_request_id="openai-mcp-discover"
has_error=false

2026-09-05T19:49:39.188+08:00
dispatcher delivered response to control plane
channel="main"
rpc_method="server/discover"
rpc_request_id="openai-mcp-discover"
status_code=200
has_error=false
finalResponse=true

第三次

2026-09-05T19:49:53.780+08:00
dispatcher received response from MCP server
rpc_method="server/discover"
rpc_request_id="openai-mcp-discover"
has_error=false

2026-09-05T19:49:53.994+08:00
dispatcher delivered response to control plane
channel="main"
rpc_method="server/discover"
rpc_request_id="openai-mcp-discover"
status_code=200
has_error=false
finalResponse=true

公開節錄已刻意移除所有命令識別碼、Tunnel request ID、Tunnel ID 與 client instance ID。

main 通道觀察結果

在提供的 debug capture 中，客戶 MCP 的 main 通道觀察到：

main/server/discover：3 次成功的最終回覆
main/tools/list：     0 次
main/tools/call：     0 次

較大的工作階段中，同時存在 OAuth / Harpoon 控制流量，其中也可能出現 tools/list 等 MCP 類似方法；但是那些屬於 harpoon 控制通道，因此本回報刻意不把它們計入客戶 MCP 的 main 通道結果。

Embedded MCP 對照

這次 MCP 目標不是自行撰寫的 CAT-RV MCP。

使用的是 tunnel-client v0.0.14 官方內建的 MCP 測試伺服器。

官方原始碼明確註冊：

server_info
echo
uppercase

所以這次重現不依賴 CAT-RV repository 程式碼、第三方 MCP framework，也不依賴自行撰寫的工具實作。

ChatGPT 端結果

應用程式能建立並出現在 ChatGPT 中，但是：

  • 應用程式頁面顯示沒有可用的應用程式動作；
  • ChatGPT 可以辨識該應用程式／命名空間；
  • 官方 embedded MCP 的三個工具無法被呼叫；
  • 要求 ChatGPT 使用 server_info、echo 或 uppercase 時，沒有 main/tools/call 抵達 Tunnel；
  • 手動「重新整理」沒有讓這些工具變成可用。

為什麼目前不像本機 MCP 可用性故障

問題發生時：

  • 官方 tunnel-client 程序仍持續執行；
  • /healthz 回覆 200 live；
  • /readyz 回覆 200 ready；
  • main 通道仍為 enabled；
  • main probe 仍為 ok；
  • OpenAI 控制端連線仍保持正常；
  • OAuth 已能讓應用程式成功建立；
  • main/server/discover 確實抵達官方 embedded MCP；
  • embedded MCP 回覆非錯誤結果；
  • tunnel-client 成功把該回覆送至 OpenAI 控制端；
  • 最終回覆記錄為 status_code=200、has_error=false、finalResponse=true。

目前可以直接確認的故障邊界，是這個成功 discovery 回覆之後，到 ChatGPT 真正出現可用客戶 MCP 動作之前。

可能相關的問題

這個問題可能與以下回報相關，但重現方式並不相同：

預期行為

對官方 v0.0.14 embedded MCP stub 成功執行 Refresh 後，ChatGPT 應該能暴露這三個示範工具：

server_info
echo
uppercase

如果目前託管端使用的協定在 server/discover 成功後不需要另外送出 tools/list，那麼等效的 discovery 流程仍應該讓這三個工具定義出現在應用程式中。

如果託管端在成功 discovery 後無法繼續，介面或診斷資料至少應提供一個不洩漏隱私、可機器判讀的失敗原因，而不是只有一般性的重新整理失敗訊息。

問題

  1. 官方 v0.0.14 embedded stub 成功回覆 main/server/discover 後，ChatGPT 託管端預期應經過什麼流程來註冊應用程式工具？
  2. 正常情況下是否應該再送出 main/tools/list，還是目前工具結構會透過其他託管端 discovery 路徑取得？
  3. 為什麼三次成功、完整的 server/discover 最終回覆都被控制端接受，但 App 仍然沒有任何可用動作？
  4. 是否存在可以說明這次 Refresh 為何停在這個邊界的託管端工作流程狀態或終止原因？
  5. 如果要透過 OpenAI Support 私下提供資料，哪些命令／請求／工作流程識別碼最有助於後台對照？
  6. 這是否是已知的 ChatGPT 託管應用程式問題，或者還有其他 tunnel-client 診斷方式能進一步確認故障邊界？

可提供的證據

如果有需要，我可以透過 OpenAI Support 私下提供：

  • 三次 server/discover 的完整命令 request ID；
  • 對應的 Tunnel request ID；
  • client instance ID；
  • Tunnel ID；
  • 精確時間與時區；
  • 完整但已遮罩的 debug capture；
  • tunnel-client 產生的 support archive；
  • Tunnel metrics 與狀態快照；
  • Manual Refresh 失敗與 App 顯示沒有可用動作的截圖。

這些內部識別資料刻意不公開貼在 GitHub。

不需要公開任何 prompt 內容、CAT-RV 原始碼、repository 內容、API key、OAuth Client Secret、access token、refresh token、bearer token、瀏覽器 cookie 或其他登入憑證，就能重現目前可觀察到的故障邊界。

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions