[Windows] Codex Desktop 26.803.10989.0: "Error: write EOF" main-process modal keeps appearing (with log evidence and my analysis)

[Windows] Codex Desktop 26.803.10989.0: "Error: write EOF" main-process modal keeps appearing (with log evidence and my analysis)

The problem

Ever since I updated the Codex Windows desktop app, this modal keeps popping up. It shows on nearly every startup, and then again at random points while I'm working:

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)

It's not tied to any one project or action. I also reproduced it with Browser Use disabled and no third-party plugins installed, so it's not something I'm triggering on purpose.

One thing worth calling out: the modal blocks the app. Until I click it away, Codex is frozen — I can't type, can't click anything in the window, the whole UI just sits there. So this isn't just an annoying popup, it halts whatever I'm in the middle of (including long-running tasks I can't babysit).

Quitting and reopening the app doesn't stop it either. It just comes back, which matches what other people reported in #35985/#35782 (the app restores the previous session, and the modal comes right back with it).

Environment

• Codex Desktop for Windows (Microsoft Store / MSIX)
• Package: OpenAI.Codex_26.803.10989.0_x64__2p2nqsd0c76g0
• OS: Windows 11 Home (Chinese), 10.0.26200, x64
• I checked the Store on 2026-08-13 and this is already the latest version, so updating isn't an option.

Same package version as #38202. The difference here is I dug through the logs and found evidence of what's happening.

Log evidence

Logs live in %LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\Codex\Logs\2026\08\13\.

The pipe gets created on startup, right around when the dialogs show

2026-08-13T07:21:29.430Z info [browser-use-native-pipe-server] browser-use native pipe listening pipePath=\\.\pipe\codex-browser-use-b4256aea-de53-473f-ae66-0b7c3379477b
2026-08-13T07:21:29.431Z info [browser-session-registry] browser_use_iab_backend_startup_ready backend=iab pipePath=\\.\pipe\codex-browser-use-b4256aea-de53-473f-ae66-0b7c3379477b platform=win32 release=26.803.81509 sessionId=019fe491-0722-7223-b340-e8dbafa864d5

And here's the same failure from 2026-08-10, with a full stack that matches the modal

2026-08-10T11:16:19.868Z warning [browser-use-native-pipe-server] browser-use native pipe socket error errorCode=EPIPE errorMessage="write EPIPE" errorName=Error errorStack="Error: write EPIPE
    at afterWriteDispatched (node:internal/stream_base_commons:159:15)
    at writeGeneric (node:internal/stream_base_commons:150:3)
    at Socket._writeGeneric (node:net:966:11)
    at Socket._write (node:net:978:8)
    at doWrite (node:internal/streams/writable:596:12)
    at clearBuffer (node:internal/streams/writable:781:7)
    at onwrite (node:internal/streams/writable:651:7)
    at WriteWrap.onWriteComplete [as oncomplete] (node:internal/stream_base_commons:105:10)"

The stack frame in the dialog (WriteWrap.onWriteComplete in stream_base_commons) is the same one that shows up here with EPIPE. So the modal looks like the unhandled version of a write to a pipe whose other end is already gone.

What I think is going on

The main process talks to its children over Node streams:

• a named pipe \\.\pipe\codex-browser-use-* to the in-app browser backend,
• the stdio transport to the codex CLI app-server process,
• Git review worker subprocesses (git status / git diff).

When the peer disappears (sidebar window destroyed, app-server drops, or a git subprocess gets canceled after a timeout), the main process is still writing to the socket. Node reports that as write EOF / EPIPE. The error escapes somewhere in the client unregister/broadcast path where there's no error handler, turns into an uncaught exception in the Electron main process, and Electron shows the dialog. #35985's logs show the exact same sequence: browser-sidebar routing: target window is no longer live -> IpcRouter Socket error errorCode=EPIPE -> the dialog.

Different triggers (browser sidebar #35985, Git review cancel/retry #38062, app-server disconnect #35782) all end up on the same unhandled write path, which makes me think this is a general IPC lifecycle bug rather than one feature misbehaving.

A few more things I checked

• This isn't a native crash. Crashpad has no dumps and there are no WER entries in the Windows Application event log around the dialog times. It's purely an uncaught JS exception in the Electron main process.
• The pipes never get cleaned up. The two codex-browser-use-* pipes from today's log (b4256aea-... at 07:21Z and 6cd399f3-... at 09:00Z) are still alive on my machine hours later, along with two newer ones:

``
\\.\pipe\codex-browser-use-b4256aea-de53-473f-ae66-0b7c3379477b
\\.\pipe\codex-browser-use-6cd399f3-66f2-4d41-8681-caecab79ae8f
\\.\pipe\codex-browser-use-7dea7bf7-c344-4f08-9775-deb2c37e084d
\\.\pipe\codex-browser-use-87493a3e-ec03-46a9-820c-3aaeaefd8f41
``
So each session/restart appears to leave its pipe behind. Writing to a pipe whose peer is long gone is exactly the EPIPE/EOF we're seeing, and this also explains why the dialog keeps coming back after restarts.

Possible fixes

• Attach an error handler to the native pipe / app-server stdio sockets and ignore EPIPE/EOF (standard Node practice: socket.on('error', ...)).
• Wrap the client unregister/broadcast path so a write to a closed peer can't escape as an uncaught exception.
• Add a main-process uncaughtException guard that logs instead of showing a modal (or at least debounces them).
• On session restore, drop stale clients / dead pipe peers before reconnecting.
• Clean up old codex-browser-use-* pipes when their session ends instead of leaving them to accumulate (I count 4 still alive on my machine from today alone).

Workarounds I'm using meanwhile

Until this gets fixed, a few things that cut down how often I hit it:

• Use the terminal codex CLI instead of the desktop app when I can. The Rust CLI doesn't have this problem.
• Turn off Browser Use / Computer Use in the app settings (and set enabled = false under [mcp_servers.node_repl] in ~/.codex/config.toml). Doesn't fully fix it per #35985, but it removes a big chunk of the triggers.
• Close or stop all running conversations before quitting the app, so it doesn't restore a stale session on next launch. That seems to be what triggers the dialog right on startup.

What I already tried (none of it helped)

• Windows Settings > Apps > Codex > Advanced options > Repair
• Full app restart / Windows restart
• Confirmed it's already the latest Store version
• Uninstalled third-party Codex wrappers (the failure is in the official app)

Related issues

• #38202 (same package version, same dialog)
• #35985 (unhandled write EOF after IpcRouter EPIPE when browser-sidebar client closes)
• #38062 (Git review cancellation spams the same dialog)
• #35782 (app-server disconnect/recovery terminates the desktop app)