Bundled messages / computer-use MCP servers fail to initialize on Codex 0.154.0 — client's capabilities.experimental rejected with JSON-RPC -32603

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

0.154.0

What subscription do you have?

Business Plan

What platform is your computer?

macOS | 27.0 (Darwin 27.0.0), Apple M5 (arm64) |

What issue are you seeing?

Bundled messages / computer-use MCP servers fail to initialize on Codex 0.154.0 — client's capabilities.experimental rejected with JSON-RPC -32603

Summary

messages@openai-bundled and computer-use@openai-bundled are installed, enabled, and registered (codex mcp list shows the messages server), but the MCP handshake fails in every session, so no mcp__messages__* / mcp__computer-use__* tools are ever registered. The connector is silently unusable — no error surfaces in the UI, codex mcp list looks healthy, and the server binary itself is fine.

Root cause: the Codex client advertises

"capabilities": {"experimental": {"codex/auth-change": {}}, "elicitation": {"form": {}, "url": {}}}

in initialize. The bundled SkyComputerUseClient MCP server cannot decode capabilities.experimental and answers with a JSON-RPC protocol error, so Codex marks the server failed and drops its tools:

MCP server startup failed server_name="messages"
  error=handshaking with MCP server failed: JSON-RPC error: -32603:
  Internal error: The data couldn't be read because it isn't in the correct format.

Environment

macOS	27.0 (Darwin 27.0.0), Apple M5 (arm64)
Codex CLI	codex-cli 0.154.0 (Homebrew cask codex; 0.153.4 previously)
Codex app	/Applications/ChatGPT.app, bundled codex-cli 0.154.0-alpha.6.2, Codex Framework 152.0.7977.83
Plugin	messages@openai-bundled 1.0.1000968; computer-use@openai-bundled 1.0.1000968
MCP server	bin/computer-use-client-launcher messages mcp → ~/…/SkyComputerUseClient.app/Contents/MacOS/SkyComputerUseClient (bundle id com.openai.sky.CUAService.cli, Team ID 2DC432GLL2)
Server identity	serverInfo: {"name":"Messages","version":"387913d396515920cfbb7ad1a9580eb9649b2cdb69cac914d276e850a42b1c5a"}

Reproduction

1. Deterministic, no Codex needed (pure stdio MCP)

Invoke the connector's MCP server binary directly — this works on a stock install and is unaffected by any local launcher patching:

CLIENT="$HOME/.codex/computer-use/Codex Computer Use.app/Contents/SharedSupport/SkyComputerUseClient.app/Contents/MacOS/SkyComputerUseClient"

# failing case (what Codex 0.154.0 sends)
printf '%s\n' '{"jsonrpc":"2.0","id":0,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{"experimental":{"codex/auth-change":{}},"elicitation":{"form":{},"url":{}}},"clientInfo":{"name":"codex-mcp-client","title":"Codex","version":"0.154.0"}}}' \
  | CODEX_HOME="$HOME/.codex" timeout 20 "$CLIENT" messages mcp

# control: same request without capabilities.experimental
printf '%s\n' '{"jsonrpc":"2.0","id":0,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{"elicitation":{"form":{},"url":{}}},"clientInfo":{"name":"codex-mcp-client","title":"Codex","version":"0.154.0"}}}' \
  | CODEX_HOME="$HOME/.codex" timeout 20 "$CLIENT" messages mcp

