Hyphenated MCP server names cause working servers to render as 'Tools: (none)'

Resolved 💬 4 comments Opened Mar 23, 2026 by CaliLuke Closed Mar 28, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

Codex can show Tools: (none) for a working MCP server if the configured MCP server name contains -.

This is not a transport failure and not a tools/list failure. The bug is in how Codex sanitizes fully-qualified MCP tool names and then later groups them back by server name for mcpServerStatus/list.

User-visible symptom

A configured server like:

  • autok-local

shows up in Codex as:

  • Status: enabled
  • Auth: OAuth
  • URL: http://localhost:8000/mcp
  • Tools: (none)

But the same server immediately works if the config key is renamed to:

  • autok_local

Root cause

In codex-rs/core/src/mcp_connection_manager.rs, qualify_tools() builds raw fully-qualified names like:

  • mcp__autok-local__browse_content

Then sanitize_responses_api_tool_name() replaces disallowed characters with _, producing:

  • mcp__autok_local__browse_content

Later, group_tools_by_server() in codex-rs/core/src/mcp/mod.rs splits the sanitized qualified key and reconstructs the server name as:

  • autok_local

Finally, mcpServerStatus/list in codex-rs/app-server/src/codex_message_processor.rs renders per-server status rows using the configured MCP server name from config, which is still:

  • autok-local

So the lookup misses and that server renders with no tools.

Why this is especially confusing

  • initialize succeeds
  • tools/list succeeds
  • the MCP server can be fully functional
  • official MCP SDK clients can list and call tools just fine
  • only Codex's inventory/status rendering drops the tools

This makes it look like the MCP server is broken even though the issue is the Codex-side regrouping path.

Minimal repro

  1. Configure an MCP server in Codex using a hyphenated name, for example:
  • autok-local
  1. Ensure the server returns a non-empty tools/list.
  2. Open the MCP server status view in Codex.
  3. Observe Tools: (none).
  4. Rename only the config key to autok_local.
  5. Restart/reload Codex.
  6. Observe the tools now appear.

Expected behavior

Codex should preserve the original MCP server name for grouping/rendering and should not reconstruct the server name from a sanitized fully-qualified tool key.

Actual behavior

Codex groups sanitized tool keys under autok_local while rendering the configured server row autok-local, so the tool list disappears.

Suggested fix

Avoid deriving the server name for status grouping from the sanitized fully-qualified tool key.

Instead, preserve the original configured/server-reported server name separately through the snapshot/status path and group/render against that canonical name.

Additional note

This also explains why some built-in or external MCP servers appear unaffected:

  • names like figma and linear have no -, so sanitization does not change the grouping key.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 5 months ago

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

  • #14927

Powered by Codex Action

SproutSeeds · 5 months ago

I took a local-first pass on current main, and the hyphenated-name bug is reproducible in both status surfaces, not just one.

Exact results:

  • cargo test -p codex-core group_tools_by_known_server_names passed
  • cargo test -p codex-app-server mcp_server_status passed
  • INSTA_UPDATE=always cargo test -p codex-tui mcp_tools_output_ passed

What that narrowed:

  • qualify_tools() sanitizes a raw key like mcp__autok-local__browse_content into mcp__autok_local__browse_content
  • mcpServerStatus/list then regroups from the sanitized key, so the configured row autok-local misses its tools
  • TUI /mcp had the same failure shape through prefix matching on the unsanitized configured server name

The narrow fix I could support was a shared regrouping helper that maps sanitized tool keys back to canonical configured server names when that mapping is unique. That fixed both the app-server status path and the TUI /mcp path without widening the protocol shape.

If two configured server names collapse to the same sanitized key, for example autok-local and autok_local, the canonical identity is no longer perfectly recoverable from the flattened tool key alone. The local helper falls back in that case instead of guessing.

Current main has a real MCP hyphenated-name regrouping bug across both app-server and TUI, and a narrow shared-helper fix is enough for the common unique-name case.

If that direction sounds right, I can turn the local patch into a small PR.

mle-foo · 5 months ago

Opened draft PR #15797 for this fix: https://github.com/openai/codex/pull/15797

etraut-openai contributor · 5 months ago

This appears to be a duplicate of #15832.

This PR addresses this issue. It will be included in the next release.