ChatGPT Desktop: local MCP tools are discovered successfully but not exposed to Chat sessions

What version of the Codex App are you using (From “About Codex” dialog)?

26.803.10989.0

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Microsoft Windows NT 10.0.26100.0 x64

What issue are you seeing?

ChatGPT Desktop successfully starts a configured local MCP server, completes the MCP initialization handshake, calls tools/list, and receives the full tool inventory. However, those tools are not exposed to the Chat session.

The affected MCP server is configured as tessl_registry_mcp.

The prompt used in a new Chat session was:

Use the tessl_registry_mcp MCP server and list its tools.

ChatGPT responded:

I still cannot see tessl_registry_mcp in this ChatGPT session.
I checked the currently exposed connector/tool namespaces, and they are:
GitHub, Gmail, REDACTED.
tessl_registry_mcp is not among them, so I can't invoke it or enumerate its tools from here.

However, a transparent stdio capture shim placed between ChatGPT Desktop and the MCP server shows that Desktop successfully:

launches the MCP server;
sends initialize;
receives a valid initialize response;
sends notifications/initialized;
sends tools/list; and
receives the server's complete 17-tool inventory.

This was reproduced across three separate MCP server processes created during the same ChatGPT Desktop reproduction.

The MCP server returned these tools:

install
login
new_plugin
outdated
review_fix
review_run
review_view
search
skill_publish
skills_available
status
tile_publish
uninstall
update
workspace_create
workspace_list
workspace_list_members

ChatGPT Desktop also called resources/list and resources/templates/list. The server returned normal JSON-RPC Method not found responses for those methods because it does not advertise MCP resources.

There was no MCP initialization or tool-discovery error in the captured exchange.

This appears to be a failure after successful MCP tool discovery, in the path that registers/exposes locally discovered MCP tools to the Chat session.

What steps can reproduce the bug?

On Windows 11, configure the following local MCP server in ChatGPT/Codex Desktop:
- Name: tessl_registry_mcp
- Command: C:\Windows\System32\wsl.exe
- Arguments:
  - /mnt/c/Users/<USER>/AppData/Local/Programs/Tessl/tessl.exe
  - mcp
  - start
Tessl version used: 0.95.0.
For diagnostic purposes, place a transparent stdio shim between Desktop and the above command. The shim only forwards stdin/stdout unchanged while recording:
- client -> MCP server traffic;
- MCP server -> client traffic; and
- MCP server stderr.
Fully exit and restart ChatGPT Desktop.
Open a new Chat session.
Send:

Use the tessl_registry_mcp MCP server and list its tools.
Observe that Chat reports that tessl_registry_mcp is not present in its exposed tool namespaces.
Inspect the MCP shim capture.

The captured protocol exchange shows:

ChatGPT Desktop -> MCP server
- initialize
- notifications/initialized
- tools/list
- resources/list
- resources/templates/list
MCP server -> ChatGPT Desktop
- successful initialize result;
- successful tools/list result containing all 17 Tessl tools;
- Method not found for the two resource methods.
Repeat the test. In my reproduction, three MCP processes were launched and all three successfully initialized and returned the full tools/list result.

As a control test, I configured the same server through the same shim and launched it from Codex CLI 0.147.0-alpha.6.6.

The Codex CLI test succeeds: the MCP server initializes and its 17 tools are available.

Therefore the same MCP server, command, transport and shim work from Codex CLI but the successfully discovered tools are not exposed to Chat in ChatGPT Desktop.

Session/conversation/request identifiers in the attached public logs have been redacted. Token usage and context-window usage do not appear relevant to the reproduction.

What is the expected behavior?

After ChatGPT Desktop successfully initializes a configured MCP server and receives a successful tools/list response, those MCP tools should be registered and made available to the Chat session.

For this server, after discovery succeeds, Chat should be able to invoke the 17 tools returned by tessl_registry_mcp, or at minimum recognize that the MCP server and its tools are available.

Instead, Chat reports that the server is not exposed to the session even though the Desktop-side MCP client has already discovered its tools successfully.

Additional information

Control test

The same MCP server was tested through the same transparent shim using Codex CLI 0.147.0-alpha.6.6.

That test succeeds and exposes the full 17-tool inventory.

This strongly suggests that:

the MCP server itself is working;
the stdio transport is working;
the initialize handshake is working;
tools/list is working; and
the failure occurs after MCP discovery, specifically in the Desktop Chat tool-registration/exposure path.

MCP server details

Tessl CLI version:

0.95.0

Server reports:

Name: Tessl Registry MCP
Version: 0.0.1
MCP protocol version: 2025-06-18

The command used during the captured Desktop reproduction was:

