[Windows] Local executor exits on registry timeout; persistent durable WebSocket open timeouts #52854

Summary

On Windows, an established Codex local executor connection disconnected, then an environment-registry request timeout caused the shared local executor to exit and restart automatically. Desktop logs also contain persistent WebSocket connection-establishment failures for hostKind=durable; the relationship between these failures and environment-status notifications is unknown.

Environment

• Client package: OpenAI.Codex 26.1007.2314.0
• Bundled codex build: 2e5e00daee91c61d
• Date: 2026-10-10
• All timestamps below are UTC.
• An existing loopback system proxy was enabled. The proxy process did not restart in the incident window. This establishes the proxy path, not proxy causation.

Local executor incident

• 09:24:13.602843: established Noise rendezvous connection disconnected, reason=read_error.
• 09:24:18.402050: reconnect failed, reason=websocket_error.
• 09:24:28.446: Local Work executor exited with code 1:
  environment registry request failed: route-aware request timed out.
• 09:24:29.448: automatic executor restart.
• 09:24:30.662494: new executor process started.
• 09:24:37.074: executor connected successfully.

The desktop main process stayed alive. No matching Windows sleep/restart, application crash/hang, network-profile or WLAN change events were found in 09:14–09:34. That does not exclude an unlogged network/proxy interruption.

Durable-host connection failures and bounded follow-up

In the same desktop session, durable connection attempts began at 07:10:53.129. The first error appeared at 07:11:08.159, followed by close code 1006 and failureReason=open_timeout, with initialized=false / wasInitialized=false. No successful initialization was found in the inspected metadata.

The user reported manually switching an existing proxy node around 10:04. In equal 30-minute windows, 09:34–10:04 and 10:04–10:34:

• Local rendezvous disconnections, reconnect WebSocket errors and registry-timeout exits were each 0 before / 0 after; this does not prove the node change fixed the issue.
• Durable-host close events were 56 before / 53 after, all code 1006.
• Across those 109 events: close failure reason was open_timeout 91 times and unknown 18 times. Corresponding exact WebSocket-error events had errorCode=unknown 91 times, ECONNRESET 15 times and ETIMEDOUT 3 times.
• Related metadata includes hostId=durable, thread_resume_requested, thread_resume_failed and vmProduct=unknown. The actual destination domain, HTTP status and useful request correlation ID were unavailable.

External environment-disconnected notifications arrived at 10:07:16 and 10:32:24; environment queries at 10:07:19 and 10:32:28 returned connected. No corresponding local executor disconnect/exit/restart was found. Nearby durable closes were at 10:06:53.832 and 10:32:16.159, but frequent retries make timestamp proximity insufficient to establish causation.

Requested investigation

1. Identify the durable host's service target and the failed connection-establishment stage; advise whether this Windows build has a relevant known issue.
2. Investigate the 09:24 registry timeout and why it terminates the shared executor rather than recovering.
3. Correlate the two environment notifications with their original server-side event times and connection/request lifecycle.

This report contains only sanitized versions, timestamps, errors and aggregate counts. No session transcript, raw logs, attachments, credentials, account information, local paths or project data are included. No client restart, installation or configuration change was performed by the diagnostic task. The 30-minute passive observation is complete; ongoing project work continues.