0.112.0 hangs / shows extreme latency on WSL after tool execution; 0.111.x is stable

Summary

After upgrading Codex CLI from 0.111.x to 0.112.0, codex exec became flaky and often hangs or takes much longer to finish on WSL.

The same prompt, same repo, same provider, same machine:

• 0.111.x usually finishes in about 13s
• 0.112.0 is inconsistent: sometimes 11-12s, sometimes 30-68s, sometimes it hangs until timeout

This looks like a CLI/runtime regression rather than a provider/proxy issue.

Environment

• Codex CLI: 0.112.0
• Comparison version: 0.111.x
• OS: WSL (Arch Linux)
• Mode: codex exec
• Sandbox: read-only
• Approval: never
• Model: gpt-5.4
• Reasoning effort for repro: none
• Provider: custom OpenAI-compatible provider over Responses API

What I observed

On 0.112.0, simple repo-aware prompts are flaky. In failed runs, Codex sometimes:

• stops after mcp startup: no servers
• or performs a successful local tool call (for example rg) and then never returns the final answer

I verified that the upstream request itself completes:

• my proxy receives POST /backend-api/codex/responses
• it returns 200
• the streamed response completes
• but Codex CLI still hangs afterwards

That strongly suggests the hang is happening inside the CLI runtime/tool loop after the upstream response path is already healthy.

Minimal repro in my environment

Command:

npx -y @openai/codex@0.112.0 exec \
  --cd /path/to/repo \
  --ephemeral \
  --color never \
  -s read-only \
  -c 'model_reasoning_effort="none"' \
  'Name only one file path where log_proxy_service_tier_trace is defined.'

Expected

A quick final answer with a single file path.

Actual

With 0.112.0, results are inconsistent:

• successful runs: roughly 11s / 22s / 55s
• other runs: 70-90s timeout
• in hanging runs, output often stops after MCP startup or after a successful rg tool call

A/B results

Same repo and same prompt:

• 0.111.x: stable, usually around 13s
• 0.112.0: flaky, large latency variance, occasional full hangs

Workarounds tested

These improved things, but did not fully eliminate the problem:

• multi_agent = false
• --disable unified_exec (best workaround I found)
• disabling MCP servers did not remove the issue completely

Downgrading to 0.111.x is the only workaround that fully removed the slowdown for me.

Important note

This report is about 0.112.0 with model_reasoning_effort="none".

I also observed separate bad behavior with xhigh, but that appears to be a different issue and I am not mixing it into this report.

Question

Is there a known regression in 0.112.0 around:

• WSL
• post-tool-call completion
• unified_exec
• or custom Responses API providers?

If needed, I can provide:

• stderr from successful vs hanging runs
• exact timing samples
• proxy logs showing upstream completed while the CLI remained stuck