C:\Windows\System32\wsl.exe /mnt/c/Users/<USER>/AppData/Local/Programs/Tessl/tessl.exe mcp start

Note that this invokes the Windows Tessl executable through WSL interoperability; it is not a Linux-native Tessl binary.

Desktop/app-server observations

The attached Desktop log covers the same reproduction.

It shows successful mcpServerStatus/list calls at the app-server RPC layer with errorCode=null.

The Desktop app-server also starts normally and reports version:

0.147.0-alpha.6.6

There is an unrelated warning in the log:

ignoring invalid experimental feature enablement keys: apps_mcp_path_override

The app remains in the connected state despite that warning.

There are also unrelated HTTP 429 Too many requests warnings later in the session. The MCP initialization and tool discovery had already completed successfully before those occurred.

Attachment glossary

The uploaded diagnostic files are:

codex-desktop-redacted-20260812-190756.log

Redacted ChatGPT/Codex Desktop application log covering the reproduction.

User paths, conversation/session identifiers, request IDs and named-pipe identifiers have been redacted. Timestamps, method names, feature flags, versions and diagnostic messages have been preserved.

ChatGPT Desktop MCP shim capture.zip

One complete capture directory from the failing ChatGPT Desktop reproduction.

It contains:

command.txt — exact working directory and child command launched by the shim.
desktop-to-tessl.bin — raw bytes sent by ChatGPT Desktop's MCP client to Tessl.
tessl-to-desktop.bin — raw bytes returned by Tessl to ChatGPT Desktop.
tessl-stderr.log — Tessl stderr/startup diagnostics.

This capture demonstrates a successful MCP initialization and a successful tools/list response containing all 17 tools even though Chat subsequently reports that tessl_registry_mcp is unavailable.

The behaviour was reproduced in three separate Desktop shim capture directories; only one complete representative capture is necessary to demonstrate the issue, but additional captures can be provided if useful.

Codex CLI MCP shim capture.zip

Equivalent capture produced using Codex CLI as a control.

This shows that the same MCP server and shim successfully initialize and expose the tools when used from Codex CLI.

Summary

The key distinction is:

MCP discovery in ChatGPT Desktop: SUCCESS

Exposure of the discovered MCP tools to Chat: FAILURE

Because the wire-level MCP exchange succeeds, this does not appear to be a Tessl startup, WSL, stdio, handshake, or tools/list failure.

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

Remote HTTP MCP servers: handshake OK but tools never exposed in desktop conversations (regression in 26.803.61601/81509) #37976

Powered by Codex Action

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

Remote HTTP MCP servers: handshake OK but tools never exposed in desktop conversations (regression in 26.803.61601/81509) #37976

Powered by Codex Action

Not a duplicate. Issue #37976 relates to remote HTTP MCP servers, and the observed behaviour is different. This issue relates to local STDIO MCP servers.

+1. Same root cause on Windows with remote HTTP MCP servers (Lingxing/SellerSprite): handshake and tools/list succeed, but the tools are omitted from the Chat session catalog (omitting MCP server without an exact ready client). Also reproduces with a local stdio proxy; works on older versions and in Codex CLI. Notably, our model catalog already has "use_responses_lite": false, so #33679's workaround does not apply ? this is the startup race, not the Responses Lite path.

I was redirected here from the duplicate reports #40578 and #39555.

I am experiencing a related issue with a web-installed personal Skill on macOS, rather than a local MCP server.

The personal Skill appears under both “Installed” and “Created by me” in ChatGPT on the web and works correctly there. However, it does not appear under Plugins → Skills in the ChatGPT Mac app and cannot be selected through @ mentions.

Chats synchronize correctly between the web version and the Mac app, so the account and conversation synchronization work. Only the installed Skill capability is missing from the desktop Chat/Work interface.

Troubleshooting completed:

Confirmed that the same ChatGPT account is used
Fully quit and reopened the Mac app
Refreshed the Skills page
Uninstalled and reinstalled the Skill on the web
Verified that the Skill configuration is valid and supports ChatGPT

Mac app version: 26.901.20858
Platform: Darwin 25.1.0 arm64 arm
Subscription: ChatGPT Pro
Skill: microlearning-forklaring

Feedback ID:
no-active-thread-01a06b24-6ec3-7541-8790-bb38a8a10512

Is there a supported way to force the desktop app to refresh or reconcile account-installed personal Skills?

I can reproduce this on Windows with a completely different local MCP server (OriginPro integration), including a Streamable HTTP control path.

Environment / observations:

