0.114.0 upgrade to 0.116.0/0.117.0/0.118.0 somewhat breaks MCP

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

• #15832
• #15565
• #14927
• #15628

Powered by Codex Action

tracking internally as PDINC-13505

while the tools enumeration are not showing in /mcp the agent seems able to assume the tools are present. From the session

› try again.

• Retrying the Chrome MCP tool now.

• Working now.

MCP Chrome tool succeeded:

• opened about:blank
• pages visible:
• chrome://new-tab-page/
• about:blank

So the browser attach path is healthy again.

› ok, let me see if upgraging you still allows it to work. ready?

• Yes. After the upgrade, I’ll test MCP first.

› ok, the 'Tools: (none)' but, try anyways

• Trying the Chrome MCP tool directly.

• Called chrome-devtools.new_page({"url":"about:blank","timeout":20000})
└ # new_page response
## Pages
1: chrome-error://chromewebdata/
2: REDACTED
3: REDACTED
4: REDACTED
5: REDACTED
6: REDACTED
7: about:blank [selected]

───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

• Works.

Even though /mcp says Tools: (none), the bound Chrome MCP tool is functioning in this session.

I successfully opened about:blank and got the page list back.

0.114 to 0.117 is a bug jump. Are you able to narrow it down to a specific release?

0.114 to 0.117 is a bug jump. Are you able to narrow it down to a specific release?

we know it did not work in 116, as the subject said. If 115 testing is required, we can interrupt work to find out.

[we should note, we _have not seen_ a practical impact to work at this time]

I can confirm this looks like the same regression, and in my setup it is not limited to hyphenated server names.

Additional data point from codex-cli 0.117.0 on WSL2/Arch Linux:

• /mcp omits the per-server Status line entirely
• /mcp can show Tools: (none) for working non-hyphenated servers such as context7 and openaiDeveloperDocs
• codex mcp list still reports those servers as enabled
• the tools are still callable successfully in-session (for example Context7 resolve_library_id and query_docs)

So this seems broader than the hyphenated-name grouping bug in #15565.

I opened #16087 with the same symptoms from the context7 / openaiDeveloperDocs side and will close it as a duplicate of this issue.

upgraded to 0.118, asked codex for self check:

```• I’ve confirmed the Chrome server itself only exposes tools, not resources, so the Resources: (none) part of /mcp is
expected. The only suspicious part left is Tools: (none), and I’m now testing a fresh codex exec invocation plus your
MCP config to see whether discovery is broken in the CLI or only in the /mcp display.

• Ran [ -f ~/.codex/config.toml ] && sed -n '1,220p' ~/.codex/config.toml || echo 'NO_CONFIG'
└ model = "gpt-5.4"
model_reasoning_effort = "high"
… +40 lines
enabled = true

• Ran codex mcp --help
└ Manage external MCP servers for Codex

… +26 lines
-h, --help
Print help (see a summary with '-h')

• Ran codex mcp list
└ Name Command Args Env Cwd Status Auth
chrome-devtools nc 127.0.0.1 3333 - - enabled Unsupported

• Ran codex mcp get chrome-devtools
└ chrome-devtools
enabled: true
… +5 lines
startup_timeout_sec: 20
remove: codex mcp remove chrome-devtools

───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

• The config is sane: chrome-devtools is enabled and points at nc 127.0.0.1 3333. I’ve started a clean codex exec run
that explicitly asks the agent to call list_pages; that will tell us whether the runtime can actually consume the MCP
tools even though /mcp claims there are none.

• Waited for background terminal · codex exec --json --dangerously-bypass-approvals-and-sandbox 'Use the chrome-
devtools MCP tool list_pages and reply only with the number of open pages.'

• As of April 5, 2026, Chrome MCP is working on your machine, but /mcp is still misreporting it.

What I verified locally:

• codex --version returns codex-cli 0.118.0
• codex mcp list shows chrome-devtools enabled with nc 127.0.0.1 3333
• A raw MCP handshake plus tools/list against 127.0.0.1:3333 returns the full Chrome tool set from chrome_devtools

0.17.1

• A fresh codex exec --json run actually performed mcp_tool_call server:"chrome-devtools" tool:"list_pages" and

returned the current 4 open pages

So the important distinction is:

• Runtime MCP tool use: working
• /mcp TUI/status display: still broken, showing Tools: (none) incorrectly

One part of /mcp is accurate:

• Resources: (none) and Resource templates: (none) are expected here, because this Chrome MCP server does not

implement resources/list or resources/templates/list; it returns Method not found

So the re-review conclusion is: this is still a display/discovery bug in /mcp, not a Chrome MCP connectivity failure.
If you want, I can also dig into whether there’s a known fix past 0.118.0 or help build a minimal repro transcript
for the GitHub issue.

• Ran codex exec --json --dangerously-bypass-approvals-and-sandbox 'Use the chrome-devtools MCP tool list_pages and
│ reply only with the number of open pages.'
└ Reading additional input from stdin...
{"type":"thread.started","thread_id":"019d5e58-7f4a-7a32-8dda-575fe7265d92"}
… +17 lines
{"type":"item.completed","item":{"id":"item_2","type":"agent_message","text":"4"}}
{"type":"turn.completed","usage":{"input_tokens":32109,"cached_input_tokens":19328,"output_tokens":131}}

codex is able to use chrome-devtools, but /mcp still has erroneous output.

renaming the mcp tool results in:
```• It changes very little for actual tool use, but it does remove a naming mismatch.

  What I verified now:

  - Your config key is [mcp_servers.chrome_devtools]
  - codex mcp list now shows chrome_devtools
  - codex mcp get chrome_devtools resolves cleanly

  For me, the important part is this:

  - The MCP tool namespace I already have is underscore-based: mcp__chrome_devtools__...
  - The raw Chrome MCP server had also been identifying itself as chrome_devtools

  So the rename mainly aligns these three names:

  - config key: chrome_devtools
  - server name: chrome_devtools
  - tool namespace: mcp__chrome_devtools__*

  Practical effect:

  - Commands and references should now use chrome_devtools, not chrome-devtools
  - It likely reduces the chance of UI/discovery weirdness caused by hyphen-to-underscore normalization
  - It does not by itself prove /mcp will stop showing Tools: (none); that underlying display bug may still exist

  So the short answer is: for me, this is mostly a cleanup/alignment change, not a capability change. If anything, it
  makes the setup more correct and less ambiguous.


› it did for the /mcp issue, I see "  • chrome_devtools
      • Auth: Unsupported
      • Command: nc 127.0.0.1 3333
      • Tools: click, close_page, drag, emulate, evaluate_script, fill, fill_form, get_console_message,
  get_network_request, handle_dialog, hover, list_console_messages, list_network_requests, list_pages, navigate_page,
  new_page, performance_analyze_insight, performance_start_trace, performance_stop_trace, press_key, resize_page,
  select_page, take_screenshot, take_snapshot, upload_file, wait_for
      • Resources: (none)
      • Resource templates: (none)
  "


• That confirms the bug was name normalization, not Chrome MCP itself.

  The likely failure mode was:

  - your config entry was chrome-devtools
  - the server/tooling path normalizes or expects chrome_devtools
  - /mcp was failing to join the discovered tool list back to the configured server entry, so it rendered Tools: (none)

  After renaming to chrome_devtools, the identifiers now line up:

  - config key
  - server-reported name
  - tool namespace

  So the corrected conclusion is:

  - Chrome MCP was working before
  - /mcp was misreporting because of the hyphenated server name
  - renaming to chrome_devtools fixed discovery/rendering in the CLI

  Resources: (none) and Resource templates: (none) are still expected for this server.