Custom stdio MCP server discovered by /mcp but tools not exposed to Desktop threads

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

• #19304
• #17904
• #18527
• #19363

Powered by Codex Action

Update after full Codex Desktop restart:

Outcome is still: Discovery works, exposure still fails.

Fresh thread details:

• cwd: /Users/arbenlila/development/interdomestik-crystal-home
• current thread id: 019dc0ed-8043-78b1-badb-e1a5aa5e6f02
• tool_search for expected QA tools returned 0 tools, both initially and after rechecking.
• codex mcp list --json shows interdomestik_qa enabled.
• pnpm mcp:preflight passed, including live tools/list discovery.
• thread_dynamic_tools for the current thread contains only:
• automation_update
• read_thread_terminal
• load_workspace_dependencies
• install_workspace_dependencies
• thread_dynamic_tools contains 0 interdomestik_qa, project_map, read_files, or code_search entries.
• Recent Desktop logs show the stdio server started and initialized as interdomestik-qa version 1.0.0.
• Recent logs show ListToolsResult for this same thread containing the expected QA tool names.
• Only MCP warnings found were unsupported resources/resource templates methods, not tools/list failure.

Versions after restart:

• codex --version: codex-cli 0.124.0
• current thread cli_version: 0.125.0-alpha.3
• Desktop client: Codex.app 26.422.30944, build 2080

Most precise failure boundary:

Desktop/RMCP can start interdomestik_qa and receive ListToolsResult, but those tools are not persisted/indexed into the current thread's callable dynamic tools, so tool_search exposes none of them.

Reviewed the potential duplicates suggested by the bot. I do not think this is an exact duplicate, though it is likely related to the same MCP exposure/indexing area.

Comparison:

• #19304 is the closest symptom match, but it is Windows + local MCP plugin packaging. This issue is macOS + project-scoped stdio MCP config, and the important extra evidence is that Desktop logs show ListToolsResult for the same current thread containing the expected tool names, while thread_dynamic_tools still contains no custom MCP entries.
• #17904 is about codex exec session schema. This issue is Desktop thread/tool_search exposure.
• #18527 is remote HTTP OAuth MCP/auth handoff. This issue is local stdio MCP with successful initialization and tools/list, so OAuth is not involved.
• #19363 is custom model provider behavior. This issue uses the normal Desktop/App path, not a custom provider.

So the narrower failure here remains: Desktop/RMCP successfully starts the stdio server and receives ListToolsResult, but the discovered tools are not persisted/indexed into the thread's callable dynamic tools.

Additional cross-client comparison from the same local repo/machine:

Gemini/Antigravity is able to mount and use MCP tools successfully in this repo context. Verified working there:

• mcp-context-server/project_map
• mcp-context-server/read_files
• context7/resolve-library-id
• playwright/browser_tabs
• e2e-test-generator/generate_basic_test

This further suggests the MCP server/environment is not the root problem. Other MCP clients can index and call repo/context/playwright-style MCP tools on the same machine, while Codex Desktop still discovers interdomestik_qa via tools/list but does not expose the tools to the thread/tool_search surface.

One separate note: Gemini's repo-qa wrapper hit a JSON parsing/encoding issue (invalid character 'â') for some QA commands, which looks like command-output formatting inside that wrapper. That is distinct from this Codex issue, where the tools are not mounted at all despite successful ListToolsResult discovery.

Additional related issue with a useful version boundary: #19649

That report describes the same core failure class: MCP servers are registered and visible via codex mcp list / codex mcp get, but their tools are not injected into Codex threads.

Important detail from #19649:

• known working: codex-cli 0.120.0
• broken: codex-cli 0.122.0-alpha.13 and later
• same config works again after downgrading to 0.120.0

That lines up with this Desktop report:

• older Interdomestik thread on 0.91.0 had usable mcp__interdomestik_qa__... calls
• current Desktop/App runtimes around 0.124.x / 0.125.x discover tools/list but do not expose the tools to tool_search / thread_dynamic_tools