Codex Desktop on Windows, current app after updating on 2026-09-04
ChatGPT Plus
MCP server: local origin-mcp driving OriginPro 2026 through a localhost bridge
Desktop Settings shows the MCP enabled
Local bridge health checks pass (Bridge: reachable, Origin: reachable)
For the Streamable HTTP variant (origin_http via localhost proxy), Codex Desktop logs show repeated server=origin_http status=ready
Despite that, a brand-new Desktop chat reports that origin_http is not available / not provided to the current session, and no MCP tool is callable
The same config is present in ~/.codex/config.toml
Process inspection confirms Codex is launching the configured MCP process

I also tested a direct stdio variant. That path fails earlier with MCP client for "origin" failed to start: handshaking with MCP server failed: connection closed: initialize response; however, the HTTP path reaches status=ready, so this separate HTTP reproduction strongly supports a Desktop post-discovery/session tool-exposure problem matching this issue.

Expected: once the HTTP MCP reaches status=ready, its tools should be attached to a fresh Desktop chat session, or the UI/logs should expose the reason they are not.

This is blocking use of a healthy local scientific-software MCP integration on Windows.

I’m seeing the same failure mode on macOS Desktop 26.908.70816 with a different local stdio MCP.

I inserted a transparent stdio proxy in front of the MCP and confirmed:

child launches successfully
initialize succeeds with MCP protocol 2025-06-18
Desktop sends notifications/initialized
Desktop sends tools/list
server returns a non-empty valid tool inventory
Desktop continues with resources/list
despite successful discovery, none of the MCP tools are exposed to the Chat session

I also reproduced the user-visible symptom with a second local MCP.

One additional observation: I configured an explicit working directory, but the child reports cwd=.. (This does not prevent MCP initialization/tool discovery, so it may be unrelated.)

Sanitized wire excerpt:

[CLIENT -> SERVER]
{"jsonrpc":"2.0","id":0,"method":"initialize",
 "params":{
   "protocolVersion":"2025-06-18",
   "capabilities":{"elicitation":{"form":{},"url":{}}},
   "clientInfo":{"name":"codex-mcp-client","title":"Codex","version":"0.154.0-alpha.6.2"}
 }}

SERVER STDERR:
MCP Server running on stdio

[SERVER -> CLIENT]
{"jsonrpc":"2.0","id":0,
 "result":{
   "protocolVersion":"2025-06-18",
   "capabilities":{"tools":{},"resources":{}},
   "serverInfo":{"name":"REDACTED","version":"REDACTED"}
 }}

[CLIENT -> SERVER]
{"jsonrpc":"2.0","method":"notifications/initialized"}

[CLIENT -> SERVER]
{"jsonrpc":"2.0","id":1,"method":"tools/list",
 "params":{"_meta":{"progressToken":0}}
}

[SERVER -> CLIENT]
{"jsonrpc":"2.0","id":1,
 "result":{
   "tools":[
     {"name":"tool_1","description":"REDACTED","inputSchema":{"type":"object","properties":{}}},
     {"name":"tool_2","description":"REDACTED","inputSchema":{"type":"object","properties":{}}},
     "... additional tools omitted ..."
   ]
 }}

[CLIENT -> SERVER]
{"jsonrpc":"2.0","id":2,"method":"resources/list",
 "params":{"_meta":{"progressToken":1}}
}

[SERVER -> CLIENT]
{"jsonrpc":"2.0","id":2,"result":{"resources":[]}}

This differs from #45555 because Desktop successfully completes initialization and tool discovery here; the failure appears to be in the post-discovery tool-registration/exposure path.

I can reproduce a related Windows Desktop Chat failure with a third-party remote MCP connector (Remote Desktop Commander).

Environment:

Windows Codex/ChatGPT Desktop package 26.915.4065.0
Normal Chat surface
The connector/device remains online and healthy
Same Windows machine: Chrome web Chat can invoke the connector across consecutive user turns
Work can invoke the same connector across consecutive user turns
macOS Chat used the same connector reliably for several days

Reproduction:

Start a fresh normal Chat in Windows Desktop.
Mention the connector and request a simple command such as whoami.
The first tool invocation succeeds.
Send a second user message requesting another command, with or without mentioning the connector again.
No corresponding remote command executes on the device.

This is repeatable after creating new Chats, fully restarting the app, rebooting Windows, and using the Windows app Repair action.

The affected Desktop Chat log also contains:
chatgpt_completion_transport_recovery_started
with HTTP 404 / Resume stream unavailable.

Because the same connector continues to work in Chrome web Chat and Work on the same machine, this appears consistent with a Windows Desktop normal-Chat tool exposure/rehydration failure across the completed assistant-response -> next-user-turn boundary, rather than an MCP-server, device, authorization, or connector-service failure.

Relevant community report: https://community.openai.com/t/custom-mcp-connector-disappears-after-successful-invocation-in-chrome-web-chat-and-desktop-chat-no-second-request-reaches-mcp-server/1392606

