Custom stdio MCP server discovered by /mcp but tools not exposed to Desktop threads

[arbenl]

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

[mcp_servers.interdomestik_qa]
command = "/bin/bash"
args = ["scripts/start-repo-qa.sh"]
cwd = "."

The wrapper script resolves the repo root, changes into it, and starts a TypeScript MCP server over stdio.

Expected behavior

The following custom MCP tools should be exposed to Desktop threads and callable via names like mcp__interdomestik_qa__project_map:

• project_map
• read_files
• code_search
• check_health
• pr_verify
• security_guard
• e2e_gate

Actual behavior

• Desktop /mcp shows the server enabled.
• codex mcp list --json shows the server enabled.
• Repo preflight passes, including live MCP tools/list discovery.
• Desktop logs show the server starts and returns a ListToolsResult containing the expected custom QA tools.
• tool_search returns 0 callable interdomestik_qa tools.
• Thread request payloads do not include any mcp__interdomestik_qa__* tools.
• The current thread's thread_dynamic_tools only contains generic Desktop tools such as automation_update, read_thread_terminal, load_workspace_dependencies, and install_workspace_dependencies.

Evidence collected locally

Manual/repo preflight confirms live MCP discovery works:

pnpm mcp:preflight

Desktop logs show the custom server is started and queried successfully:

• custom QA server starts on stdio
• client initializes against the server
• ListToolsRequest is sent
• ListToolsResult is received with the expected custom tools

But those discovered tools are not present in the thread/deferred tool surface.

Historical comparison from local Codex state/logs:

• An Apr 20 thread on Codex 0.91.0 successfully called tools such as:
  • mcp__interdomestik_qa__read_files
  • mcp__interdomestik_qa__code_search
  • mcp__interdomestik_qa__project_map
• Apr 24 threads on Codex 0.124.0-alpha.2 do not expose those tools, despite successful /mcp discovery.

I also checked whether stale Desktop workspace state was the cause. The active workspace root and thread cwd both point to the correct repo, but the custom MCP tools are still not exposed.

Suspected failure point

The failure appears to be after successful MCP tools/list discovery and before Desktop registers/indexes those tools into the per-thread/deferred tool surface.

It does not appear to be caused by the MCP server implementation, stdio transport, project config, or CLI discovery, because live tools/list discovery succeeds outside the Desktop thread tool surface.

[github-actions]

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

• Codex Desktop for Windows does not load local MCP plugin tools #19304
• codex exec session schema does not expose MCP tools even though codex mcp list shows server enabled #17904
• Desktop thread can omit configured remote OAuth MCP server from mounted tools with no auth prompt or error #18527
• MCP servers disappear from session when using a custom provider #19363

Powered by Codex Action

[arbenl]

Update after full Codex Desktop restart:

Outcome is still: Discovery works, exposure still fails.

Fresh thread details:

• cwd: /Users/arbenlila/development/interdomestik-crystal-home
• current thread id: 019dc0ed-8043-78b1-badb-e1a5aa5e6f02
• tool_search for expected QA tools returned 0 tools, both initially and after rechecking.
• codex mcp list --json shows interdomestik_qa enabled.
• pnpm mcp:preflight passed, including live tools/list discovery.
• thread_dynamic_tools for the current thread contains only:
  • automation_update
  • read_thread_terminal
  • load_workspace_dependencies
  • install_workspace_dependencies
• thread_dynamic_tools contains 0 interdomestik_qa, project_map, read_files, or code_search entries.
• Recent Desktop logs show the stdio server started and initialized as interdomestik-qa version 1.0.0.
• Recent logs show ListToolsResult for this same thread containing the expected QA tool names.
• Only MCP warnings found were unsupported resources/resource templates methods, not tools/list failure.

Versions after restart:

• codex --version: codex-cli 0.124.0
• current thread cli_version: 0.125.0-alpha.3
• Desktop client: Codex.app 26.422.30944, build 2080

Most precise failure boundary:

Desktop/RMCP can start interdomestik_qa and receive ListToolsResult, but those tools are not persisted/indexed into the current thread's callable dynamic tools, so tool_search exposes none of them.

[arbenl]

Reviewed the potential duplicates suggested by the bot. I do not think this is an exact duplicate, though it is likely related to the same MCP exposure/indexing area.

Comparison:

• Codex Desktop for Windows does not load local MCP plugin tools #19304 is the closest symptom match, but it is Windows + local MCP plugin packaging. This issue is macOS + project-scoped stdio MCP config, and the important extra evidence is that Desktop logs show ListToolsResult for the same current thread containing the expected tool names, while thread_dynamic_tools still contains no custom MCP entries.
• codex exec session schema does not expose MCP tools even though codex mcp list shows server enabled #17904 is about codex exec session schema. This issue is Desktop thread/tool_search exposure.
• Desktop thread can omit configured remote OAuth MCP server from mounted tools with no auth prompt or error #18527 is remote HTTP OAuth MCP/auth handoff. This issue is local stdio MCP with successful initialization and tools/list, so OAuth is not involved.
• MCP servers disappear from session when using a custom provider #19363 is custom model provider behavior. This issue uses the normal Desktop/App path, not a custom provider.

So the narrower failure here remains: Desktop/RMCP successfully starts the stdio server and receives ListToolsResult, but the discovered tools are not persisted/indexed into the thread's callable dynamic tools.

[arbenl]

Additional cross-client comparison from the same local repo/machine:

Gemini/Antigravity is able to mount and use MCP tools successfully in this repo context. Verified working there:

• mcp-context-server/project_map
• mcp-context-server/read_files
• context7/resolve-library-id
• playwright/browser_tabs
• e2e-test-generator/generate_basic_test

This further suggests the MCP server/environment is not the root problem. Other MCP clients can index and call repo/context/playwright-style MCP tools on the same machine, while Codex Desktop still discovers interdomestik_qa via tools/list but does not expose the tools to the thread/tool_search surface.

One separate note: Gemini's repo-qa wrapper hit a JSON parsing/encoding issue (invalid character 'â') for some QA commands, which looks like command-output formatting inside that wrapper. That is distinct from this Codex issue, where the tools are not mounted at all despite successful ListToolsResult discovery.

[arbenl]

Additional related issue with a useful version boundary: #19649

That report describes the same core failure class: MCP servers are registered and visible via codex mcp list / codex mcp get, but their tools are not injected into Codex threads.

Important detail from #19649:

• known working: codex-cli 0.120.0
• broken: codex-cli 0.122.0-alpha.13 and later
• same config works again after downgrading to 0.120.0

That lines up with this Desktop report:

• older Interdomestik thread on 0.91.0 had usable mcp__interdomestik_qa__... calls
• current Desktop/App runtimes around 0.124.x / 0.125.x discover tools/list but do not expose the tools to tool_search / thread_dynamic_tools

So this issue may be the Desktop/app-server manifestation of the same regression family as #19649. This issue still adds Desktop-specific evidence: the logs show ListToolsResult for the same current thread, while thread_dynamic_tools remains missing the discovered MCP tools.

[rnett]

This may be #20574, are you using a custom or older model?