[Windows][0.147.0] Python SDK stalls at turn/start while bundled CLI stalls later in Responses sampling stream

Summary

On Windows, Codex 0.147.0 repeatedly fails to complete real non-interactive turns through two independent client paths:

1. openai-codex Python SDK: thread creation succeeds, but starting the turn never returns a TurnHandle.
2. Bundled codex exec --json CLI: thread.started and turn.started are emitted, but the Responses sampling stream disconnects and the turn never emits a terminal JSONL event before a bounded watchdog terminates it.

The two paths fail at different client layers but converge on the same Codex/app-server/Responses execution stack. No repository mutation occurred in the failed probes.

Environment

• Windows x64
• openai-codex: 0.147.0
• openai-codex-cli-bin: 0.147.0
• bundled codex-cli: 0.147.0
• Authentication: saved ChatGPT account authentication reuse
• API key: not used for these probes

Python SDK reproduction

Observed lifecycle:

A4_WORKER_STARTED
ACCOUNT_READY
THREAD_CREATED
TURN_START_REQUESTED
(no TURN_HANDLE_ACQUIRED)

One earlier occurrence logged:

lone leading surrogate in hex escape at line 1 column 661

A later independent occurrence preserved no protocol stderr, but reproduced the same last valid phase:

THREAD_CREATED
→ TURN_START_REQUESTED
→ no TurnHandle

The two prompts were independently checked and were valid strict UTF-8, contained no surrogate code points, NULs, forbidden control characters, or malformed Unicode escapes, and passed local JSON serialization/deserialization round trips. They were approximately 5 KB each.

The Python SDK response waiter has no observed terminal response before the external 30-second hard watchdog. The process tree was then contained successfully.

Bundled CLI control probes

The bundled codex.exe from openai-codex-cli-bin 0.147.0 was invoked using non-interactive JSONL mode in disposable directories.

Two independent probes both reached:

thread.started
turn.started

and then produced no terminal JSONL event before a 45-second hard ceiling.

Both stderr streams reported a model-cache incompatibility involving missing supports_parallel_tool_calls, followed by a Responses stream disconnect and a sampling request timeout entering retry 1/5.

The second probe used a disposable Git repository containing:

smoke_target.txt = BEFORE

Codex never reached a file operation. After timeout, the file was still exactly BEFORE and Git remained clean. Both process trees were contained and no bundled codex.exe survived.

Important control observation

The CLI path bypasses the Python SDK synchronous turn-start / TurnHandle waiter, but still fails later at the Responses sampling stream.

Therefore the observed failure is not explained solely by the Python SDK's TurnHandle acquisition waiter.

Expected behavior

A non-interactive Codex turn should either:

• reach a terminal response;
• return a structured transport/network error; or
• fail within a bounded transport deadline.

It should not remain non-terminal without a machine-readable final result.

Actual behavior

Python SDK:

thread created
→ turn/start requested
→ no TurnHandle

Bundled CLI:

thread.started
→ turn.started
→ Responses stream disconnect
→ sampling timeout/retry
→ no terminal result within bounded watchdog

Related issues

Potentially related, but not exact duplicates:

• #27395 — turn/start timeout while app-server sidecar stalls
• #39572 — Responses streams remain non-terminal after network interruption
• #19821 — Responses WebSocket failures before HTTP fallback

This report adds a same-machine, same-version control comparison between the Python SDK and bundled CLI execution paths.

Evidence limitation

The exact app-server fault is not proven. In the later Python SDK reproduction, app-server stderr was not persisted outside the SDK's in-memory buffer, so an underlying protocol error cannot be confirmed or excluded. The strongest supported classification is a turn-start response-waiter stall without a captured protocol error, together with a separate CLI reproduction of a downstream Responses transport failure.

Privacy

No project source, credentials, cookies, auth files, API keys, full prompts, or private repository paths are included. Sanitized timestamps and lifecycle logs can be provided if useful.

Start with the Windows reproductions described in the issue, tracing Python SDK turn/start response handling and the bundled codex exec --json Responses stream; the report names no repository files or tests. Done means each path returns a terminal result, structured transport error, or bounded failure instead of a non-terminal stall.