I can reproduce the same issue on macOS with eM Client's local STDIO MCP server.

Environment

macOS, Apple Silicon (arm64)
ChatGPT Desktop: 26.924.22138
ChatGPT Plus
eM Client: 11.0.473 (9e16cce)
MCP transport: STDIO
MCP protocol: 2025-06-18

MCP configuration

Command:

/Applications/eM Client.app/Contents/MacOS/eM Client

Arguments:

--mcp

--mcp-secret

<REDACTED>

The MCP server itself has been independently tested and works correctly.

Direct MCP testing confirms:

process startup: OK
MCP secret authentication: OK
STDIO communication: OK
initialize: OK
protocol negotiation (2025-06-18): OK
notifications/initialized: OK
tools/list: OK
non-empty tool inventory returned: OK

The returned tools include, among others:

ListEmailAccounts

ListEmailFolders

SearchEmails

GetEmailData

SearchEmailConversations

GetConversationData

However, after completely restarting ChatGPT Desktop and opening a new Chat session, none of the eM Client MCP tools are exposed to the session.

When explicitly asking ChatGPT to use only the eM Client MCP (with Computer Use/screenshots/GUI interaction prohibited), ChatGPT reports that no eM Client MCP tool is available in the current session, while other connectors such as Gmail, Google Calendar, and Google Contacts are available.

Therefore my observed failure boundary is the same:

MCP discovery / tools/list: SUCCESS

Exposure of discovered MCP tools to Chat: FAILURE

The issue persists on ChatGPT Desktop 26.924.22138, so this appears to still be reproducible in a newer Desktop build.

One additional eM Client-specific finding: in a restricted environment, eM Client MCP requires the macOS user TMPDIR; without it, its internal MailClient MCP transport times out. Supplying TMPDIR resolves that separate startup issue, but does not resolve the ChatGPT Desktop tool-exposure problem.

The actual MCP secret has been redacted.

Adding another Windows reproduction, with a useful A/B control between normal Chat and Work using the same private personal plugin and the same local stdio MCP server.

Environment

ChatGPT Plus
Windows Desktop app
Private personal plugin backed by a local stdio MCP process
MCP protocol: 2025-06-18
Server advertises 5 read-only tools, including a zero-argument health-check tool
Server is launched locally through PowerShell -> Python

I am intentionally omitting the plugin name, local paths, database/service names and account identifiers because this MCP connects to an internal business system.

Normal Chat: discovery succeeds, tool is never called

In a brand-new normal Chat, I explicitly selected the plugin via @ and asked ChatGPT to execute the health-check tool.

Wire-level capture shows:

Desktop launches the local MCP process
initialize succeeds
notifications/initialized is sent
tools/list succeeds and returns all 5 tools
resources/list / resources/templates/list are queried normally
No tools/call is ever emitted

The relevant client info reported during this failing Chat path is:

clientInfo.name    = codex-mcp-client
clientInfo.version = 0.159.0-alpha.12.1

So the MCP server is alive and its tools are discovered successfully, but the Chat session behaves as though those tools are not available to the model.

Work: same plugin + same MCP works

Using Work on the same machine, with the same plugin and the same MCP server, I requested the exact same health check.

Wire-level capture shows:

initialize succeeds
tools/list returns the same 5 tools
Desktop emits an actual tools/call
The health-check tool executes successfully and returns a valid result

The client info on the working Work path is:

clientInfo.name    = codex-mcp-client
clientInfo.version = 0.160.0

The successful call also contains metadata identifying the client as desktop_app.

Why this seems useful

This gives a direct control case where the following are identical:

Windows machine
ChatGPT account
personal plugin
local command / stdio transport
MCP server implementation
MCP protocol version
advertised tool schemas
downstream service

The variable is the surface/runtime:

Normal Chat -> initialize OK -> tools/list OK -> no tools/call
Work        -> initialize OK -> tools/list OK -> tools/call OK -> backend OK

The different MCP client versions (0.159.0-alpha.12.1 in normal Chat vs 0.160.0 in Work) may also be relevant. At minimum, this appears to rule out the MCP server, stdio transport and downstream service, and points to the normal-Chat tool registration/exposure path.

I can provide a further redacted wire capture if it would help diagnose the issue.

Fedora/Linux reproduction: selected personal plugin, healthy installed stdio MCP, but both tools absent from Chat (2026-10-08)

I am adding a detailed Linux/Fedora reproduction to this existing issue rather than opening a duplicate. The affected local assistant is named JARVIS. I have removed user paths, session IDs, access tokens, device identifiers, and private logs.

Environment

