gpt-5.6-sol loses all MCP tools after runtime metadata changes to tool_mode = "direct"

Resolved 💬 14 comments Opened Jul 16, 2026 by apkd Closed Jul 17, 2026

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

codex-cli 0.144.0

What subscription do you have?

Pro lite

Which model were you using?

gpt-5.6-sol

What platform is your computer?

Linux 6.18.38 x86_64 unknown

What terminal emulator and version are you using (if applicable)?

kitty 0.47.0

Codex doctor report

{
  "schemaVersion": 1,
  "overallStatus": "fail",
  "codexVersion": "0.144.0",
  "checks": {
    "auth.credentials": {
      "status": "ok",
      "summary": "auth is configured",
      "details": {
        "stored API key": "false",
        "stored ChatGPT tokens": "true",
        "stored auth mode": "chatgpt"
      }
    },
    "config.load": {
      "status": "ok",
      "summary": "config loaded",
      "details": {
        "enabled feature flags": "shell_tool, unified_exec, shell_snapshot, code_mode_host,
        terminal_resize_reflow, sqlite, hooks, enable_request_compression, multi_agent,
        tool_search_always_defer_mcp_tools, tool_suggest, plugins, in_app_browser, browser_use,
        browser_use_full_cdp_access, browser_use_external, computer_use, remote_plugin, plugin_sharing,
        image_generation, resize_all_images, skill_mcp_dependency_install, mentions_v2, steer,
        guardian_approval, goals, collaboration_modes, tool_call_mcp_elicitation, auth_elicitation,
        personality, fast_mode, tui_app_server, prevent_idle_sleep, remote_compaction_v2,
        workspace_dependencies",
        "mcp servers": "1",
        "model": "gpt-5.6-sol",
        "model provider": "openai"
      }
    },
    "installation": {
      "status": "ok",
      "summary": "installation looks consistent",
      "details": {
        "install context": "other",
        "managed by bun": "false",
        "managed by npm": "false",
        "managed by pnpm": "false"
      }
    },
    "mcp.config": {
      "status": "ok",
      "summary": "MCP configuration is locally consistent",
      "details": {
        "configured servers": "1",
        "disabled servers": "0",
        "streamable_http servers": "1"
      }
    },
    "network.env": {
      "status": "ok",
      "summary": "network-related environment looks readable",
      "details": {
        "proxy env vars": "none"
      }
    },
    "network.provider_reachability": {
      "status": "ok",
      "summary": "active provider endpoints are reachable over HTTP",
      "details": {
        "ChatGPT base URL": "https://chatgpt.com/backend-api/ reachable (HTTP 403)",
        "reachability mode": "ChatGPT auth"
      }
    },
    "network.websocket_reachability": {
      "status": "ok",
      "summary": "Responses WebSocket handshake succeeded",
      "details": {
        "auth mode": "chatgpt",
        "handshake result": "HTTP 101 Switching Protocols",
        "model provider": "openai",
        "supports websockets": "true",
        "wire API": "responses"
      }
    },
    "runtime.provenance": {
      "status": "ok",
      "summary": "running local build on linux-x86_64",
      "details": {
        "platform": "linux-x86_64",
        "version": "0.144.0"
      }
    },
    "terminal.env": {
      "status": "fail",
      "summary": "TERMINFO unreadable - terminal capabilities are unknown",
      "details": {
        "terminal": "kitty",
        "terminal size": "80x24"
      }
    },
    "updates.status": {
      "status": "ok",
      "summary": "update configuration is locally consistent",
      "details": {
        "latest version": "0.144.5",
        "latest version status": "newer version is available"
      }
    }
  }
}

What issue are you seeing?

All configured MCP tools became unavailable simultaneously on multiple machines on July 16, 2026. No Codex
binary, configuration, or MCP server update occurred.

The MCP clients still initialize successfully:

Codex maintains an established connection to the HTTP MCP server.
Local stdio MCP child processes remain running.
codex doctor reports that the MCP configuration is locally consistent.
The MCP servers respond normally when probed independently.

