[Windows] Computer Use retains a rotated native-pipe UUID and never reconnects #41453

Summary

Why this is a new root fix, not another missing-pipe report: existing Windows reports cover cases where no Computer Use pipe is provisioned. This issue covers a different lifecycle defect: Desktop successfully creates and persists a new valid pipe, while an already-started Windows client keeps the previous valid-but-dead UUID. The duplicate and PR searches performed before publication found no previous public report that isolated this rotation path or validated the one-time authoritative refresh and reconnect fix below. Restarting the extension host was used only to prove the stale binding; it is not the proposed solution.

On Windows, an already-started Computer Use client can retain a dead native-pipe identifier after Codex Desktop replaces the Computer Use server with a new randomly named pipe. The client then repeatedly connects to the obsolete path and returns FILE_NOT_FOUND until the extension host is restarted.

This differs from reports where the native pipe is never provisioned: here both the old and new identifiers are valid product-generated values at different times, and the current authoritative value is already persisted.

Environment

• Windows 11
• Codex bundled Computer Use generation: 26.825.32147
• Computer Use runtime: cua_node/e4d75eceaa042f20

Root cause

1. Codex Desktop creates the Windows Computer Use server at a random pipe name:

   \\.\pipe\codex-computer-use-${randomUUID()}
   

2. The current identifier is persisted as SKY_CUA_NATIVE_PIPE_DIRECTORY in config.toml and copied into the node_repl environment when its thread configuration is built.

3. The Windows Computer Use client captured that value once in its constructor.

4. Unlike the macOS client, the Windows connection-failure path had no service ensure, no authoritative path refresh, and no reconnect.

5. After Desktop created a new UUID, the existing extension node_repl continued connecting to the old pipe and surfaced FILE_NOT_FOUND.

Restarting the Chrome plugin extension-host.exe recreated the plugin app-server and node_repl with the new pipe, which confirmed the stale binding, but restart is only a diagnostic recovery rather than the root fix.

Validated root fix

On a failed native-pipe connection, the Windows client now:

1. Reads the authoritative current SKY_CUA_NATIVE_PIPE_DIRECTORY from config.toml.
2. Compares it with the captured identifier.
3. If they differ, replaces the stale identifier and retries exactly once through the normal connection path.
4. Surfaces a repeated failure normally when the current path is unchanged.

There is no infinite retry loop, service restart, fixed delay, or fallback transport.

• Patched Windows client SHA-256: 978eb6e53bb4d61410f0c25144ca096bccab5ddf78deff630dbfa231ed722d8a
• Regression harness: mock native-pipe transport with a stale environment path and a different current config path.

Maintainer handoff: source-level implementation

The production fix should preserve this bounded state machine rather than copy the tested minified-module anchors:

connect(capturedPipe)
  success -> return connection
  FILE_NOT_FOUND ->
    currentPipe = readAuthoritativePersistedPipe()
    if currentPipe is non-empty and currentPipe != capturedPipe:
      capturedPipe = currentPipe
      retry normal connect exactly once
    else:
      surface original failure
  any repeated failure -> surface normally

Required regression tests:

• Stale captured path plus a different live persisted path produces exactly stale -> FILE_NOT_FOUND -> fresh -> success.
• When the persisted path equals the captured path, there is no retry.
• When the refreshed path also fails, there is exactly one retry and the second failure is surfaced.
• Missing or malformed persisted configuration does not create a retry loop.
• A running Windows client survives a real Desktop pipe rotation without restarting the extension host or creating a new task.

Regression evidence

The mock trace was exactly:

stale -> FILE_NOT_FOUND -> fresh

The retried JSON-RPC request completed successfully and returned the expected empty app list. The patched module also passed Node syntax validation.

After a fresh runtime loaded the installed client:

• sky.list_apps() returned 40 applications, including the unique Chrome Beta window.
• A real get_window_state() returned a 9,161-character accessibility tree.
• The ChatGPT page was recognized as a Document.
• The side composer remained clean (Do anything).

Expected product behavior

A live Windows Computer Use client should recover once when the product-generated pipe UUID changes, using the current authoritative identifier already persisted by Desktop. Users should not need to restart the extension host or start a new task merely to replace a dead binding.

Public implementation reference

This issue is the canonical public patch specification for the rotated-pipe root cause. The hash identifies the exact client artifact used for verification; it is evidence, not a portable replacement file. Anyone porting the repair to a newer generation should implement the bounded state machine and run the regression tests above. No installed executable or private runtime file is required to understand the fix.

Related validated root-fix specifications:

• Chrome native-host status/ensure: Windows: Chrome native host out of date; plugin uninstall and feedback upload fail #40228 (comment)
• Windows Computer Use UIA/geometry/focus/synchronization: Computer Use cannot determine Chrome URL on Windows, even on chrome://newtab/ #25271 (comment)
• Windows Computer Use rotated native pipe: [Windows] Computer Use retains a rotated native-pipe UUID and never reconnects #41453

No executable, installed binary, user path, account data, task/tab identifier, or token is attached. The repository contribution guide asks for detailed root-cause reports and does not accept external PRs, so the implementation evidence is provided here without publishing installed binaries.