`codex exec` on Windows silently drops `custom_tool_call` items received from a custom Responses provider (0.152.0 & 0.152.1)

Environment

• codex-cli 0.152.0 (standalone) and 0.152.1 (desktop-bundled binary, invoked as codex exec)
• Windows 11 Pro 23H2 (10.0.22631), x86_64
• Custom model provider: wire_api = "responses", base_url pointing to a local OpenAI-compatible Responses gateway
• Models: gpt-5.6-sol / gpt-5.6-luna (reproduces with both)

Summary
In non-interactive codex exec mode on Windows with a custom Responses provider, the client receives a complete custom_tool_call output item in the SSE stream (139 response.custom_tool_call_input.delta events, status: completed), parses the full response (its reported turn.completed usage matches the wire usage exactly), but then silently discards the tool call: no execution, no follow-up request with the tool output, no error, exit code 0. The session ends after a single upstream request with only the text portion emitted.

What we verified at wire level (recording reverse proxy between codex and the gateway)

1. Upstream response contains 3 output items: reasoning, message, custom_tool_call (name=exec, status=completed).
2. Client's reported usage matches the wire response exactly (it received and parsed everything).
3. Client sends exactly 1 upstream request; a tool-executing session would require >= 2.
4. Exit code 0; the dropped tool call is invisible to the caller.

Ruled out by A/B testing

• Not the request payload: the byte-identical Windows-generated request body replayed via curl against the same gateway consistently yields tool calls that a Linux client executes fine (6/6 replays).
• Not the headers: full codex header set present in the failing live capture; upstream still returned the tool call.
• Not sandbox/approvals: reproduces identically with --dangerously-bypass-approvals-and-sandbox (danger-full-access).
• Not the CLI version alone: reproduces on both 0.152.0 and 0.152.1.
• Not the platform's network path: same machine, same gateway, same account seat.
• Linux (Ubuntu 24.04, codex 0.152.0, same provider config, same prompt) enters the tool loop normally (16 command executions).
• Desktop app sessions on the same Windows machine (same bundled 0.152.1 binary, codex_work_desktop originator, official provider) process 30-50+ custom_tool_call events per session without issue — including one running concurrently at the exact minute an exec session dropped its tool call.

Repro steps

1. On Windows, configure a custom provider with wire_api = "responses" (any OpenAI-compatible Responses endpoint that returns custom_tool_call items).
2. codex exec -m <model> -C <dir> "Read the first line of hello.txt in the current directory and tell me exactly what it says"
3. Observe: upstream SSE contains custom_tool_call (exec_command reading the file); codex prints at most the message text and exits 0 without executing the tool or sending a follow-up request.

Expected: execute the custom tool call and continue the turn (as on Linux), or at minimum surface an error.

Possibly related: #37718, #31894

Wire-level evidence (redacted SSE streams, request bodies, request/response summaries) available on request.

Start by tracing the codex exec Responses/SSE handling for custom_tool_call items on Windows, using the local OpenAI-compatible gateway and wire-level capture described in the issue. Compare the Windows path with the working Linux behavior; done means the tool executes and receives a follow-up request, or the client surfaces an error instead of exiting successfully.