Fedora Linux, x86_64, GNOME Desktop.
Codex CLI 0.156.1 (confirmed locally). The separate ChatGPT Desktop bundle/About version has not been verified; do not infer it from the CLI version.
ChatGPT Plus.
Personal plugin jarvis-direct v0.1.1, visible under Plugins and explicitly selected using an @jarvis-direct plugin link before sending the request.
MCP server name jarvis, transport stdio; plugin manifest declares a relative executable launcher and working directory:

{
  "mcpServers": {
    "jarvis": {
      "type": "stdio",
      "command": "./bin/jarvis-direct-mcp",
      "cwd": "./"
    }
  }
}

The local Python launcher enters Bubblewrap with --unshare-net / --unshare-pid, read-only runtime components, and a narrowly scoped local Unix operator socket. No HTTP/tunnel, paid provider or cloud inference.
Codex CLI MCP inventory shows jarvis enabled with the v0.1.1 launcher. Two independently cached copies of the installed v0.1.1 launcher are byte-identical.

Installed-path MCP protocol test (PASS) — explicitly not a Desktop wire capture

I launched the actual installed plugin entry point, using a bounded read-only JSON-RPC stdio client:

Test	Observed
MCP initialize	PASS
Protocol	2025-11-25
notifications/initialized	sent
MCP tools/list	PASS
Advertised tools	exactly jarvis_run_goal and jarvis_cancel_goal
Launcher child exit	0
Local Unix operator socket	same inode before/after; mode 0600
TCP listener before/after samples	both valid; zero new listeners observed
MCP tools/call	never sent
Goal, cancellation, filesystem mutation, or service restart	none

This confirms local installed-launcher execution, MCP framing, negotiation and tool discovery. It does not yet establish that Desktop itself initiated the successful MCP handshake on the failing turn, since the wire test was an independent installed-path probe rather than an intercept of Desktop traffic. I want to avoid overstating that boundary.

ChatGPT Desktop reproduction (HOLD)

Confirm the actual plugin jarvis-direct appears in the ChatGPT Desktop Plugins menu, with its local-Fedora-operator description.
Create a fresh project-backed Chat, explicitly select the plugin via the UI/@ plugin link, and ask: “Check whether jarvis_run_goal and jarvis_cancel_goal are actually available; do not execute any actions.”
The Chat model's available tool catalog contains neither of the two tools. No tool call is made. The answer correctly returns HOLD.
Repeat in a new ordinary Chat outside the project, again with the plugin selected. Both tools remain absent.
The reproduction therefore is not limited to project-scoped chats, and this is not merely a literal typed plugin name: the UI recognizes the plugin selection.

Compact result:

Plugin visible: YES
Plugin explicitly selected via UI: YES
Codex CLI inventory: jarvis ENABLED
Installed stdio MCP initialize: PASS (independent probe)
Installed stdio MCP tools/list: jarvis_run_goal, jarvis_cancel_goal
Fresh project Chat: 0 of 2 tools exposed
Fresh normal Chat outside project: 0 of 2 tools exposed
Desktop-originated MCP protocol capture: NOT AVAILABLE
Actual goal or cancel operation: NEVER INVOKED

Expected vs. actual behavior

Expected: A selected and enabled personal plugin either exposes its MCP tools to the current chat's callable catalog, or reports a specific startup/readiness/permission failure.

Actual: The plugin is visible and selected, but the model cannot access its declared actions, despite the independent installed-path MCP test and enabled CLI registry being healthy. This blocks a real use case without any useful Desktop error or actionable diagnostic.

What maintainers could investigate

Please clarify which step can drop a selected plugin's stdio tools in the Desktop Chat path, separately from the working CLI and installed-path probe:

Plugin selection to effective Desktop MCP server configuration (does Desktop actually launch the intended server?).
MCP client readiness and startup timing in Desktop, versus tool binding capture on the first turn.
Whether the selected plugin server is treated as optional, omitted before an exact ready client exists, and never re-bound.
Whether tools/list succeeds inside Desktop but post-discovery registration / per-thread dynamic tool catalog silently omits the tools.
Any app capability gate, approval setting, or transport-specific tool-surface restriction relevant to Linux + personal plugin + stdio.
Whether a verified fix, specific supported build, or supported non-HTTP workaround exists.

Related issues: #38342 (optional MCP startup/catalog consistency), #19425 (post-discovery tool exposure), #26659 (stdio CLI-vs-Desktop distinction). These are similar reports; a common internal cause has not been proven for this Fedora case.

I would appreciate the minimal privacy-safe Desktop-side event sequence needed to distinguish “not launched”, “launched but pending”, “list returned but not registered”, and “registered but not exposed to this chat”, or a known fixed build. Please avoid recommending an HTTP tunnel or disabling sandbox restrictions: those defeat the security properties of this local-only assistant.