However, the model receives neither the MCP tool namespaces nor tool_search. It only receives ordinary built-in
tools. Calls to every configured MCP tool are therefore impossible.

The dynamically fetched model catalog currently describes gpt-5.6-sol as:

{
  "slug": "gpt-5.6-sol",
  "supports_search_tool": true,
  "use_responses_lite": true,
  "tool_mode": "direct",
  "multi_agent_version": "v2"
}

This can be inspected with:

jq '.models[]
  | select(.slug == "gpt-5.6-sol")
  | {
      slug,
      tool_mode,
      supports_search_tool,
      use_responses_lite,
      multi_agent_version
    }' ~/.codex/models_cache.json

Before this failure, the same unchanged Codex installations used Code Mode with gpt-5.6-sol and successfully
invoked the same MCP tools.

What steps can reproduce the bug?

Configure a working HTTP or stdio MCP server.
Start Codex 0.144.0 using gpt-5.6-sol.
Confirm that the MCP server initializes successfully.
Ask Codex to invoke one of the configured MCP tools.
Observe that the MCP namespace is absent from the model-visible tool list.
Observe that tool_search is also absent.
Inspect ~/.codex/models_cache.json and confirm that gpt-5.6-sol now has tool_mode: "direct".

This began simultaneously on several machines with unchanged installations.

What is the expected behavior?

Successfully initialized MCP tools should remain callable.

Codex should either:

expose the MCP namespaces directly; or
expose tool_search so deferred MCP tools can be discovered and invoked.

A runtime model-metadata change should not leave MCP tools initialized locally but unreachable by the model.

Additional information

The active feature set includes tool_search_always_defer_mcp_tools.

This appears to involve the combination of:

tool_mode = direct
supports_search_tool = true
use_responses_lite = true
tool_search_always_defer_mcp_tools = enabled

MCP tools appear to be deferred because search is considered available, while tool_search itself does not reach
the model.

Relevant code appears to include:

core/src/session/turn.rs
core/src/mcp_tool_exposure.rs
core/src/tools/spec_plan.rs

gpt-5.6-terra and gpt-5.6-luna currently advertise tool_mode: "code_mode_only" and may provide a temporary
workaround.

View original on GitHub ↗

14 Comments

github-actions[bot] contributor · 4 days ago

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

#33547

Powered by Codex Action

Bimmervison · 4 days ago

Independent reproduction on macOS with ChatGPT Desktop 26.707.91948 and Codex CLI 0.144.5.
With gpt-5.6-sol, the Figma MCP initializes successfully and logs report server_name=figma tool_count=26, but figma/use_figma and figma/whoami are not model-visible. ToolSearchAlwaysDeferMcpTools is enabled while tool_search is absent.
With the same account, client, MCP configuration, and network, switching only to GPT-5.4 successfully calls figma/whoami.
This appears to be a model/tool-injection regression rather than an MCP connectivity or OAuth failure. Current workaround: GPT-5.4.

apkd · 4 days ago

Current workaround: GPT-5.4.

GPT-5.6 Terra/Luna also work. This issue seems to only affect Sol.

Bimmervison · 4 days ago

> Current workaround: GPT-5.4. GPT-5.6 Terra/Luna also work. This issue seems to only affect Sol.

yes, but sol still working yesterday

jeygeethan-megan · 4 days ago

Independent confirmation with both node_repl and Chrome on macOS.

Environment:

ChatGPT/Codex Desktop 26.707.91948
Bundled CLI 0.144.5
Workspace Dependencies 26.715.12143
macOS 26.5.2

Every failing fresh Desktop/CLI probe used gpt-5.6-sol: the MCP manager discovered all three node_repl tools, but the model-facing task had no callable tool.

Changing only to GPT-5.4 restored the surface:

Ephemeral CLI: real mcp_tool_call to node_repl/js; console.log(1+1) returned 2.
Fresh Desktop task: tool discovery exposed mcp__node_repl; the same JS probe returned 2; Chrome then connected and successfully listed open tabs read-only.

