›_ Codex Issues
Codex Issues / #26659

Custom STDIO MCP server enabled and tools/list works, but tools are not exposed in Codex Desktop thread

Open 💬 5 comments Opened Jun 5, 2026 by ilkerfatih44
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

Version 26.602.40724 • Released 5 Haz 2026

What subscription do you have?

Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

<img width="1920" height="1040" alt="Image" src="https://github.com/user-attachments/assets/acc68ce8-bb74-485f-b6b4-74f93f6717ae" />
<img width="1920" height="1040" alt="Image" src="https://github.com/user-attachments/assets/25b0b545-d5a5-436d-b3cd-286161d97b7e" />

A custom STDIO MCP server is enabled in Codex Desktop and works correctly at the MCP protocol level, but its tools are not exposed to the active Codex Desktop thread.

The MCP server appears enabled in Codex Desktop Settings → MCP servers. It also appears in /mcp as enabled.

Local protocol probe succeeds:

  • initialize: OK
  • serverInfo: kuponcu-context-mcp v0.2.0
  • tools/list returns 7 tools:
  • get_current_baseline
  • get_task_policy
  • get_forbidden_surfaces
  • get_validation_profile
  • search_project_sources
  • verify_hash_only
  • get_report_contract

However, inside a Codex Desktop thread opened in the correct workspace, tool_search cannot find any of these tools.

Relevant session evidence:

  • cwd: C:\Users\QQ\Desktop\altin-starter
  • originator: Codex Desktop
  • cli_version shown in logs: 0.137.0-alpha.4
  • The prompt asked Codex to check for these exact MCP tools:

get_current_baseline, get_task_policy, get_forbidden_surfaces, get_validation_profile, search_project_sources, verify_hash_only, get_report_contract

  • Codex performed a tool_search_call with these tool names.
  • tool_search_output returned:

tools: []

  • Final result:

MCP_TOOLS_NOT_VISIBLE

The issue is not that the MCP server is missing or failing to start. The server is enabled, visible in settings, and protocol-valid, but the active Codex thread does not expose its tools.

What steps can reproduce the bug?

  1. On Windows, create a custom STDIO MCP server and add it in Codex Desktop Settings → MCP servers.
  2. Configure it with:
  • command: C:\Users\QQ\Desktop\altin-starter\.venv\Scripts\python.exe
  • args:
  • -B
  • C:\Users\QQ\Desktop\altin-starter\mcp_servers\kuponcu_context_mcp\kuponcu_context_mcp\server.py
  • --repo-root
  • C:\Users\QQ\Desktop\altin-starter
  • --source-root
  • C:\Users\QQ\Desktop\kuponcu-context-sources\PR69_K1U_K1S_GA
  • cwd: C:\Users\QQ\Desktop\altin-starter
  1. Confirm the server is enabled in Codex Desktop Settings.
  2. Confirm /mcp shows the server as enabled.
  3. Verify locally outside Codex that the MCP protocol works:
  • initialize returns OK
  • tools/list returns 7 tools
  1. Open a Codex Desktop thread in the same workspace:

C:\Users\QQ\Desktop\altin-starter

  1. Ask Codex to check for the MCP tools:

get_current_baseline, get_task_policy, get_forbidden_surfaces, get_validation_profile, search_project_sources, verify_hash_only, get_report_contract

  1. Codex performs tool_search, but the result is an empty list:

tools: []

  1. The thread reports MCP_TOOLS_NOT_VISIBLE.

Session id from the failing run:
019e98f4-1731-79c2-a00d-62736bace39e

What is the expected behavior?

If a custom STDIO MCP server is enabled in Codex Desktop, visible in /mcp, and its local MCP protocol tools/list call succeeds, its tools should be exposed to the active Codex Desktop thread/tool registry.

Expected:

  • tool_search should find the custom MCP tools.
  • Codex should be able to call get_current_baseline and the other MCP tools.
  • If tools are intentionally not exposed, Codex Desktop should show a clear reason or error, such as unsupported transport, invalid schema, disabled tool list, workspace restriction, approval issue, or thread type incompatibility.

Actual:

  • The MCP server is enabled and protocol-valid.
  • /mcp shows the server as enabled.
  • Local tools/list returns 7 tools.
  • The Codex Desktop thread tool_search returns tools: [].
  • Codex reports MCP_TOOLS_NOT_VISIBLE.