Final status: installed stdio protocol PASS; selected Chat plugin tool admission HOLD; goal end-to-end NOT TESTED; no secrets disclosed, no paid external inference, no unsafe fallback or runtime configuration changes.

Additional reproduction on Linux — ChatGPT Desktop 26.1007.21434

I can reproduce a closely related issue on Omarchy Linux (Wayland/Hyprland) using a private local plugin for an existing STDIO MCP server.

Environment

ChatGPT Desktop: 26.1007.21434
Linux x86_64, Omarchy / Wayland
ChatGPT Plus
Private plugin: herdr-read-only@local-private, v0.1.1
Python 3, STDIO MCP; server reports herdr-readonly v1.0.0
MCP protocol version: 2025-11-25
Tools: herdr_status, herdr_result (both read-only)

Successful control tests

MCP Inspector completed initialize and tools/list, returning exactly those two tools.
Codex CLI invoked herdr_read_only.herdr_status successfully (isError: false) and received a real agent-status result.
A separate Codex app-server process returned both tools through mcpServerStatus/list with toolsError: null.
codex plugin list confirmed the private plugin was installed and enabled; portable plugin.json/mcp.json and additional compatibility .codex-plugin/plugin.json/.mcp.json were tried.

Desktop failure

After fully quitting and restarting ChatGPT Desktop, I opened a fresh conversation, selected @Herdr Read Only, and requested a direct herdr_status invocation. The conversation reported an empty tool lookup ([]); it did not invoke the MCP tool or receive any response.

Additional diagnostic observation

With the global MCP registration disabled only for a temporary app-server test, while enabling the plugin MCP override, mcpServerStatus/list returned:

{
  "name": "herdr_read_only",
  "pluginId": null,
  "serverInfo": null,
  "tools": {},
  "toolsError": null
}

This suggests that the tools discovered in the separate control app-server process may have come from the global MCP registration, not the plugin-specific registration. An attempted isolated-plugin test did not discover its temporary plugin, so that test was inconclusive.

Qualification: Unlike the Windows report, I have not captured MCP wire traffic or inspected the actual tool registry from the failing Desktop conversation process. Successful discovery is confirmed in MCP Inspector, Codex CLI, and a separate app-server process — not directly in the failing Desktop session.

Expected behavior

If private local STDIO plugin tools are supported in ordinary ChatGPT Desktop conversations, selecting the enabled plugin should make its discovered read-only tools callable.

Questions for maintainers

Are locally installed STDIO MCP plugin tools supported in ordinary ChatGPT Desktop conversations on Linux?
Is any additional authorization or tool-exposure step needed after installation/enablement?
Is there a supported diagnostic API to inspect the actual tool registry exposed to a Desktop conversation?

This resembles the issue reported here, with the additional Linux reproduction and a successful Codex CLI invocation.

Follow-up: Work succeeds outside a ChatGPT Project, but does not invoke the local MCP inside a Project (2026-10-12)

This is a follow-up to my earlier Windows reproduction in this comment. I now have a second, more narrowly isolated contrast with Work itself.

Environment / unchanged control

ChatGPT Desktop on Windows, ChatGPT Plus.
Same installed private personal plugin (v0.1.1) and same local stdio MCP server (PowerShell launcher -> Python); no MCP code, transport, schema, or backend changes between the two tests.
Server advertises five read-only tools, including a no-argument health check.
MCP protocol 2025-06-18.

A. Work conversation outside a ChatGPT Project — PASS

On 2026-10-12 at 09:41 local time, the stdio capture records actual tools/call requests for the health-check tool and a table-description tool. The request metadata identifies:

client_type    = desktop_app
source         = codex
workspace_kind = projectless
codex_version  = 0.162.0-alpha.17.2

This is a successful positive control: the same Desktop installation can expose and invoke the local MCP tools in Work.

B. Work conversation inside a ChatGPT Project — FAIL

For the in-Project Work test, I saved the current line count of the local MCP wire log, sent the health-check request in the Project's Work conversation, waited for the response, and checked all lines appended since that baseline.

Result: zero additional MCP log lines. In particular, no new tools/call arrived at the local stdio server. Unlike the earlier normal-Chat reproduction, this Project reproduction did not even record a fresh initialize or tools/list exchange during the measured interval.

The zero-new-traffic observation does not by itself establish whether the Project runtime omitted MCP attachment, reused an existing session without issuing a call, or was blocked earlier in tool exposure. It does establish that the user's request never reached this local MCP server.

Expected: A Work conversation inside a ChatGPT Project should have access to the same installed local plugin/MCP tools as a Work conversation outside a Project, or the UI should explicitly identify any unsupported limitation.

