[Windows x86-64][Python SDK 0.144.4] app-server preflight succeeds but first turn terminates failed/other

What issue are you seeing?

Using the official Python SDK on Windows x86-64 with Python 3.11.15, the SDK-pinned app-server runtime initializes successfully. In a fresh process:

• openai-codex==0.144.4
• openai-codex-cli-bin==0.144.4
• ChatGPT account state: authenticated
• gpt-5.6-luna is present in the model catalog
• An ephemeral read-only thread starts successfully

The first and only text turn then reaches its public terminal completion event without returning a response, finish reason, or usage.

Sanitized structured fields:

class=CodexOAuthInvocationError
code=sdk_turn_run_failed
stage=turn_run
cause_type=TurnCompletedFailure
turn_status=failed
codex_error_code=other
diagnostic_source=turn_completed
turn_completed_event_received=true

No free-form error message, raw event, exception chain, authentication material, account identity, request/thread/turn identifiers, backend URL, HTTP status, command line, environment dump, or local path was collected for this report.

What steps can reproduce the bug?

1. Authenticate the official Codex SDK through ChatGPT.
2. Start a fresh SDK/app-server process in a temporary empty working directory.
3. Query the public account state with refresh_token=False.
4. Query models with hidden models included and confirm gpt-5.6-luna is present.
5. Start one ephemeral thread with read-only sandboxing and deny-all approvals.
6. Send exactly one minimal text turn and consume events through the public terminal turn-completed event.

Minimal pseudocode:

with temporary_empty_working_directory() as cwd:
    config = CodexConfig(
        cwd=cwd,
        sandbox="read-only",
        approval_policy="deny-all",
        local_surfaces_disabled=True,
    )

    async with AsyncCodex(config=config) as client:
        assert (await client.account(refresh_token=False)).authenticated
        assert "gpt-5.6-luna" in await client.models(include_hidden=True)

        thread = await client.thread_start(
            model="gpt-5.6-luna",
            ephemeral=True,
        )
        events = thread.turn("Return one fixed ASCII marker only")
        consume_until_public_turn_completed(events)

The reproduction uses no tools, no repository context, no retry, and no model or provider fallback.

What is the expected behavior?

After account, model-catalog, and ephemeral-thread preflight succeeds, the minimal text turn should return the requested marker with a finish reason and aggregated usage.

If the turn cannot run, the SDK/app-server should expose a documented structured, non-sensitive error classification more specific than other.

Additional information

The same terminal result was reproduced after one public account refresh and again after other Codex surfaces had been closed, using a fresh app-server process. This does not establish the internal cause of other.

Release comparison at the time of reporting:

• Latest official standalone Codex CLI observed: 0.145.0.
• Latest stable Python SDK and official pinned runtime observed: 0.144.4.
• The standalone CLI was not substituted for the SDK-pinned runtime.
• PR #32280 appears to add an optional error payload to the terminal turn event. It may improve safe diagnostics, but this report does not claim that it fixes the underlying failure.

Questions:

1. Is this terminal failed/other path a known issue in Python SDK/runtime 0.144.4 on Windows?
2. Does standalone CLI 0.145.0 contain an underlying fix, or only improved terminal-error diagnostics?
3. When should matching stable Python SDK and pinned-runtime releases become available?
4. Is there another documented, structured, non-sensitive public field that can safely distinguish this failure beyond other?

turn_status=failed
codex_error_info=other
qep_error_code=CODEX_TURN_FAILED_OTHER