Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   app-serverIssues involving app server protocol or interfacesIssues involving app server protocol or interfaces

   browser

   connectivityIssues involving networking or endpoint connectivity problems (disconnections)Issues involving networking or endpoint connectivity problems (disconnections)

   on Jul 29, 2026
2. github-actions commented on Jul 29, 2026

   

   github-actionsBot

   on Jul 29, 2026 – with GitHub Actions

   Contributor

   More actions

   Potential duplicates detected. Please review them and close your issue if it is a duplicate.

   • [Windows][26.721.4979.0] app-server disconnect/recovery causes full desktop app termination under concurrent tasks #35782

   Powered by Codex Action
3. speedaemonc4 commented on Jul 29, 2026

   

   speedaemonc4

   on Jul 29, 2026 – with ChatGPT Codex Connector

   Author

   More actions

   Additional reproduction after a clean restart and automatic Store update:

   • The error recurred on OpenAI.Codex_26.721.11231.0_x64__2p2nqsd0c76g0, so it is not fixed in that newer build.
   • Browser Use feature flags remained disabled and the Browser/Chrome plugins reported not installed.
   • Despite the prior explicit MCP disablement, Desktop regenerated the [mcp_servers.node_repl] configuration without enabled = false and launched two node_repl.exe children under the packaged app-server.
   • BROWSER_USE_AVAILABLE_BACKENDS was empty, while the Computer Use plugin and SKY_CUA_NATIVE_PIPE remained enabled.

   This indicates Browser/Chrome are not the only route capable of leaving the faulty IPC lifecycle active. A second isolation test now disables the Computer Use plugin and feature, removes its turn-ended notifier, and explicitly disables node_repl. If the exception persists after that clean restart, the remaining cause is likely the general Desktop IPC router/app-server lifecycle rather than an optional browser backend.
4. Mayokun26 commented on Aug 3, 2026

   

   Mayokun26

   on Aug 3, 2026

   More actions

   I can reproduce the same uncaught Electron main-process stream failure on current macOS, with the Browser/Chrome native-pipe lifecycle involved.

   Environment:

   • macOS 26.3.1 (25D2128), Apple Silicon arm64
   • ChatGPT/Codex app 26.727.51351, build 6119
   • bundled codex-cli 0.146.0-alpha.9.2
   • ChatGPT Chrome extension 1.2.27236.6274

   Visible dialog:

   A JavaScript error occurred in the main process
   
   Uncaught Exception:
   Error: write EPIPE
       at WriteWrap.onWriteComplete [as oncomplete]
       (node:internal/stream_base_commons:87:19)
   

   Matching Desktop log:

   warning [browser-use-native-pipe-server] browser-use native pipe socket error
   errorCode=EPIPE errorMessage="write EPIPE"
   

   The same period also records repeated failures of the form:

   No ChatGPT browser route is available for browser session <redacted>
   

   Reproduction/behavior:

   1. Run multiple long-lived local Codex tasks, including tasks using the embedded browser.
   2. Allow one browser route/client to become stale or disappear during a long session.
   3. The native Electron write EPIPE dialog begins recurring every few minutes.
   4. Fully quitting and reopening the app does not resolve it because the long-lived task/browser state is restored.
   5. Disabling the Chrome extension and confirming its native host exited did not stop the popup.
   6. Terminating an orphaned pre-update app-server/code-mode-host pair did not stop it.
   7. Terminating browser helper processes stopped embedded-browser access but did not provide a usable mitigation; browser workers require those helpers.

   An additional diagnostic detail: after the first pair of browser-use-native-pipe-server EPIPE warnings, the native dialogs could continue recurring without a corresponding new EPIPE line appearing in the Desktop log.

   Expected behavior:

   • Browser client disconnects and stale routes should be treated as normal lifecycle events.
   • Pending writes should retain an error handler and swallow EPIPE/EOF after disconnect.
   • The exception should never reach Electron's main-process uncaught-exception dialog.
   • Browser helpers should rebind to the live route without requiring the user to disable Browser/Chrome or restart long-running tasks.

   This appears to be the macOS write EPIPE variant of this issue, with route-binding symptoms related to #20678. Browser functionality is operational and important to the running tasks, so disabling Browser/Chrome is not a viable workaround.