So this issue may be the Desktop/app-server manifestation of the same regression family as #19649. This issue still adds Desktop-specific evidence: the logs show ListToolsResult for the same current thread, while thread_dynamic_tools remains missing the discovered MCP tools.

This may be https://github.com/openai/codex/issues/20574, are you using a custom or older model?

Thanks. I do not think this is #20574.

In this repro I am not using a custom provider like Ollama/LiteLLM/Bifrost. The failing Desktop thread is using the normal Codex Desktop / ChatGPT path with gpt-5.5.

The failure signature is also different:

• #20574: tool_search is present but aborts with unsupported payload when called through a non-native provider.
• This issue: tool_search executes successfully, but returns an empty result for interdomestik_qa.
• The same session can discover other MCP/tool sources such as Context7, Playwright, and OpenAI docs.
• codex mcp list --json shows interdomestik_qa enabled.
• pnpm mcp:preflight passes, including live tools/list discovery from the stdio server.
• Desktop logs have shown ListToolsResult containing the expected interdomestik_qa tool names.
• The missing step is still that those discovered tools are not inserted into the thread/deferred tool index, so no mcp__interdomestik_qa__... namespace becomes callable.

So this still looks like a Desktop/app-server MCP exposure/indexing issue, not the custom-provider tool_search payload bug from #20574.

Additional update: I also tested a repo-side hardening for a possible stale-workspace-root factor.

Originally the project-scoped MCP entry used a relative cwd:

[mcp_servers.interdomestik_qa]
command = "/bin/bash"
args = ["scripts/start-repo-qa.sh"]
cwd = "."

I changed it to pin the server cwd to the absolute repository root while keeping the launcher argument unchanged:

[mcp_servers.interdomestik_qa]
command = "/bin/bash"
args = ["scripts/start-repo-qa.sh"]
cwd = "/Users/arbenlila/development/interdomestik-crystal-home"

I also added a local preflight guard so pnpm mcp:preflight fails if interdomestik_qa resolves with a relative cwd or a cwd outside this repo.

Verification after that hardening:

• codex mcp list --json resolves interdomestik_qa with the absolute repo cwd.
• pnpm mcp:preflight passes.
• live stdio tools/list discovery still passes and returns the expected QA tools.
• launching the same MCP command from a different parent directory works when the child cwd is pinned to the repo.

However, this did not fix Desktop thread exposure. In the running Desktop session, tool_search still returns 0 results for interdomestik_qa / project_map / read_files / code_search.

So the absolute-cwd change is a useful repo-side mitigation that removes stale root ambiguity, but it is not a complete fix for this issue. The remaining failure is still in the Desktop/app-server exposure/indexing step after successful MCP discovery.

Additional update from the repo side: I hardened the interdomestik_qa MCP configuration to remove possible local blockers, but the Desktop exposure failure remains in the current thread.

Repo-side changes made and verified:

• interdomestik_qa is pinned to the absolute repository cwd instead of cwd = ".".
• The project-scoped Codex config now declares a focused enabled_tools allowlist for the core agent tools:
• project_map
• read_files
• read_file_range
• code_search
• git_status_compact
• git_branch_info
• changed_files
• scope_audit
• check_health
• pr_verify
• security_guard
• e2e_gate
• All QA MCP tool input schemas are now strict object schemas with additionalProperties: false.
• pnpm mcp:preflight now verifies codex mcp get interdomestik_qa --json, including the parsed enabled_tools allowlist.

Verification results:

• codex mcp get interdomestik_qa --json shows the server enabled with the absolute cwd and the parsed enabled_tools allowlist.
• pnpm mcp:preflight passes.
• Live stdio tools/list discovery passes.
• Live tools/list returns 35 tools, all with strict object schemas, and the core allowlisted tools are present.

However, this existing Codex Desktop thread still returns 0 results from tool_search for interdomestik_qa project_map read_files code_search ....