Working Desktop task ID: 019f6b99-ac95-7a12-a702-4a158ec39c06.

One nuance: an equivalent GPT-5.6 Terra ephemeral CLI probe still reported node_repl unavailable in this environment, so Terra may not be a universal workaround across surfaces. GPT-5.4 is confirmed here in both CLI and Desktop. No config, plugin, extension, or app reinstall was involved.

theOxifier · 4 days ago

Just adding to the noise, but experiencing the same issue as others.

joonathan · 4 days ago

Adding a same-machine macOS A/B reproduction supporting this diagnosis.

Environment: Codex Desktop 26.707.91948, CLI 0.144.5, and Chrome plugin 26.707.91948. Chrome extension and native-host checks passed.

Both fresh projectless tasks received the same prompt:

Use @Chrome to list my currently open Chrome tabs. Do not interact with any page.

GPT-5.6 Sol — failed

Model: gpt-5.6-sol, Medium
Task: 019f6adb-f996-77f1-83b5-b4f980d59a0e
Model catalog: tool_mode = "direct"
Neither mcp__node_repl__js nor tool_search was exposed, so Chrome control could not initialize.

GPT-5.6 Terra — succeeded

Model: gpt-5.6-terra, High
Task: 019f6c46-e232-7791-8285-0a8c4007551b
Model catalog: tool_mode = "code_mode_only"
The identical prompt successfully invoked node_repl/js using the Chrome browser backend.

This same-environment comparison supports the proposed interaction between Sol’s tool_mode = "direct" and deferred MCP tools.

DainisGorbunovs · 4 days ago

Workaround is to add the affected MCP namespace (e.g. mcp__node_repl) to direct_only_tool_namespaces.

So for node_repl this would mean adding the following config to ~/.codex/config.toml:

[features.code_mode]
direct_only_tool_namespaces = ["mcp__node_repl"]

See https://github.com/openai/codex/issues/33609#issuecomment-4994035260 for more info. I've also drafted and tested a fix in https://github.com/openai/codex/compare/main...DainisGorbunovs:codex:agent/fix-responses-lite-tool-search but as I'm not in the contributor list, I cannot make a PR.

EDIT: Alternative workaround: set environment variable CODEX_INTERNAL_ORIGINATOR_OVERRIDE=codex_cli_rs_github_issue_33609 before launching codex. With codex_cli_rs_github_issue_33609 originator, the tool mode is still code_mode_only and thus this issue is not present.

LoweloDev · 4 days ago

Codex Desktop on Windows has a model-specific tool exposure regression matching openai/codex#33575. With gpt-5.6-sol, installed plugins and MCP servers initialize and enumerate their tools, but neither their tools nor tool_search is exposed to the model. Linear, Computer Use, Browser, Codex Security, and other plugins become uncallable. Another Codex model can access the same plugins, confirming the installation and connections are healthy.
Reproduced on Codex Desktop 26.707.12708.0 / bundled components 26.707.91948 / CLI 0.144.5. The failure began BEFORE updating from CLI 0.144.2. Windows kernel reboot, app Repair, and disabling/re-enabling every plugin did not fix it.

Please escalate as a gpt-5.6-sol model-catalog/tool-manifest regression. Does indeed explicitly NOT affect every 5.6 model, ONLY sol.

LoweloDev · 4 days ago

Workaround is to add the affected MCP namespace (e.g. mcp__node_repl) to direct_only_tool_namespaces. So for node_repl this would mean adding the following config to ~/.codex/config.toml: [features.code_mode] direct_only_tool_namespaces = ["mcp__node_repl"] See #33609 (comment) for more info. I've also drafted and tested a fix in main...DainisGorbunovs:codex:agent/fix-responses-lite-tool-search but as I'm not in the contributor list, I cannot make a PR. EDIT: Alternative workaround: set environment variable CODEX_INTERNAL_ORIGINATOR_OVERRIDE=codex_cli_rs_github_issue_33609 before launching codex. With codex_cli_rs_github_issue_33609 originator, the tool mode is still code_mode_only and thus this issue is not present.

