Windows Desktop: custom stdio MCP tools pass discovery but are not exposed to Codex task tool surface

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

26.715.31925

What subscription do you have?

Plus

What platform is your computer?

Microsoft Windows NT 10.0.19045.0 x64

What issue are you seeing?

````markdown

Summary

Codex Desktop shows a custom stdio MCP server as enabled, and the server passes
process-level MCP tools/list discovery, but the MCP tools are not exposed to
the current Codex task/tool_search.

This does not appear ArcRift-specific. It matches an existing class of Codex
Desktop MCP exposure/injection failures where MCP discovery succeeds but tools
are not available to the model/thread.

Related issues:

• #19425: custom stdio MCP server discovered/enabled, but tools not exposed to

Desktop threads/tool_search.

• #19649: MCP servers registered but tools not injected into Codex threads.
• #20771: closed as a duplicate of #19425 for the same general failure class.

If this should be handled as additional evidence for #19425 rather than a
separate issue, I am happy to move/close it as a duplicate.

Impact

Custom local MCP integrations can appear correctly enabled in Codex Desktop and
can pass direct tools/list discovery, while still being unusable from Codex
tasks. This can make users spend time debugging local server/config issues even
when the remaining failure boundary appears to be Desktop runtime tool-surface
injection.

Environment

• OS: Windows
• Codex Desktop version: 26.715.31925
• Server type: custom stdio MCP server
• MCP registration route: Codex Desktop Settings > Plugins > MCP
• Runtime: local Node.js stdio server
• Related local app: ArcRift v1.6.3 local runtime
• Local model/runtime dependency: Ollama on localhost

MCP server shape

The custom MCP server is an AOS read-only safe proxy in front of ArcRift.

Sanitized configuration shape:

name = "aos-arcrift-safe-proxy"
type = "stdio"
command = "<NODE_EXE>"
args = ["<AOS_WORKSPACE>/Controls/MCP/arcrift_safe_proxy.js"]
cwd = "<AOS_WORKSPACE>"

[env]
OLLAMA_URL = "http://localhost:11434"
ARCRIFT_STORAGE_MODE = "sqlite"
GRAPH_BACKEND = "ollama"
SQLITE_DB_PATH = "<TEMP>/aos_arcrift_desktop_settings_safe_proxy.sqlite"

No cloud API key is passed to this MCP server.

Actual behavior

• Codex Desktop UI shows the MCP server as enabled.
• Process-level MCP probe against the same stdio server returns the expected

four tools and no resources.

• tool_search in the Codex task does not expose any safe-proxy tools.
• Searching specifically for recall_context returns no safe-proxy tool.
• Only unrelated standard Codex app/thread tools are visible.

Local evidence

Ollama and ArcRift local runtime are available:

• Ollama API http://localhost:11434/api/tags returns HTTP 200.
• ArcRift backend http://localhost:3001/health returns HTTP 200 and version

1.6.3.

Process-level safe-proxy MCP discovery passes:

{
  "status": "PASS_PROXY_PROCESS_PROBE",
  "tools": [
    "get_project_summary",
    "identify_active_project",
    "list_projects",
    "recall_context"
  ],
  "blocked_tools_absent": true,
  "resources_empty": true,
  "tool_calls_executed": false,
  "temp_db_family_removed": true
}

Codex task/tool_search visibility fails:

safe-proxy tools visible to Codex runtime: NO
recall_context tool visible to Codex runtime: NO

Safety controls

The safe proxy intentionally exposes only read-only tools. The following
ArcRift capabilities are intentionally not exposed in the current stage:

• store_memory
• prune_memory
• search_memory
• index_codebase

No ArcRift tool call, retrieval, indexing, pruning, or memory write was
performed during the evidence collection.

Why this looks like a Codex Desktop/tool-surface issue

The local MCP server can start and answer tools/list correctly. The remaining
gap is after discovery: the tools are not injected into or exposed through the
Codex Desktop task/tool_search surface.

This appears to match the failure class described in #19425 and related reports:
custom/local MCP discovery succeeds, but the discovered tools do not reach the
thread/model callable tool surface.

Request

Could you confirm whether custom stdio MCP tools registered through Codex
Desktop Settings are expected to be exposed to task/tool_search on Windows, and
whether there is any additional step required beyond enabling the MCP server in
Desktop Settings?

If this is a known Desktop runtime/tool-surface injection issue, what diagnostic
logs or metadata would be most useful to provide without exposing private
workspace paths or data?

What steps can reproduce the bug?

Feedback ID: 019f7524-2428-7dd1-8179-ab975a7ec1c2

What is the expected behavior?

Expected behavior

After the custom MCP server is enabled and its tools/list manifest is valid,
Codex should expose the safe-proxy tools to the task/tool_search surface.

Expected safe-proxy tools:

• get_project_summary
• identify_active_project
• list_projects
• recall_context

Additional information

What steps can reproduce the bug?

1. On Windows, open Codex Desktop 26.715.31925.
2. In Settings → MCP servers, add and enable a custom STDIO server with:

• an absolute path to node.exe;
• an absolute path to the MCP server script in args;
• an absolute workspace path in cwd;
• the required local-only environment variables.

1. Save the server and select Restart.
2. Confirm that Codex Desktop shows the MCP server as enabled.
3. Against the same command, arguments, working directory, and environment, perform a metadata-only process-level MCP probe:

• tools/list returns get_project_summary, identify_active_project, list_projects, and recall_context;
• resources/list returns no resources;
• no MCP tools are called.

1. Open a fresh Codex Desktop task in the same workspace.
2. Use /mcp to inspect the server status, then ask Codex to locate recall_context or the other custom MCP tools.
3. Observe that none of the server’s tools are exposed to the task or returned by tool_search.

Expected: The four tools returned by tools/list are available to the Codex Desktop task.

Actual: The server appears enabled and passes process-level discovery, but its tools are absent from the Desktop task/tool surface.