So the repo/server side is now exposure-ready: no relative cwd, no unbounded Codex tool surface, and no permissive input schemas. If a fresh Desktop thread still does not surface mcp__interdomestik_qa__..., the remaining failure is still in Desktop/app-server MCP indexing/injection after successful discovery.

Additional update from the current Desktop session after restart and after testing the local-plugin/CLI distinction.

Current state:

• Codex Desktop now shows the Interdomestik QA plugin as available/enabled in the session metadata.
• tool_search still returns 0 results for interdomestik_qa, project_map, read_files, and code_search.
• There is still no callable mcp__interdomestik_qa__... namespace in the Desktop session.
• The hyphen/underscore distinction does not appear to be the root cause: the local plugin name can be interdomestik-qa, while the MCP server id remains interdomestik_qa; Desktop can know about the plugin/server, but the tools still are not admitted into the callable tool index.

CLI / local stdio contrast from the same repo and machine:

• The same MCP server config is startable from the CLI path.
• The repo-local stdio server can be initialized, can return tools/list, and can execute tool calls.
• Verified via a thin local bridge using the same launcher:
• pnpm mcp:tool list returns the expected QA tools.
• pnpm mcp:tool call read_file_range '{"file":"package.json","startLine":1,"endLine":8}' succeeds.
• The app-bundled Codex CLI also sees interdomestik_qa as enabled with the expected command/cwd/env configuration.

So the current narrowed boundary is:

1. MCP server startup works.
2. MCP initialize works.
3. MCP tools/list works.
4. Direct stdio tool calls work.
5. Desktop can have the local plugin/server present in session metadata.
6. Desktop still does not insert those discovered tools into tool_search / the callable mcp__... namespace.

I also checked public issues/docs for evidence that Codex Desktop has started admitting local custom MCPs into tool_search; I did not find a confirmed fix or documented supported path for that yet. This still looks like a Desktop/app-server MCP admission/indexing bug, not a repo MCP implementation problem.

Hi OpenAI Codex team,

I’m asking for help with a Codex Desktop MCP exposure issue.

I have a repo-local MCP server named interdomestik_qa. The server is configured, startable, and discoverable, but Codex Desktop does not expose its tools as callable mcp__interdomestik_qa__... tools through tool_search.

What works:

• codex mcp get interdomestik_qa --json shows the server enabled.
• The server launches over stdio.
• Live initialize works.
• Live tools/list works.
• pnpm mcp:preflight passes.
• The server returns a reduced Codex-facing tool surface.
• Tool schemas are strict object schemas with additionalProperties: false.
• Gemini and VS Code can expose MCP tools on the same machine.

What fails:

• In Codex Desktop, tool_search returns 0 tools for interdomestik_qa, project_map, read_files, read_file_range, and code_search.
• No callable namespace like mcp__interdomestik_qa__project_map appears, even after restarting Codex Desktop from the repo root.

Current suspected boundary:

Codex Desktop can see/start/discover the MCP server, but the discovered tools are not admitted into the Desktop/app-server callable tool index.

Could you please clarify whether Codex Desktop currently supports exposing local custom stdio MCP servers into tool_search? If yes, what exact config/plugin shape is required? If not, is this a known limitation or regression?

This is blocking my preferred workflow because the repo MCP tools are much faster and deeper for codebase inspection than shell fallbacks.

Thank you.

I'm running into same issue, this is a huge one, I think it should have been fixed by now...

Codex CLI recognize my MCP and model can make call, but Codex app does not. /cli on codex app shown the MCP server, but model not being able to call it.

it's absurd this bug is still open after all this time. MCP is such a key feature, why is the team not fixing something like this?

I'm experiencing this issue as well.

I am seeing the same Desktop MCP discovery-to-exposure failure on a newer Codex build, with two independent custom Streamable HTTP MCP servers.

Environment:

• macOS
• Codex Desktop: 26.707.72221
• Desktop-bundled Codex CLI/app-server: 0.144.2
• Separately installed Codex CLI: 0.144.5
• MCP configuration: global ~/.codex/config.toml
• Transport: Streamable HTTP on localhost
• Model/provider: normal Codex Desktop / ChatGPT path, not a custom or OSS provider

What works:

• codex mcp list shows both custom servers enabled.
• The Desktop-bundled CLI also sees the same configured servers.
• Both servers complete MCP initialize successfully.
• Both advertise the tools capability.
• Direct tools/list returns their complete and valid tool definitions.
• The tools can be called through a direct MCP client, confirming that the servers and transport are functional.

What fails:

• New Codex Desktop threads receive no callable namespace for either server.
• No mcp__<server>__... tools are present in the thread tool registry.
• Generic MCP resource discovery does not expose either server.
• Fully restarting and opening a new thread does not change the result.

This appears to fail after successful server initialization and tool discovery, but before the discovered tools are admitted into the Desktop thread callable-tool index. That matches the boundary described in this issue.

The servers are primarily tool-oriented and do not advertise MCP resources, so this may overlap with:

• #14242 — tool-only MCP servers are not discovered/used correctly
• #10499 — Desktop shows MCP servers but chat cannot use them while TUI/CLI behavior differs
• #19649 — registered MCP tools not injected into threads; closed, but documents the same regression family

The older #3441 appears different because its example used the obsolete [mcp.servers] configuration shape. My configuration uses the current [mcp_servers.<name>] format and is parsed correctly by both CLI versions.

So this is still reproducible on Desktop/app-server 0.144.2, well beyond the 0.124.x versions originally reported here.

Adding a stricter reproduction on a newer Desktop build. This server exposes both MCP resources and tools, so the failure is not limited to tool-only servers or an empty resources/list response.

Environment:

• macOS 26.5.2, Apple Silicon
• Codex Desktop 26.707.91948 (build 5440)
• Desktop-bundled Codex CLI/app-server 0.144.5
• Global ~/.codex/config.toml
• Custom stdio MCP server
• Fresh task and resumed task both tested

Verified working:

• The MCP server is enabled in Codex configuration.
• Its disabled-tool ACL is empty.
• The configured stdio process starts and remains live.
• MCP initialization succeeds.
• Resource discovery succeeds; the task can read the server resource.
• Codex telemetry for the exact fresh task records:

listed MCP server tools while building tool list server_name=RepoPromptCE tool_count=20

Observed failure:

• The task receives no callable mcp__RepoPromptCE__* tools.
• The task also receives no tool_search or equivalent deferred-tool retrieval bridge.
• Desktop logs show ToolSearchAlwaysDeferMcpTools enabled.
• Therefore the 20 successfully discovered tools are deferred/withheld, but there is no mechanism available to retrieve them.
• A full machine reboot, restarting both applications, and creating a genuinely new task do not change the result.

Expected behavior:

When Codex defers discovered MCP tools, the task must receive tool_search; otherwise it should inject the direct MCP tools. Successfully discovered tools must not become unreachable through both paths.

This places the failure after successful tools/list and before model-visible direct/deferred tool registration, matching the boundary described in this issue. The server configuration, process, transport, resource path, and tool discovery all remain healthy.

this is the discovery-vs-registration split, and it shows up wherever tool exposure is a separate layer from tool discovery. /mcp, codex mcp list, and your preflight are all reading the same fact: a tools/list round trip succeeded. none of them read the thread's tool surface, which is the thing that actually gates a call. so every green light you have is green about the wrong layer. the useful diff is the 0.91.0 thread against the alpha one, same ListToolsResult, different thread_dynamic_tools. whatever indexes discovered tools into that surface stopped consuming the result, and nothing downstream of it is built to notice the gap.

Additional reproduction: Windows / Streamable HTTP / Codex Desktop 0.144.5

I can reproduce this with a custom Streamable HTTP MCP server for a game
I am developing. The server exposes resources and three tools for observing
and controlling the running application.

