GitHub Issue: Newly Configured Stdio MCP Server Listed By codex mcp But Not Admitted To Assistant Tool Manifest

Title

Newly configured stdio MCP server is enabled in codex mcp list/get but absent from assistant tool manifest

Body

Summary

A minimal local stdio MCP server is configured and visible to the Codex CLI via codex mcp list and codex mcp get, but its tool is not exposed to the assistant tool manifest. Other MCP servers in the same Codex session, such as context-mode and ctk, are visible through tool discovery.

This looks like a Codex host/tool-manifest admission mismatch rather than an MCP server protocol issue.

Environment

• OS: Windows
• Codex CLI: codex-cli 0.128.0
• MCP transport: stdio
• Server name tested: ruflomin
• Tool allow list: enabled_tools = ["ping"]

Current MCP State

codex mcp list shows:

Name          Command                                              Args                                                                                   Env  Cwd                                                                   Status   Auth
context-mode  C:\Users\SNCom\AppData\Roaming\npm\context-mode.cmd  -                                                                                      -    -                                                                     enabled  Unsupported
ctk           C:\Users\SNCom\.ctk\ctk-mcp.cmd                      -                                                                                      -    -                                                                     enabled  Unsupported
ruflomin      node.exe                                             C:\Users\SNCom\Documents\Github Repo\PWE-Obsidian\OBComVault\99_TEMP\ruflo-min-mcp.js  -    C:\Users\SNCom\Documents\Github Repo\PWE-Obsidian\OBComVault\99_TEMP  enabled  Unsupported

codex mcp get ruflomin shows:

ruflomin
  enabled: true
  enabled_tools: ping
  transport: stdio
  command: node.exe
  args: C:\Users\SNCom\Documents\Github Repo\PWE-Obsidian\OBComVault\99_TEMP\ruflo-min-mcp.js
  cwd: C:\Users\SNCom\Documents\Github Repo\PWE-Obsidian\OBComVault\99_TEMP
  env: -
  startup_timeout_sec: 30
  remove: codex mcp remove ruflomin

Direct MCP Probe Passes

The same MCP server responds correctly when probed directly over stdio:

Content-Length: 164
{"jsonrpc":"2.0","id":1,"result":{"protocolVersion":"2024-11-05","serverInfo":{"name":"ruflomin","version":"1.0.0"},"capabilities":{"tools":{"listChanged":false}}}}

Content-Length: 209
{"jsonrpc":"2.0","id":2,"result":{"tools":[{"name":"ping","description":"Return pong from the minimal Ruflo compatibility shim.","inputSchema":{"type":"object","properties":{},"additionalProperties":false}}]}}

Content-Length: 77
{"jsonrpc":"2.0","id":3,"result":{"content":[{"type":"text","text":"pong"}]}}

Assistant Tool Discovery

Within the fresh Codex assistant session:

• Searching for context-mode ctx_stats finds tools.
• Searching for ctk search finds tools.
• Searching for ruflomin ping finds 0 tools.

So the session can discover some MCP-backed tools, but not the newly configured ruflomin server.

Isolation Already Tested

The following likely causes were tested and ruled out locally:

• Hyphenated server name: changed from ruflo-min to ruflomin.
• Server collision: removed prior ruflo and ruflo-min entries, leaving only ruflomin.
• Missing enabled_tools: enabled_tools = ["ping"] is present.
• ServerInfo mismatch: shim now reports serverInfo.name = "ruflomin".
• Invalid tool schema: tools/list includes an inputSchema.
• Missing tool execution: tools/call for ping returns pong.
• Global MCP failure: context-mode and ctk are visible in the same session.

Expected Behavior

If codex mcp list/get shows a stdio MCP server as enabled, the server handshakes successfully, and enabled_tools includes ping, the assistant session should receive a callable tool such as mcp__ruflomin__ping or otherwise expose the tool through the normal MCP tool discovery path.

Actual Behavior

The server is configured and direct-probe healthy, but the assistant tool manifest omits it. There is no clear local rejection reason surfaced to the user.

Question

Is there an additional admission, trust, manifest refresh, or policy gate for newly configured local MCP servers that is not documented in the MCP config reference? If so, what is the intended path to admit a newly configured stdio MCP server into the assistant callable tool catalog?

If this is unintended, the useful debugging target appears to be the Codex host/session tool-manifest admission path rather than the MCP server itself.

Local Evidence Bundle

Local report artifact:

50_OUTPUT/codex-mcp-admission-path-findings-2026-05-06.md

Related local finding:

CONFIGURED: PASS
DIRECT MCP HEALTH: PASS
SERVERINFO MATCH: PASS
COLLISION ISOLATION: PASS
ASSISTANT MANIFEST ADMISSION: FAIL
CALLABLE: NOT TESTED