Windows Codex Desktop: unhandled `write EOF` after IpcRouter EPIPE when browser-sidebar client closes

What version of Codex is running?

• Windows Store package: OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0
• Bundled CLI: codex-cli 0.146.0-alpha.3.1

What platform is your computer?

Microsoft Windows NT 10.0.26200, x64.

What issue are you seeing?

Codex Desktop intermittently shows a native Electron error dialog during long-running sessions:

A JavaScript error occurred in the main process

Uncaught Exception:
Error: write EOF
    at WriteWrap.onWriteComplete [as oncomplete]
    (node:internal/stream_base_commons:87:19)

The matching Desktop log shows an IPC client lifecycle failure rather than a model, prompt, repository, or shell-command error. Immediately before the app-server stdio transport disconnects, the log records that the browser-sidebar target window is no longer live. The subsequent failure sequence is:

browser-sidebar routing: target window is no longer live
IpcRouter Socket error errorCode=EPIPE
... broadcastClientStatus ...
... unregisterClient ...
app_server_connection.state_changed ... next=disconnected ... transport=stdio

The EPIPE appears to escape the client-unregistration/broadcast path and becomes an uncaught Electron main-process write EOF exception. The dialog can recur during the same Desktop run and makes long unattended tasks unsafe because the app-server connection is lost and an interrupted turn is not reliably resumed.

Timeline and eliminated local causes

• The first matching EPIPE/write EOF event was recorded before any third-party Superpowers plugin was installed.
• The same third-party plugin was later fully uninstalled; it is not needed to trigger the underlying failure.
• System Node.js was installed after the first captured event. Codex also uses its own bundled Node/runtime, so system Node did not introduce the original failure.
• A separately developed local MCP server was not registered with Codex and was created after the original event.
• The failure is cross-project and is observed in the Desktop IPC/app-server control path.

Windows AppX deployment history shows the Store app updated from 26.721.3996.0 to 26.721.4979.0 on July 24, 2026. The first captured failure on this machine occurred after that update.

Steps to reproduce

The failure is intermittent; there is not yet a deterministic minimal reproducer.

1. Run Codex Desktop on Windows with the bundled Browser and/or Chrome integration enabled.
2. Keep a local task active for an extended period.
3. Allow the browser-sidebar window/client to close, become stale, or otherwise fail its liveness check while the app-server connection remains active.
4. Observe IpcRouter ... EPIPE during broadcastClientStatus / unregisterClient, followed by the Electron write EOF dialog and app-server stdio disconnection.

The dialog has occurred repeatedly during normal Desktop use without intentionally terminating the app-server.

Expected behavior

• Losing a browser-sidebar or other IPC client should deregister that client cleanly.
• EPIPE, EOF, and already-closed-stream conditions during status broadcast/unregistration should be caught and treated as an expected client-disconnect race.
• The exception must not escape to Electron's main process.
• The remaining Desktop/app-server session should stay connected, or reconnect and resume the interrupted turn automatically.

Temporary mitigation

The following local configuration is being tested as a containment workaround:

[plugins."browser@openai-bundled"]
enabled = false

[plugins."chrome@openai-bundled"]
enabled = false

[features]
browser_use = false
browser_use_external = false
browser_use_full_cdp_access = false
in_app_browser = false

[mcp_servers.node_repl]
enabled = false

This is only a workaround because it removes supported Browser/Chrome functionality and does not harden the main-process IPC lifecycle itself.

Suggested areas to inspect

• Make broadcastClientStatus resilient to sockets closing between liveness checking and write completion.
• Make unregisterClient idempotent and prevent it from broadcasting through a socket already being removed.
• Attach/retain an error handler until all pending writes have settled.
• Treat Windows EPIPE/EOF from a closed IPC client as a normal disconnect rather than an uncaught exception.
• Add a regression test for a client/window disappearing while a status broadcast is in flight.
• Reconnect the app-server transport and resume any active turn when possible.

Related reports

• #21670 — Windows Chrome/Browser shared native-pipe instability with IpcRouter Socket error: write EPIPE
• #30348 — app-server stdio disconnect and write EPIPE after a request lifecycle race
• #20846 — Windows Browser Use IAB bridge connection failures
• #19693 — Windows Browser native-pipe injection/bridge failure

This report is specifically for the uncaught Electron main-process write EOF crash path and the broadcastClientStatus → unregisterClient sequence.