Failing case (also reproduces with the computer-use plugin's launcher, or with …/plugins/cache/openai-bundled/messages/<ver>/bin/computer-use-client-launcher messages mcp on an unpatched install):

{"error":{"code":-32603,"data":{"detail":"The data couldn't be read because it isn't in the correct format."},"message":"Internal error: The data couldn't be read because it isn't in the correct format."},"id":0,"jsonrpc":"2.0"}

Control case: result.serverInfo.name = "Messages" with capabilities.tools.

2. Through Codex

RUST_LOG=warn codex exec --skip-git-repo-check "reply with exactly: hi" 2>&1 \
  | grep -E 'MCP server startup failed server_name="(messages|computer-use)"'

Observed: one failure per server per session (mcp.runtime.refresh / mcp.runtime.refresh_if_dirty), and an agent turn asked to call mcp__messages__find_chats replies TOOL_MISSING.

Bisection (single-variable, against the same server binary)

initialize.params.capabilities	result
{}	OK — serverInfo.name = "Messages"
{"elicitation":{}}	OK
{"elicitation":{"form":{},"url":{}}}	OK
{"experimental":{"codex/auth-change":{}}}	-32603
{"experimental":{"codex/auth-change":{}},"elicitation":{"form":{},"url":{}}} (what Codex sends)	-32603

Also ruled out as triggers: clientInfo.title, and protocol versions 2024-11-05 / 2025-06-18 / 2025-11-25 (all OK). With experimental removed the server completes the handshake and returns its six tools (find_chats, read_messages, search_messages, send_message, count_message_activity, read_image).

Not the cause

• Not plugin state: codex plugin list → messages@openai-bundled installed, enabled 1.0.1000968; codex mcp get messages → enabled: true with correct command/args/cwd.
• Not a CLI-vs-app version skew: codex CLI 0.154.0 and the app's bundled 0.154.0-alpha.6.2 both contain the codex/auth-change capability, and both fail — aligning the two versions changes nothing. The skew is client ↔ bundled server, and the server ships inside the app bundle.
• Not macOS permissions or sync: the failure happens at initialize, before any Messages access. (Independently, Automation for "Codex Computer Use → Messages" is already granted in System Settings.)
• Not a stale cache: the same failure reproduces from both ~/.codex/plugins/cache/openai-bundled/messages/1.0.1000968/ and the marketplace source ~/.codex/.tmp/bundled-marketplaces/openai-bundled/plugins/messages/.

Suggested fixes (either direction)

1. Server side (preferred) — make the SkyComputerUseClient MCP server ignore unknown/experimental capability keys instead of failing the handshake. It currently appears to decode initialize strictly; unknown-key tolerance (or at least tolerating experimental) restores both bundled connectors.
2. Client side — don't advertise experimental to stdio servers that don't opt in, or gate codex/auth-change behind per-server capability negotiation (e.g. only advertise it after the server declares support, or allow opting out per MCP server in config.toml).

Local workaround used here (for reference, not a ship request)

Replace the plugin launcher with a shim that strips only that one capability and forwards everything else byte-for-byte. Installed in both the cache copy and the marketplace source; originals preserved alongside:

#!/bin/bash
set -u
codex_home="${CODEX_HOME:-${HOME}/.codex}"
client="${codex_home}/computer-use/Codex Computer Use.app/Contents/SharedSupport/SkyComputerUseClient.app/Contents/MacOS/SkyComputerUseClient"
while IFS= read -r line; do
  case "${line}" in
    *'"method":"initialize"'*)
      filtered=$(printf '%s' "${line}" | /usr/bin/jq -c \
        'if (.method? == "initialize") and (.params.capabilities?.experimental? != null)
         then del(.params.capabilities.experimental) else . end' 2>/dev/null)
      if [ -n "${filtered}" ]; then printf '%s\n' "${filtered}"; else printf '%s\n' "${line}"; fi ;;
    *) printf '%s\n' "${line}" ;;
  esac
done | exec "${client}" "$@"

Result with the shim: MCP server startup failed server_name="messages" → 0 per session, and a live turn successfully invoked mcp__messages__find_chats (server messages). Caveats: an app update overwrites both launcher copies, and network policy should treat this as a local patch, not a supported configuration.

Additional observation (possibly a second, unrelated issue)

With the handshake fixed, the tools register but actual calls hang and then time out in the Messages AppleEvent layer:

Error Domain=NSOSStatusErrorDomain Code=-1712 "errAETimeout: the AppleEvent timed out"

Automation consent for Codex Computer Use → Messages is toggled on in System Settings → Privacy & Security → Automation, and Messages is running. Worth a look if the team wants the connector working end-to-end on this configuration.

What steps can reproduce the bug?

See above

What is the expected behavior?

See above

Additional information

No response

Start with the direct SkyComputerUseClient stdio reproduction and the initialize request described in the issue, then trace how the bundled messages and computer-use launchers handle MCP capabilities. Confirm the failure with capabilities.experimental and the control case without it. Done means the handshake succeeds without a local shim and the bundled tools register; the AppleEvent timeout is listed as a separate concern.