Additional information

In Codex Desktop Settings → MCP servers, kuponcu-context-mcp appears under “Servers” and the toggle is enabled. Built-in/plugin MCP entries such as codex_apps and node_repl appear separately under plugins. Despite this, the active thread tool_search returns tools: [] for all custom MCP tool names.

No secrets, .env values, tokens, cookies, runtime_state contents, or private payloads are included in this report.

codex_mcp_issue_evidence_pack.zip

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 2 months ago

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

  • #25843
  • #26094
  • #26072
  • #26347

Powered by Codex Action

ilkerfatih44 · 2 months ago

Small correction to the reproduction section:

The command path should be:

C:\Users\QQ\Desktop\altin-starter\.venv\Scripts\python.exe
ilkerfatih44 · 2 months ago

Update: Streamable HTTP MCP works in the same Codex Desktop environment.

STDIO MCP result:

  • local initialize/tools-list: PASS
  • visible in /mcp: enabled
  • Codex Desktop thread tool exposure: FAIL (tools: [] / MCP_TOOLS_NOT_VISIBLE)

Streamable HTTP MCP result:

  • local HTTP initialize: PASS
  • local HTTP tools/list: PASS, 7 tools
  • visible in /mcp: enabled
  • Codex Desktop thread tool exposure: PASS
  • get_current_baseline was visible and callable from the thread
  • bounded smoke test also passed using:
  • get_task_policy
  • get_forbidden_surfaces
  • get_report_contract
  • search_project_sources

HTTP MCP URL:

http://127.0.0.1:8765/mcp
jixianyihao · 2 months ago

same problem

HaoYue1027 · 7 days ago

Additional reproduction — Desktop app-server 0.149.0 (MSIX 26.818.3698.0), Windows 11 build 26200; CLI 0.148.0 works with identical config

Adding another data point, consistent with #30343 and the original report.

Environment

  • OS: Windows 11, build 26200 (same as the original reporter)
  • Codex Desktop (ChatGPT desktop app): MSIX 26.818.3698.0; embedded app-server version string read from the installed codex.exe binary: 0.149.0
  • Codex CLI: v0.148.0
  • MCP server: custom local STDIO server (Python, mcp SDK 2.0.0), absolute-path venv launcher, reading a local Obsidian vault; configured in ~/.codex/config.toml as [mcp_servers.kika-obsidian] with enabled = true and default_tools_approval_mode = "auto"

Repro timeline

  1. codex mcp list -> server present, status enabled; codex mcp get kika-obsidian shows the full stdio config.
  2. Direct stdio protocol probe (fresh subprocess: initialize -> notifications/initialized -> tools/list): PASS. 17 tools returned; calling list_notes and search_notes returns real vault content.
  3. Codex Desktop thread (fresh sessions, twice): tools are not exposed - the thread tool registry has no MCP tools, while /mcp still lists the server as enabled.
  4. Control experiment, same machine and same config.toml: codex exec --skip-git-repo-check --sandbox read-only "list your MCP tools" -> PASS; the CLI session reports kika-obsidian with search_notes, get_note, list_notes callable.

Causal isolation

  • Same config file, same server binary, same vault, same OS session; the only difference is the client (Desktop thread vs CLI session).
  • The server is launched by an absolute path to a venv python.exe and does not depend on npx, node, or cmd resolution, so the Windows-PATH hypothesis from #30343 does not apply here.
  • Combined with the macOS/VS Code Streamable-HTTP reproduction in #30343, this looks like the Desktop/extension session layer failing to inject configured mcp_servers tools into the thread tool registry, not a server or environment issue.

Workaround note

  • In this thread (2026-06-05 comment) a contributor confirmed the same STDIO server exposed its tools when switched to Streamable HTTP. I have not verified this locally yet (my server is STDIO-only today), but it is the practical path for affected users.

Request

  • Expected: tools from enabled STDIO MCP servers are exposed in Desktop threads, same as CLI sessions.
  • Actual: tools: [] in Desktop thread tool search while the identical CLI session exposes and can call them.
  • Please fix Desktop thread MCP tool exposure, or document the limitation and supported transports for the Desktop app. Happy to run a debug build or provide more logs.