The failure does not appear to be game-specific: Codex successfully discovers
the tools but does not expose them to the thread.

Environment:

• Windows
• Codex Desktop client: 26.707.91948
• Codex runtime/session version: 0.144.5
• Model: gpt-5.6-sol
• MCP transport: Streamable HTTP on localhost
• MCP server type: custom C++ server embedded in a local application

Observed behavior:

• MCP initialization succeeds.
• resources/list, resources/templates/list, and resources/read succeed.
• The server returns three valid tools from tools/list.
• Manual tools/call requests to the server succeed.
• Codex internal logs repeatedly report:

server_name=<custom_server> tool_count=3

• Nevertheless, none of the three tools is exposed to the model-visible

thread tools.

• tool_search is also unavailable in the affected thread, so the deferred

tools cannot be discovered.

• Only the generic MCP resource-reading functions are available to the model.

The discovered tools consist of:

• one read-only observation tool
• one ordinary control tool
• one explicitly destructive data-editing tool

The server exposes resources as well as tools, so this is not caused by an
empty or unsupported resources/list implementation.

I reproduced the result in an independent fresh Codex task. It also reported
that none of the custom MCP tools was directly available, ruling out stale
tool state in an existing thread.

Additional diagnostic result:

codex features list reports:

tool_search_always_defer_mcp_tools removed true

Adding the following user configuration had no effect and was removed
afterward:

tool_search_always_defer_mcp_tools = false

Expected behavior:

Either:

1. a small discovered MCP tool set should be exposed directly to the thread, or
2. tool_search must be supplied whenever those tools are deferred.

The failure appears to occur after successful tools/list discovery but
before the tools are exposed to the thread or tool-search surface.

I traced this to a concrete code-mode exposure bug and have a tested patch.

Root cause: in code_mode_only, the planner retains only the code executor tools and tools marked DirectModelOnly. MCP tools are intentionally deferred to tool_search, but the cached tool_search handler itself retained normal exposure and was filtered out. The MCP server could therefore initialize and return ListToolsResult, while both access paths were unavailable: the MCP tools were deferred and the search bridge was hidden.

The patch marks tool_search as DirectModelOnly. Deferred MCP tools remain out of the initial prompt, but the model keeps the top-level search bridge, can receive the deferred namespace, and can then call the MCP tool. I added planner coverage and an end-to-end Responses Lite test for search -> deferred MCP namespace -> tool call, and also verified the patched app-server against a real configured Streamable HTTP Jira MCP server.

Review PR: https://github.com/yunusemregul/codex/pull/1
Commit: https://github.com/yunusemregul/codex/commit/dd5b8e84ca190efcd4222f2eb0460e38959a8301

OpenAI documents external Codex contributions as invitation-only, and GitHub rejected creating the PR directly against openai/codex through both GraphQL and REST. The fork PR is therefore the reviewable patch; if a maintainer invites it, the same branch can be submitted upstream directly.

Related reports: #14242, #10499, and #19649.

Thanks for the detailed report. I independently reproduced a closely matching Windows case and narrowed it to a specific Sol/Responses Lite tool-exposure path. I believe it belongs in this thread because MCP discovery succeeds, but the Desktop task does not receive a usable deferred tool surface.

Environment

• Windows
• Codex Desktop/App Server 0.144.5
• Model: gpt-5.6-sol
• Live account catalog:
• use_responses_lite: true
• supports_search_tool: true
• tool_mode: direct
• multi_agent_version: v1
• Independent, read-only stdio MCP canary exposing one unique echo tool

Controlled live results

| Route | Only catalog change | tools/list | Successful MCP call |
|---|---|---:|---:|
| GPT-5.5, normal Responses | none | 1/1 | 1/1 |
| Sol, Responses Lite + deferred tool_search | none | 3/3 | 0/3 |
| Sol, normal Responses + deferred tool_search | use_responses_lite: true → false | 3/3 | 3/3 |
| Sol, Responses Lite + direct MCP namespace | supports_search_tool: true → false | 2/2 | 2/2 |