Observed:

Work outside Project -> tools/call observed -> health check succeeds
Work inside Project  -> no new MCP wire traffic -> health check unavailable

Can the maintainers confirm whether local stdio MCP plugins are supported in Work conversations within ChatGPT Projects? If supported, this looks like a Project-scoped plugin/tool attachment or exposure regression. I can provide a redacted, tightly scoped A/B trace if useful.

As before, plugin names, local paths, user/session IDs, database identities and business data are deliberately omitted.

I found a practical workaround for this class of failure on Linux / ChatGPT Plus, where a locally installed MCP plugin was visible to the product UI/local plugin catalog but its tools were not exposed to an ordinary Chat session.

Observed failure:

The local plugin was installed and its tool schema/catalog was present locally.
Chat could recognize the plugin reference, but the MCP tool namespace itself was absent from the session, so calls could not be made.
Re-opening/fresh chats did not make the local tool surface appear.

Workaround that succeeded:

Create/use an OpenAI Secure MCP Tunnel for the same MCP server.
In ChatGPT, go to Settings → Plugins → Add custom MCP server.
Choose Tunnel and select/enter the Secure MCP Tunnel.
Finish creating the plugin.
Start a fresh ordinary Chat with that tunnel-backed plugin available.

After doing this, the MCP tools were actually exposed to the Chat session and a read-only stat_path tool invocation succeeded. The local server/tool implementation did not need to be changed; the material change was registering it through the ChatGPT custom-MCP/tunnel path rather than relying on the locally installed plugin's tool exposure.

So, for users who can accept a Secure MCP Tunnel, this appears to be a viable workaround for the post-discovery / session-tool-exposure failure. It is not equivalent for users who specifically require a local-only stdio security boundary, but it may also help narrow the bug: the same MCP functionality becomes callable when admitted through the tunnel-backed ChatGPT plugin path.

Additional Windows Codex Desktop observation, submitted with the affected user's authorization on October 18, 2026 (Asia/Shanghai).

This is a related tool-exposure symptom in Codex Desktop, not a claim that it has the same cause as the ChatGPT Desktop reports in this issue.

Observed versions: Desktop 26.1013.4894.0, bundled CLI 0.163.0-alpha.10.2. The existing conversation is a local Codex conversation with no project membership. We need to preserve that conversation and its history.

A separate portable-plugin packaging defect was identified and corrected first. The old manifest used an absolute Windows executable command. A bounded public app-server plugin/read comparison returned mcpServers:[] for that package, while the revision changing only the command to bare node and the package version retained its one server. The corrected package revision is 0.1.1; the server implementation and UI were unchanged.

The correction was installed through the supported CLI marketplace/plugin commands. Official plugin list confirms the corrected version is installed and enabled, and the installed files match the frozen package. A separate bounded public app-server mcpServerStatus/list call, without threadId and filtered to the single target, then initialized and discovered the one expected tool. The returned pluginId exactly matched the installed plugin, toolsError was null, and the control process exited normally. No model, conversation, or business-tool methods were called in that discovery control.

After the update, the existing Desktop conversation's active turn completed. We checked the available tool catalog once in the NEXT turn of the SAME conversation: the target tool namespace/tool is still absent. No replacement conversation, additional application restart, security-setting change, private host RPC, or fallback transport was used. The actual Desktop-owned conversation's MCP startup/discovery and UI mounting have not been proven.

Could maintainers identify the supported way to inspect the actual existing Desktop conversation's plugin-admission, executable-launch, and tool-catalog errors, and activate the corrected local plugin while preserving that conversation? In particular, how can we distinguish a stale conversation catalog from a Desktop-host executable/environment or admission failure without changing permissions or restarting repeatedly?

The independent app-server discovery above does not establish that the Desktop-owned host discovered the tool, and we are not assuming that a separate app-server reload refreshes the Desktop host. We have not applied the tunnel/new-chat workaround suggested by another user.

Local paths, conversation/request IDs, actual plugin identifiers, UI tokens, authentication material, business content, and raw logs are omitted.

Update on October 18, 2026 (Asia/Shanghai): there is now a useful contrast within the same Desktop installation. A second already-existing local Codex conversation now advertises the expected tool in its real available-tool catalog. Ordinary Desktop startup records for that exact conversation also show the target server starting and becoming ready with no reported startup error. The original acceptance conversation still has zero matching tools in its actual catalog. We did not create a replacement conversation or perform another installation/restart for this contrast. The UI/message proof tool was not invoked in the other conversation, so this is not a UI-rendering or message-delivery pass. This narrows the remaining observation to differing tool exposure between existing conversations; it does not establish whether refresh, configuration/admission, or another cause explains the difference.

