[iOS Remote][Windows SSH] Disconnected / Codex execution failed after successful Windows version probe

What version of the Codex App are you using?

• Windows Store package: OpenAI.Codex 26.903.9818.0 (package status OK).
• Standalone Codex CLI and local app-server: 0.154.0.
• Last recorded iPhone ChatGPT version before updating: 1.2026.237 (33230022603).
• The owner subsequently installed the available App Store update on 11 September 2026 and reports the same failure. The exact post-update version and iOS version have not been captured; please do not treat the older build above as the confirmed current build.

What subscription do you have?

ChatGPT subscription authentication is in use; codex login status reports Logged in using ChatGPT. Subscription tier was not recorded for this report. No API-key authentication was configured for this test.

What platform is your computer?

Windows 11 Pro x64, version 10.0.26200, build 26200.
OpenSSH for Windows 9.5p2, LibreSSL 3.8.2.
Native Windows SSH endpoint on the same home LAN as the iPhone; the target is not a WSL SSH endpoint.

What issue are you seeing?

ChatGPT iPhone Remote cannot establish a usable Codex session on the Windows PC. Repeated retries remain Offline/Disconnected or show:

Codex execution failed.

An earlier screenshot says:

Could not connect to NUC over SSH. Check that the host name, port, network, credentials, and SSH service are correct.

However, timestamped host-side records from actual phone attempts show successful public-key authentication, successful execution of the app's Windows discovery/version probe, and then connection closure without a subsequent app-server relay bootstrap. Replaying the exact discovery command from a controller gives the same output.

This report does not establish an upstream root cause. It provides the observed failure boundary and discloses the local workaround below. We cannot inspect the iPhone's internal parser, SSH exit-status handling, or client logs.

Separately, the QR authorization route also fails after authorization with:

Pairing failed. Something went wrong while pairing. Try scanning the code again.

That error is screenshot-confirmed but has not been causally linked to the SSH failure. No QR codes, pairing material or credentials are included here.

What steps can reproduce the bug?

Reproduces on this owner's setup; not yet reproduced independently on a pristine second host.

1. Run the Windows app and install the standalone Codex CLI on PATH. Authenticate Codex with ChatGPT. Have the local app-server listening on its default private Unix-domain socket.
2. Configure a local SSH connection in ChatGPT iPhone Remote: Windows host on the same LAN, port 22, local user, ECDSA P-256 SEC1 PEM private-key authentication.
3. Enable/open that saved connection.
4. Observe repeated Offline/Disconnected states and eventually "Codex execution failed".
5. Correlate the phone's source address with OpenSSH/Operational events and the discovery probe metadata below.

The owner also updated the iPhone app and retried without resolving the issue.

Observed diagnostic sequence

The phone first sends a 600-character POSIX shell probe, followed by a 3354-character encoded PowerShell Windows probe. The POSIX probe fails on this native Windows setup; that failure alone is not evidence of the root cause.

The captured Windows probe:

• resolves (Get-Command codex).Source, with desktop install fallbacks;
• runs --version with output suppressed and exits 126 if execution fails;
• writes Windows;
• runs --version again and exits with its status.

Its actual response on the phone attempt:

exit code: 0
stdout bytes: 27
stderr bytes: 0
stdout, escaped: Windows\r\ncodex-cli 0.154.0\n
stdout SHA-256:
722a51b784f2359acac20817f268092c23cfbe96384ee5882cb2993dbbf0651c

Sanitized records, 11 September 2026; timestamps below are UTC:

{"time":"2026-09-11T09:18:11.835792+00:00","pid":14260,"event":"start","command_length":3354,"encoded":true,"tty":false}
{"time":"2026-09-11T09:18:12.529258+00:00","pid":14260,"event":"version_probe_result","code":0,"stdout_bytes":27,"stderr_bytes":0,"windows":true,"version":"0.154.0","stdout_sha256":"722a51b784f2359acac20817f268092c23cfbe96384ee5882cb2993dbbf0651c"}
{"time":"2026-09-11T09:18:12.530263+00:00","pid":14260,"event":"exit","code":0}

Matching OpenSSH events recorded public-key acceptance from the phone and connection closure afterward. Host-side instrumentation confirms generation/forwarding of those bytes and process exit; it does not prove how the iPhone consumed them.

No subsequent relay bootstrap was recorded for these failing attempts. The phone-generated codex-path and codex-proxy.ps1 files retained their previous day's timestamps.

A narrowly scoped CRLF-to-LF experiment forwarded the same version text as 26 bytes. Later attempts at approximately 11:39 UTC again showed successful version-probe execution and forwarding of normalized output; the owner still reports disconnection. This experiment did not establish a fix and is being retired.

Independent checks and their limits

The controller relay replay is expressly not claimed as a successful mobile connection. No completed model task or desktop-control operation from the iPhone has been demonstrated.

Local modifications and confounders

The failure originally occurred before a custom phone-key helper was introduced. The instrumented attempts above were made with that helper; this is not an untouched configuration.

During earlier troubleshooting:

• Installed the standalone Windows CLI because directly executing the Store-bundled executable over SSH failed.
• Corrected permissions on only the private app-server-control directory after an explicit socket-privacy error.
• Started the socket app-server under the normal, non-elevated Windows user with an at-logon task.
• Found the generated PowerShell RB @('app-server','proxy') relay could stall in controller reproduction. Added a forced-command Python helper only on the dedicated phone key, replacing that specific final relay invocation with native inherited standard handles.
• The first helper introduced its own nested-command quoting defect. This was reproduced and corrected. Quoted PowerShell discovery checks now match ordinary SSH; the iPhone failure persists after that correction.
• The current failing Windows version probe does not match the relay-rewrite signature. Bounded diagnostics on that exact captured read-only probe record only response metadata and forward output.
• Switched SSH from an exclusively held log file to standard Windows Event Viewer logging with VERBOSE level; authenticated controller access was verified afterward.

A controller VPN separately blocked controller-to-LAN traffic earlier. Closing it restored controller access. Subsequent actual phone authentication is proven, so that controller issue should not be presented as the explanation for this post-authentication mobile failure.

Expected behavior / maintainer assistance requested

The app should establish the session after valid discovery, or show the precise failing stage, command exit status and actionable diagnostic instead of a generic execution failure.

Please advise:

1. How to export a sanitized iPhone Remote diagnostic trace for the attempt after the successful Windows version probe.
2. Whether this response format and Windows SSH bootstrap are supported by the current iPhone build, and whether a known client-side issue can stop the flow at this boundary.
3. The smallest supported clean configuration needed to reproduce without the custom helper, while retaining working administrative access.
4. Whether the separate post-authorization QR failure needs a distinct ticket and which diagnostic identifier should be collected.

Related reports reviewed: #30791 (Windows proxy-process accumulation) and #39974 (mobile disconnections across devices). This report supplies a different observed boundary: successful Windows discovery followed by no relay launch, rather than claiming a confirmed duplicate or successful initialization from the phone.

Screenshots have been transcribed rather than uploading images containing local connection details. Private keys, QR contents, account identifiers, host fingerprints, private conversation content and tokens are omitted. No mobile session ID is available because a usable session never started.

Start with the Windows SSH discovery/version probe and the subsequent app-server relay bootstrap described in the issue, reproducing without the custom helper on a clean configuration. Compare the successful probe records with the missing relay launch and collect the iPhone Remote diagnostic trace. Done means the failing stage is reproduced and reported with an actionable status or a confirmed supported configuration.