Every failing Sol/Lite run initialized the MCP server, received a valid one-tool tools/list result, and logged that tool in Codex’s inventory. None made tools/call; each returned the prompt’s exact TOOL_SEARCH_UNAVAILABLE fallback. All five matched Sol controls called the canary with the expected token.

This rules out the MCP process, stdio transport, tool schema, Windows helper, Codex’s MCP invocation router, a generic Sol tool-calling limitation, and random tool choice.

Sanitized final outbound request trace

I captured the final request with the real 0.144.5 executable pointed only at a loopback endpoint. No request was forwarded externally, and no raw body, header values, credentials, prompts, instructions, or tool schemas were persisted.

For the affected Sol/Lite route, the request:

• targets POST /v1/responses;
• carries x-openai-internal-codex-responses-lite;
• has no top-level tools field;
• starts with a developer-role additional_tools item; and
• includes:

{
  "type": "tool_search",
  "execution": "client"
}

The initial body does not contain mcp__node_repl, but that is expected for a deferred namespace. Its metadata remains in Codex’s client-side search index and should be returned after a successful tool_search call.

The matched wire controls further narrow the boundary:

• With only use_responses_lite: false, the same client-executed tool_search appears in top-level tools, and Sol succeeds 3/3.
• With Lite still enabled but only supports_search_tool: false, additional_tools contains the direct mcp__node_repl namespace and its three child tools. Sol successfully invokes the equivalent synthetic MCP canary 2/2.

Therefore, Responses Lite can expose and invoke direct MCP namespaces. The failing sub-path is specifically the client-executed tool_search surface under Responses Lite.

Public-source check

I checked both the installed source-equivalent commit 8c68d4c and upstream main at 9ff4786. In both versions, the Lite request builder intentionally serializes tools into a leading AdditionalTools item.

The existing stdio_server_round_trip tests:

tool_search → MCP namespace → MCP call

However, it covers only normal Responses. I added a local Lite variant that asserts the wire placement and reuses the complete search/load/invoke round trip:

responses_lite_stdio_server_round_trip ... ok
stdio_server_round_trip ... ok

Formatting also passes. This confirms that the public client serializer, client-side search index, response routing, and MCP invocation path can complete a mocked Lite exchange. It does not cover the internal service transformation that determines which tools become model-visible.

Most likely remaining boundary

MCP initialize/tools/list succeeds
  → Codex builds the deferred search index
  → final Lite request contains client-executed tool_search
  → Responses Lite accepts the request
  → Sol receives no usable tool_search surface

Could a maintainer inspect a sanitized post-ingestion trace for one failing Sol request and confirm:

1. Whether the accepted developer-role additional_tools item still contains {"type":"tool_search","execution":"client"}.
2. Whether tool_search is registered in the model-visible tool list.
3. Whether it is filtered by the Lite route/header, the AdditionalTools conversion, or a Sol-specific allowlist.

I have sanitized per-trial summaries, three matched request traces, and the focused regression-test patch available to attach.

For users, a fresh GPT-5.5 task is a reliable workaround. A fresh Sol task alone is not sufficient in the affected direct + Responses Lite catalog cohort. Forcing non-Lite was useful as a diagnostic, not a supported configuration recommendation.

Additional reproduction: official Linear app/plugin regressed immediately after Desktop update

I can reproduce the same discovery-to-exposure failure with the official curated Linear integration, rather than a custom MCP server.

Environment:

• macOS, Apple Silicon
• ChatGPT/Codex Desktop 26.707.91948 (build 5440)
• Desktop-bundled Codex CLI/app-server 0.144.5
• Model: gpt-5.6-sol
• Official linear@openai-curated plugin
• Normal ChatGPT account/provider path

Before/after boundary:

• An archived task on the same machine/account records a successful codex_apps Linear get_issue call at 2026-07-16T02:16Z, before the Desktop update.
• The application bundle was then updated to 26.707.91948.
• The first fresh tasks under the new build no longer received any callable Linear tools.
• This is therefore a tighter version/time boundary than a newly configured connector that never worked.

Verified healthy after the update:

• The Linear plugin is installed and enabled.
• The bundled plugin manifest still declares the official https://mcp.linear.app/mcp endpoint.
• The Linear app connection remains linked and its local tool catalog contains the expected issue/project actions.
• codex mcp list and codex mcp get linear show the Linear MCP server enabled with OAuth.
• Re-running codex mcp login linear completes successfully.
• The official Linear MCP endpoint is reachable and completes OAuth negotiation.
• OpenAI and Linear status pages show no active service incident.

Observed failure:

• Fresh Desktop tasks receive no callable codex_apps Linear tools.
• The affected task also receives no tool_search bridge.
• A fresh isolated codex exec probe cannot call get_issue and reports the Linear tool unavailable.
• A direct resource probe can fail with unknown MCP server linear even though codex mcp list/get report it enabled.
• Reauthorization and full Desktop restarts do not restore the tool surface.

This appears to be the same post-discovery exposure failure described above, but it also affects a first-party curated plugin whose app connection and OAuth state are healthy. The update did not merely break a custom server configuration; it made a previously working official connector unreachable from new tasks.

The current release notes say existing app connections should remain unaffected by the App Directory to Plugin Directory migration, so this behavior appears to be an unintended regression.

All identifiers, account details, local paths, OAuth data, issue content, and workspace-specific values have been intentionally omitted.

it's really crazy that a bug of this magnitude goes ignored for so long considering the development is done primarily by agents. What is going on? Don't OpenAI have auth tests for MCP in the testing harness? I have that in my own hand rolled framework!

please contribute to the discussion https://github.com/openai/codex/discussions/33682 to raise visibility with the team. The MCP bug reports are very clearly being ignored right now.

Additional reproduction: Solo orchestration MCP / resources visible, action tools unreachable

I can reproduce this with Solo's local stdio MCP server. This is especially confusing because Solo correctly reports Codex as connected, and Codex can use Solo's resource APIs, while Solo's orchestration/action tools remain unreachable.

Environment:

• macOS 15.7.4, Apple Silicon
• Codex CLI/session runtime 0.144.5
• Model gpt-5.6-sol, medium reasoning
• Solo Desktop 0.9.3
• MCP transport: local stdio
• Global configuration:

[mcp_servers.solo]
command = "/Applications/Solo.app/Contents/MacOS/mcp"

Verified working:

• codex mcp get solo shows the server enabled.
• Solo completes MCP initialization.
• Codex can call generic MCP resource discovery for server="solo".
• resources/list returns Solo scratchpads and todos.
• A direct MCP tools/list round trip returns Solo's complete action-tool catalog, including:
• whoami
• list_agent_tools
• spawn_agent
• send_input
• get_process_output
• timer tools
• Direct manual MCP calls through a thin stdio client work.

Observed failure:

• The fresh Codex thread receives only generic MCP resource helpers.
• It receives no callable mcp__solo__... action tools.
• It also receives no tool_search bridge.
• Consequently, the documented Solo reviewer workflow cannot call list_agent_tools, spawn_agent, send_input, or timers even though Solo is connected and advertises them successfully.

Restart/update test:

• The original process used Codex 0.144.4.
• Codex was fully restarted and came back on 0.144.5.
• A genuinely fresh thread reproduced the same result.
• codex features list reports:

tool_search                         removed  false
tool_search_always_defer_mcp_tools removed  true

• Writing tool_search_always_defer_mcp_tools = false to config.toml has no effect on the reported effective state.

Expected behavior:

Either Solo's discovered action tools should be injected directly, or the thread must receive tool_search so the deferred tools can be loaded. A healthy connection plus resource access should not leave every action tool inaccessible.

This matches the code_mode_only / DirectModelOnly root cause and proposed patch described in the comment above.