app-server: any per-thread `config` override on thread/start makes subsequent turns hang (0.154.0)

Summary

On codex-cli 0.154.0 (codex app-server --stdio), passing any per-thread config override to thread/start causes the subsequent turn/start to hang indefinitely: no reasoning/agentMessage events, no error, no timeout. This makes per-thread config overrides (e.g. mcp_servers registration) unusable.

Reproduction

JSON-RPC over stdio against codex app-server --stdio:

1. initialize (capabilities.experimentalApi=false) → ok
2. thread/start with { cwd, ephemeral: true, sandbox: "read-only", approvalPolicy: "never", config: { model_reasoning_effort: "high" } } → returns a thread id (no error). Note: this is a benign override — no MCP involved.
3. turn/start with a text input → turn/started, item/started userMessage, item/completed userMessage … then silence forever (>120 s observed). No turn/completed, no error notification.

Control: the identical sequence without config completes normally.

With config: { mcp_servers: { ... } } the MCP server does spawn (mcpServer/startupStatus/updated: ready), so the override is partially honored — but turns still hang, so the feature cannot be used.

Related protocol gaps observed on 0.154.0

• thread/start param mcpServers (camelCase object) is silently ignored — no error, no startup. Same failure mode as the legacy sandboxPolicy object.
• mcpServer/elicitation/request left unanswered never times out; the thread stays in waitingOnApproval indefinitely. Clients must implement their own timeout and explicitly answer { action: "decline" }.

Environment

codex-cli 0.154.0, Linux x86_64, app-server over stdio.

Start by reproducing the JSON-RPC sequence against the codex app-server --stdio entry point, comparing thread/start with and without config before issuing turn/start. Trace how per-thread overrides are applied between these requests and add a regression test showing that a configured turn emits completion events rather than hanging.