Thx, I'm using this as a workaround for now, seems to work perfectly.

To me the regression is demonstrably more of a backend-triggered one, because Sol lost its tools during active use of Codex before any client update or local configuration change, while the same client continued working with other models. To me that strongly indicates Sol’s remotely delivered metadata changed incompatibly, whereas for other models it obv. did not. So I think backend needs a fix, rather than the client itself specifically for Sol. But what do I know, am low elo. :P

DainisGorbunovs · 4 days ago

This issue appears to be mitigated now. They've flipped the tool_mode to code_mode_only for 5.6-sol models (checked manually below).

<details>
<summary>gpt-5.6-sol model settings</summary>

VERSION=0.144.5
ORIGINATOR=codex_cli_rs

jq -r \
  --arg url "https://chatgpt.com/backend-api/codex/models?client_version=$VERSION" \
  --arg originator "$ORIGINATOR" '
    "url = " + ($url | @json),
    "header = " + (("Authorization: Bearer " + .tokens.access_token) | @json),
    "header = " + (("ChatGPT-Account-ID: " + .tokens.account_id) | @json),
    "header = " + (("originator: " + $originator) | @json),
    "silent",
    "show-error",
    "fail-with-body"
  ' ~/.codex/auth.json |
curl --config - |
jq '.models[] |
  select(.slug == "gpt-5.6-sol") |
  {
    slug,
    visibility,
    tool_mode,
    supports_search_tool,
    use_responses_lite,
    multi_agent_version
  }'

{
  "slug": "gpt-5.6-sol",
  "visibility": "list",
  "tool_mode": "code_mode_only",
  "supports_search_tool": true,
  "use_responses_lite": true,
  "multi_agent_version": "v2"
}

</details>

<details>
<summary>no models with direct tool mode, search tool enabled and using responses lite</summary>

codex debug models |
  jq '.models[] |
    select(
      .tool_mode == "direct" and
      .supports_search_tool == true and
      .use_responses_lite == true
    ) |
    {
      slug,
      visibility,
      tool_mode,
      supports_search_tool,
      use_responses_lite,
      multi_agent_version
    }'

returns nothing.

</details>

Bimmervison · 4 days ago

Workaround is to add the affected MCP namespace (e.g. mcp__node_repl) to direct_only_tool_namespaces. So for node_repl this would mean adding the following config to ~/.codex/config.toml: [features.code_mode] direct_only_tool_namespaces = ["mcp__node_repl"] See #33609 (comment) for more info. I've also drafted and tested a fix in main...DainisGorbunovs:codex:agent/fix-responses-lite-tool-search but as I'm not in the contributor list, I cannot make a PR. EDIT: Alternative workaround: set environment variable CODEX_INTERNAL_ORIGINATOR_OVERRIDE=codex_cli_rs_github_issue_33609 before launching codex. With codex_cli_rs_github_issue_33609 originator, the tool mode is still code_mode_only and thus this issue is not present.

OMG, this really works. Many thanks, wondering if open ai gonna fix that soon

joonathan · 3 days ago

Update: this now works for me on the newer build.

ChatGPT/Codex Desktop and Chrome plugin: 26.715.21425
Bundled CLI: 0.145.0-alpha.18
Model: gpt-5.6-sol, Medium
Task: 019f6f09-72f7-74e1-9432-98aba23d1ab1

In a fresh task, tool_search was present, discovered mcp__node_repl__js, and Chrome successfully returned all 24 open tabs. This is the same Mac/setup that failed on Desktop 26.707.91948 / CLI 0.144.5, with both tools absent.

The live Sol catalog changed between direct and code_mode_only during follow-up checks, so I cannot attribute the recovery to one stable metadata value. However, the original tool-exposure failure no longer reproduces for me.

apkd · 3 days ago

Closing this now that a backend-side workaround was applied. Presumably the direct tool mode will come back in better health in the future.