openai / openai/codex

Desktop: enabled public HTTPS MCP works locally but is absent from cloud session tools

Open
#45,640 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

app bug mcp
Dominant language
Rust
Stars
125k
Forks
19.4k
PR merge metrics
PR metrics pending

Description

What version are you using?

Codex Desktop 26.908.40834 (from the affected session's user-agent metadata). Bundled CLI version not verified.

Platform

macOS, Apple Silicon (arm64). Cloud execution selected in the desktop app.

What issue are you seeing?

A custom MCP named youtube_transcript, served at a public HTTPS endpoint, is configured and enabled in the desktop app's Plugins → MCPs settings. The same MCP works when using local execution, according to the user, but its tools are unavailable in the affected cloud conversation.

The user supplied a screenshot showing the MCP enabled and reports having also completed the browser-based ChatGPT connection setup. The server is remotely hosted; this is not a local-only stdio server or a request to expose localhost through a tunnel.

Steps to reproduce (user-reported workflow)
  1. Configure and enable a custom public HTTPS MCP connection.
  2. Use local execution in the desktop app and successfully invoke that MCP.
  3. Use cloud execution and ask the assistant to invoke the same MCP.
  4. Observe that the assistant cannot find the MCP's tools despite the enabled configuration shown in the app.

Example task: retrieve a YouTube transcript and identify the main questions with timestamps.

Observed diagnostics in the affected cloud session
  • No tools matching youtube_transcript or transcript retrieval were exposed in the available tool catalog.
  • list_mcp_resources(server="youtube_transcript") returned:
    resources/list failed: unknown MCP server 'youtube_transcript'
  • list_mcp_resource_templates(server="youtube_transcript") returned:
    resources/templates/list failed: unknown MCP server 'youtube_transcript'

These errors came from the session's MCP registry; they are not evidence of a failed HTTPS request to the actual server. Resource support is not required for a tools-only server; the relevant observation is the unknown-server error together with missing tools.

Expected behavior

The cloud session should expose the configured supported HTTPS MCP tools, or the app should clearly explain why this connection is unavailable for the selected execution mode and provide an actionable error. An enabled toggle without an explanation leaves the user unable to distinguish configuration scope, authentication/discovery failure, and a product defect.

Additional information

The exact cause has not been diagnosed. Desktop-side connection logs and the endpoint/authentication configuration were not available to the assistant. No claim is made that cloud reachability or authentication was tested.

Troubleshooting in the conversation also repeatedly confused the location of the server with the location of its configuration, incorrectly suggesting hosting/tunnelling and repeating setup the user had already completed. Please investigate both the missing MCP tools in cloud execution and the lack of useful connection diagnostics for the assistant/user.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start at the Desktop Plugins → MCPs configuration and the cloud execution path, then inspect the session MCP registry where the unknown-server errors are reported. Compare how the enabled public HTTPS connection is discovered locally versus in a cloud session, using the reported missing tools as the reproduction. Done means supported tools are exposed in cloud sessions or an actionable configuration, authentication, or execution-mode error is shown.

Written by the indexing model from the issue text.

Assessment

Domain
cloud, desktop
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.