Technical clarification for maintainers: the matching public CLI-tag implementation exposes config/mcpServer/reload, but its refresh iterates only the receiving app-server's own loaded threads and marks their MCP runtime dirty/prewarms them (mcp_refresh.rs, config_refresh.rs). We found no exposed official tool that routes this request to the Desktop-owned host. Is there a supported Desktop entry for that same-host reload, or an official diagnostic that reports why this particular existing conversation has not admitted the corrected plugin? We have not sent this RPC to an independent process as a substitute, changed configuration to force a refresh, or tried archive/resume resets.

Windows 11, ChatGPT desktop 26.1013.40934 (released Oct 16), Codex CLI 0.162.1, ChatGPT Plus

Same failure mode as above, but with a clear workaround: local MCP tools are exposed in Work but not in Chat.

Local Streamable HTTP MCP server (url = "http://127.0.0.1:<port>/mcp" in ~/.codex/config.toml).
Server is healthy: a direct initialize POST returns a valid result, and codex mcp list / codex exec "list your MCP tools" in Codex CLI list its tools and work.
In the desktop app's Chat tab, the model reports the server is "not exposed to this session." This happened both with a stdio bridge (npx mcp-remote) and with the native url = entry.
In the Work tab of the same app, with the same config, the tools are listed and callable (health check, list, search, retrieve all return results).

Config when it worked in Work: native url = entry, startup_timeout_sec = 90, tool_timeout_sec = 180, required = true, top-level mcp_optional_startup_grace_ms = 15000. I have not isolated which of these settings matter. This doesn't change Chat, which still doesn't expose the tools.

This matches the Windows report above that a connector works in Work but not in normal Chat. It suggests the bug is in the Chat tool-registration path, not MCP discovery. Using Work (or Codex) is a workaround for now.

Navigation Menu

Repository navigation

ChatGPT Desktop: local MCP tools are discovered successfully but not exposed to Chat sessions #38162

What version of the Codex App are you using (From “About Codex” dialog)?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Control test

MCP server details

Desktop/app-server observations

Attachment glossary

codex-desktop-redacted-20260812-190756.log

ChatGPT Desktop MCP shim capture.zip

Codex CLI MCP shim capture.zip

Summary

Environment

Normal Chat: discovery succeeds, tool is never called

Work: same plugin + same MCP works

Why this seems useful

Fedora/Linux reproduction: selected personal plugin, healthy installed stdio MCP, but both tools absent from Chat (2026-10-08)

Environment

Installed-path MCP protocol test (PASS) — explicitly not a Desktop wire capture

ChatGPT Desktop reproduction (HOLD)

Expected vs. actual behavior

What maintainers could investigate

Additional reproduction on Linux — ChatGPT Desktop 26.1007.21434

Follow-up: Work succeeds outside a ChatGPT Project, but does not invoke the local MCP inside a Project (2026-10-12)

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

ChatGPT Desktop: local MCP tools are discovered successfully but not exposed to Chat sessions #38162

Description

What version of the Codex App are you using (From “About Codex” dialog)?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Control test

MCP server details

Desktop/app-server observations

Attachment glossary

codex-desktop-redacted-20260812-190756.log

ChatGPT Desktop MCP shim capture.zip

Codex CLI MCP shim capture.zip

Summary

Activity

github-actions commented on Aug 12, 2026

brad8898 commented on Aug 12, 2026

wanou2c commented on Aug 13, 2026

peterjak-arch commented on Sep 4, 2026

xmu-zhehenboheli commented on Sep 4, 2026

eddyg commented on Sep 16, 2026

ndsmansyj commented on Sep 22, 2026

jidem commented on Sep 27, 2026

Proginji2000 commented on Oct 5, 2026

Environment

Normal Chat: discovery succeeds, tool is never called

Work: same plugin + same MCP works

Why this seems useful

Devilazz commented on Oct 8, 2026

Fedora/Linux reproduction: selected personal plugin, healthy installed stdio MCP, but both tools absent from Chat (2026-10-08)

Environment

Installed-path MCP protocol test (PASS) — explicitly not a Desktop wire capture

ChatGPT Desktop reproduction (HOLD)

Expected vs. actual behavior

What maintainers could investigate

Fusenbach commented on Oct 10, 2026

Additional reproduction on Linux — ChatGPT Desktop 26.1007.21434

Proginji2000 commented on Oct 12, 2026

Follow-up: Work succeeds outside a ChatGPT Project, but does not invoke the local MCP inside a Project (2026-10-12)

zplitzcreen commented on Oct 17, 2026

li948872431-prog commented on Oct 17, 2026

HillsCloud commented on Oct 19, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions