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

## 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:

```toml
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:

```json
{
  "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:

```text
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.
3. Save the server and select **Restart**.
4. Confirm that Codex Desktop shows the MCP server as enabled.
5. 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.
6. Open a fresh Codex Desktop task in the same workspace.
7. Use `/mcp` to inspect the server status, then ask Codex to locate `recall_context` or the other custom MCP tools.
8. 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.