5. neitblackstar-droid commented on Sep 23, 2026

   

   neitblackstar-droid

   on Sep 23, 2026

   More actions

   Draft update for openai/codex issue #35985

   The same IpcRouter closed-socket failure is still present in the current Codex Desktop build on Windows.

   Environment

   • Windows 10, version 22H2, build 19045, x64.
   • Microsoft Store package: OpenAI.Codex_26.915.4065.0_x64__2p2nqsd0c76g0 (Status: Ok).
   • Bundled app release recorded locally: codex@26.915.31945.

   Observed behavior

   On 2026-09-23 at 08:24 local time (UTC+7), Codex displayed an Electron main-process dialog with Uncaught Exception: Error: write EPIPE. The stack begins at afterWriteDispatched and writeGeneric in Node streams. The previous app process logged this sequence during shutdown (timestamps UTC):

   01:24:21.614  update_resume_state_saved threadCount=0
   01:24:21.901  [AppServerConnection] Stopping app-server transport connectionId=1 transport=stdio
   01:24:21.902  [AppServerConnection] app_server_connection.state_changed cause=stop_process ... next=disconnected
   01:24:21.943  [IpcRouter] Socket error errorCode=EPIPE errorMessage="write EPIPE"
                  stack: ... ise.broadcastClientStatus -> ise.unregisterClient
   01:24:21.947  [IpcClient] Received broadcast but no handler is configured method=ipc-connection-reset
   

   This is recurrent in the local logs: 13 prior main-process sessions created over the last seven days each logged four IpcRouter EPIPE events within the final 8–10 lines of their log. In all 13 sessions, Stopping app-server transport and update_resume_state_saved appear in the five lines immediately before the first EPIPE. The current process started at 08:24:32 and has no EPIPE event while running.

   The log sequence and stack support a shutdown/IPC client unregister race. They do not prove which specific client socket first closed. The visible modal was captured once; the log failure recurs more often than a modal has been confirmed.

   Expected behavior

   When a client socket has closed during app-server shutdown or update, the router should unregister the client and handle EPIPE without an uncaught main-process exception or blocking dialog. The app should complete its restart and preserve recoverable work.

   No raw logs or screenshot are attached because they contain local paths and other personal metadata. Sanitized excerpts can be supplied if maintainers need more detail.
6. neitblackstar-droid commented on Sep 23, 2026

   

   neitblackstar-droid

   on Sep 23, 2026

   More actions

   Follow-up from the same Windows machine (2026-09-23): clicking the in-app Update button on Store package 26.915.4065.0 reproduced the Uncaught Exception: Error: write EPIPE dialog at about 08:45 local time (UTC+7). The old process logged update_resume_state_saved, then Stopping app-server transport, followed about 50 ms later by four [IpcRouter] ... errorCode=EPIPE entries with broadcastClientStatus -> unregisterClient in the stack. At the same time, Windows AppX event 404 reported that registration of staged OpenAI.Codex_26.917.6896.0 failed with 0x80070005 because OpenAI.Codex_...!App was still running (event 638: packages not updated because affected apps are still running). The app restarted on 26.915.4065.0, so the update button had not completed the update.

   After fully closing Codex, I registered the already staged, validly signed OpenAI package. Windows AppX then recorded a successful Register operation at 09:02:23; Get-AppxPackage and the running executable both confirm 26.917.6896.0, status Ok. The new session has no EPIPE log entries so far, but that is not proof this build fixes the IPC/shutdown race on a future update. This adds a reproducible update-time trigger and a separate app-in-use registration failure to the existing report. No raw logs, paths, account IDs, or screenshots are attached.
7. neitblackstar-droid commented on Sep 24, 2026

   

   neitblackstar-droid

   on Sep 24, 2026

   More actions

   Follow-up from the same Windows 10 22H2 machine (2026-09-24): the update-time write EPIPE dialog recurred on Store package 26.917.8451.0 when clicking the in-app Update button. At 08:14:30 UTC, Desktop logged update_resume_state_saved threadCount=0, then Stopping app-server transport / next=disconnected; four [IpcRouter] Socket error errorCode=EPIPE warnings followed at 08:14:31 UTC. Windows AppX events 401/404 at 15:14:31 local (UTC+7) show registration of staged OpenAI.Codex_26.917.9434.0 failed with 0x80070005: "Unable to install because the following apps need to be closed OpenAI.Codex_...!App." The app relaunched from 26.917.8451.0; its updater reports restart_required. Two earlier sessions today on 26.917.6896.0 each logged four shutdown-time EPIPE warnings as well. This shows the IPC/shutdown failure persists across these builds and the updater is attempting registration while the app is still open. No raw logs, account identifiers, local paths, or screenshot are attached.
8. neitblackstar-droid commented on Sep 24, 2026

   

   neitblackstar-droid

   on Sep 24, 2026

   More actions

   Further evidence on the same Windows 10 22H2 host (2026-09-24): I installed the already staged, validly signed OpenAI.Codex_26.917.9434.0 package after stopping the app. Windows AppX event 400 at 15:30:50 UTC+7 and Get-AppxPackage confirm successful registration (Status: Ok); the running desktop app uses that package (build 10954).

   The IPC error still appeared in the 26.917.9434.0 desktop log at 08:46:22 UTC during a later app process exit, without clicking Update in that session. Immediately before it, the log records repeated browser-sidebar IAB_LIFECYCLE "route window is not live" messages and removal of the browser session window. It then records two [IpcRouter] Socket error errorCode=EPIPE warnings with broadcastClientStatus -> unregisterClient in the stack, followed by app-server stdio transport stopping and next=disconnected. I did not confirm a visible Electron modal for this particular occurrence; this establishes that the IPC error path persists, not that every warning displays a modal.

   A supported managed features.in_app_updates = false policy is now active only as containment for the Update-button trigger; the app's update check reports "In-app updates are disabled by policy." This does not fix the underlying IPC lifecycle race. No raw logs, local paths, account identifiers, or screenshots are attached.