[BUG] codex exec: MCP tools from `tools/list` are not injected into the model's tool set

Environment

• codex-cli version: codex-cli 0.147.0-alpha.6.6（alpha channel）
• OS: Windows 11 (native, x64)
• MCP server type: streamable HTTP (ASP.NET / IIS), responses encoded as SSE (Content-Type: text/event-stream), stateless (no Mcp-Session-Id header returned)
• Server side verified healthy: direct curl initialize / notifications/initialized / tools/list returns 200/202/200 with the full tool list

config.toml (minimal repro)

[mcp_servers.example-erp]
enabled = true
url = "http://<mcp-host>/mcp"

[mcp_servers.example-erp.http_headers]
Authorization = "Bearer <token>"

Steps to reproduce

1. Configure a streamable HTTP MCP server as above (server returns tools via tools/list).
2. Run:

   codex exec --json --skip-git-repo-check --sandbox workspace-write -C <temp-dir> -m <model> -c notify=[] "Call the MCP tool <tool> and return the result."
   

3. Observe the agent's available tool set.

Expected behavior

Tools returned by tools/list are registered and callable by the model — as in Codex desktop (ChatGPT app) with the same config, where the same tools are visible and usable.

Actual behavior

The model reports the tools do not exist (e.g. "no erp_describe / erp_query tool in this session"). The MCP connection itself works fine:

• codex sends initialize → notifications/initialized → tools/list and receives 200 with all tools (verified by a local reverse proxy capturing the actual HTTP exchange).
• list_mcp_resources with server=<id> reaches the server and returns -32601: Method 'resources/list' is not available — proving the connection and authentication are working (a wrong token would have produced 401).
• The model's tool set only contains built-in tools (shell_command, list_mcp_resources, ...); no tools from tools/list appear.

Config variants tried (none changed the behavior)

• http_headers static Authorization (original)
• bearer_token_env_var instead of the static header
• explicit enabled_tools allowlist listing all server tools
• -c features.tool_call_mcp_elicitation=false
• approval_policy = { granular = { sandbox_approval=true, rules=true, mcp_elicitations=true, request_permissions=true, skill_approval=true } }
• --sandbox read-only vs workspace-write; with/without -C and --skip-git-repo-check; temp dir vs trusted project dir
• direct connection vs local reverse proxy

Diagnostics already performed

• codex mcp list / codex mcp get <id> / codex doctor: server shown as enabled, transport streamable_http, auth "Bearer token", doctor reports MCP servers healthy (0 disabled, 0 failed).
• RUST_LOG=codex_core=trace,reqwest=trace: shows the HTTP connection to the MCP host and the completed handshake, but no tool registration from the tools/list response.
• Feature flags in this build: tool_call_mcp_elicitation = stable/true, mcp_2026_07_28 = under development/false, non_prefixed_mcp_tool_names = under development/false.

Impact

This blocks headless/non-interactive codex exec usage with streamable HTTP MCP servers (agent cannot use any MCP tool), while interactive clients (desktop) work with the identical configuration.

Version

codex --version → codex-cli 0.147.0-alpha.6.6

Start at the codex exec MCP initialization path and trace the tools/list response into the model's tool set. Reproduce with the minimal streamable HTTP configuration and verify that the returned tools become callable in codex exec without changing authentication or transport.