Windows App Server direct-stdio synthetic turn has one observed Responses transport failure on CLI 0.145.0

Problem Statement

On Windows 11 Pro, version 25H2 (build 26200), one post-update direct-stdio Codex App Server synthetic turn using CLI 0.145.0 and gpt-5.6-terra reached the outbound Responses transport stage but ended in a transport disconnect and App Server exit code 1. This is one observed failure, not a claim of intermittent or consistent behavior.

An earlier model-version incompatibility was resolved by updating the CLI: the prior model-version error did not recur in this run. This report describes only the subsequent direct-stdio transport failure.

Minimal Safe Reproduction Context

• Direct JSONL-over-stdio App Server lifecycle.
• Initialization response, initialized notification, isolated thread, and one harmless synthetic turn.
• An evidence-sink preflight passed before execution.
• No bridge, cockpit, dispatcher, Factory Acceptance Suite case, endpoint, or real workflow was involved.
• A streaming Responses request was observed. Non-streaming behavior was not tested.

Observed Behavior

Directly observed facts

• The App Server completed initialization, created an isolated thread, and started the single synthetic turn.
• The synthetic user-message item completed; no assistant item or completed-turn notification was observed.
• Stderr recorded that a startup WebSocket connection attempt failed with a socket-access error.
• The public-safe evidence does not retain a shareable exact startup WebSocket error class or message.
• The later terminal error reported: stream disconnected before completion: error sending request (safely redacted); its retained error classification was other.
• Correlation-ID status: not retained in public-safe evidence. No identifier value is included.
• The process exited with code 1.
• The earlier model-version incompatibility error was absent.

Source-supported inference

Version-matched 0.145.0 source review identified HTTP fallback logic associated with certain WebSocket failures. This does not prove a universal WebSocket-to-HTTP sequence, a completed fallback in this run, or the cause of this host's failure.

Unknowns

• Whether the observed startup WebSocket socket-access error and later HTTPS Responses request share one cause.
• Whether any HTTP fallback logic applies to this specific failure path or completed in this run.
• Whether Codex sandbox semantics, Windows policy, firewall/endpoint controls, upstream routing, or another host/network condition affected the transport.
• TLS inspection/custom root CA status: unknown.

Expected Behavior

When outbound transport is unavailable or restricted, a supported explanation, diagnostic, fallback outcome, or actionable error would help identify the next safe step. This report does not claim that successful completion was guaranteed under every host policy.

Relevant Limited Observations

No ordinary manual proxy, PAC/WPAD, WinHTTP proxy, or standard proxy-environment-variable indication was found. No Codex network restriction was proven, while Codex sandbox semantics and Windows Software Restriction Policy applicability remained ambiguous. These are limited observations only; they do not prove that no host or network restriction exists.

Current Codex release material may include system-proxy and custom-certificate-authority handling relevant to Responses WebSockets. This report makes no claim that this host uses a proxy, TLS inspection, or a custom CA.

Questions for Maintainers

1. Is this symptom known for Windows App Server use over direct stdio?
2. Is there a supported, privacy-safe diagnostic that can establish whether system-proxy or custom-certificate-authority conditions are relevant on this host?
3. What supported diagnostic can safely distinguish Codex sandbox restrictions from host policy or network controls?
4. Does any applicable HTTP fallback logic apply to this failure path?
5. Public-safe evidence did not retain correlation IDs. What privacy-safe identifier or diagnostic would maintainers prefer for correlation?
6. Would a specific, safe additional redacted diagnostic make the report actionable?

Environment Information

• Windows 11 Pro, version 25H2, build 26200.
• Codex CLI 0.145.0.
• Model: gpt-5.6-terra.
• Direct JSONL-over-stdio App Server lifecycle with one isolated synthetic turn.
• The failing-turn timestamp and timezone were not retained in the public-safe record.
• Correlation-ID status: not retained in public-safe evidence.
• TLS inspection/custom root CA status: unknown.
• One post-update failure was observed; reproducibility beyond that one run is unknown.

No machine name, username, local path, IP address, organization detail, account identifier, raw thread/turn/request/session identifier, credential, token, cookie, authorization value, environment-variable value, certificate, raw log, or trace is included.