ChatGPT-bundled Codex 0.148.0-alpha.9 fails a Streamable HTTP MCP tool call that passes in 0.147.0

Environment

• Platform: macOS arm64
• ChatGPT Desktop: 26.810.50856
• Bundled Codex CLI: 0.148.0-alpha.9
• Standalone control: Codex CLI 0.147.0
• MCP transport: authenticated Streamable HTTP on localhost

All server names, token names, ports, local paths, session identifiers, and filesystem roots have been anonymized.

Configuration

[mcp_servers.example]
url = "http://127.0.0.1:<port>/mcp"
bearer_token_env_var = "EXAMPLE_MCP_TOKEN"

Issue

An MCP read-only tool succeeds from standalone Codex 0.147.0 but fails from the Codex 0.148.0-alpha.9 executable bundled with ChatGPT.

The failure reproduces even when the bundled executable is launched from a terminal where the configured bearer-token variable is explicitly present.

Controlled reproduction

Both tests used the same:

• shell and inherited environment
• MCP configuration
• authenticated server
• working directory
• read-only sandbox
• model
• prompt

The prompt requested exactly one call to a read-only MCP tool.

Bundled 0.148.0-alpha.9

mcp: example/read_only_tool started
mcp: example/read_only_tool (failed)

Error calling tool 'read_only_tool':

The error message after the colon is empty.

Standalone 0.147.0

mcp: example/read_only_tool started
mcp: example/read_only_tool (completed)

PASS

Additional controls

• The server returns HTTP 401 without authentication.
• An authenticated MCP initialize succeeds.
• The token variable was present in the shell used for both tests.
• No server, configuration, token, prompt, or sandbox changes occurred between tests.

Expected behavior

The bundled runtime should complete the same MCP tool call as standalone 0.147.0. If it cannot, it should expose the underlying MCP transport, authentication, or tool-call error instead of returning an empty error message.

Distinction from the Desktop environment problem

When ChatGPT is launched normally, its process does not inherit the configured bearer-token variable. That is separately related to #30125.

However, the version-controlled failure described here still occurs when 0.148.0-alpha.9 is launched directly from a terminal with the token explicitly inherited. The missing Desktop environment variable therefore does not explain this A/B result.

Related issues

• #38689 — codex exec and Streamable HTTP MCP tool exposure
• #37567 — version-specific MCP regression
• #30125 — missing bearer-token variable in the active Desktop process
• #37976 — earlier remote HTTP MCP Desktop regression

Reproduce the authenticated Streamable HTTP MCP call with the bundled 0.148.0-alpha.9 executable and standalone 0.147.0 using the same configuration and environment. Trace the MCP transport and tool-call error handling to determine why the bundled runtime returns an empty error; done means the call succeeds or exposes the underlying transport, authentication, or tool-call error.