Custom MCP tools are not exposed to Desktop threads despite successful discovery.
Custom MCP tools are not exposed to Desktop threads despite successful discovery.
Problem statement normalized from the linked evidence
CANDIDATE VIEW · NOT A PUBLISHED OPPORTUNITY
01
Qualification checklist
Gate decision: Aug 15, 2026
×
At least 3 independent users2 / 3
NOT MET
×
At least 2 independent discussions1 / 2
NOT MET
✓
At least 1 supporting signalPersistence
MET
02
Observed signals
Users2
Discussions1
Mentions2
Active days2
Source coverageGitHub
TrendUNKNOWN
First seenApr 24, 2026
Last seenJul 16, 2026
Why the gate is holding
Fewer than 3 independent users
Fewer than 2 independent discussions
Competition research, commercial scoring, and Build Gap analysis do not run until this gate passes.
03
Source evidence
2 evidence records
github · HIGH · Jul 16, 2026
openai/codex
### Additional reproduction: Windows / Streamable HTTP / Codex Desktop 0.144.5 I can reproduce this with a custom Streamable HTTP MCP server for a game I am developing. The server exposes resources and three tools for observing and controlling the running application. The failure does not appear to be game-specific: Codex successfully discovers the tools but does not expose them to the thread. Environment: - Windows - Codex Desktop client: 26.707.91948 - Codex runtime/session version: 0.144.5 - Model: gpt-5.6-sol -…
Custom stdio MCP server discovered by /mcp but tools not exposed to Desktop threads
## Summary Codex Desktop sees a custom stdio MCP server and successfully discovers its tools via `tools/list`, but the tools are not exposed to Desktop threads or `tool_search`. This appears to be a regression or exposure-layer bug in Desktop/App Server `0.124.0-alpha.2`. ## Environment - Codex Desktop client: `26.422.21637` - Codex/App Server: `0.124.0-alpha.2` - Platform: macOS - Server type: custom stdio MCP server - Config location: project-scoped `.codex/config.toml` ## MCP config ```toml [mcp_servers.interdom…