Windows desktop app silently closed/restarted after 26.506 update; no crash artifact recorded

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

• #21761

Powered by Codex Action

Additional reproduction on Windows package 26.707.9981.0

I reproduced the same silent close/container-exit pattern twice on July 15, 2026. No intentional window-close action was taken.

Environment

• Windows 11 Pro, version 10.0.26200, x64
• Microsoft Store/MSIX package: OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0
• Package status: Ok
• Time zone: Asia/Shanghai (UTC+8)
• The package had updated from 26.707.9564.0 to 26.707.9981.0 the previous day. There was no AppX deployment/update activity during either exit.

Timeline

1. 17:12:29 local time

• The primary window stopped being live.
• The desktop log then recorded IpcRouter ... EPIPE, followed by Stopping app-server transport and cause=stop_process.
• AppModel-Runtime recorded the AppX container being destroyed at 17:12:30.
• A new packaged app process was launched at 17:12:33.

1. 18:22:37 local time

• The same sequence occurred: window no longer live -> EPIPE -> app-server stopped.
• AppModel-Runtime recorded container destruction at 18:22:40.
• A new app process was launched at 18:23:09.

The first exit happened roughly three minutes after a turn-complete notification while the primary window was not focused. The second happened during an active turn while the primary window was focused, so it does not appear limited to post-task completion.

Evidence checked

• No Windows Application Error, Application Hang, or Windows Error Reporting event for Codex/ChatGPT around either exit.
• No matching Reliability Monitor failure.
• No new Crashpad report, user CrashDump, WER ReportQueue item, or WER ReportArchive item.
• No GPU reset, display-driver failure, resource-exhaustion event, or memory-pressure event.
• The desktop log contained no explicit render-process-gone, child-process-gone, fatal, panic, or crash reason before the window disappeared.
• The EPIPE occurs only after the window is already gone and the same cleanup signature also appears on older normal exits, so it looks like a downstream cleanup symptom rather than the initiating cause.

This currently looks like the main BrowserWindow being destroyed and the app following its normal shutdown path without recording what triggered the close. Additional instrumentation around the BrowserWindow close/closed/destroyed path and the initiating caller would make this diagnosable.

Additional reproduction on Windows package 26.715.8383.0

I reproduced the same silent AppX container destroy/relaunch pattern twice. No intentional window-close action was taken.

Environment

• Windows 11, build 26200, x64
• Codex Desktop 26.715.8383.0
• Package status: Ok
• No matching AppX deployment/update activity during either restart

Timeline (UTC)

1. First occurrence:

• 2026-07-21 16:38:06Z: the Codex Desktop AppX container was destroyed.
• 2026-07-21 16:38:11Z: a fresh Codex packaged-app process was launched.

1. Second occurrence:

• The desktop log remained active until 2026-07-22 02:29:43Z.
• 2026-07-22 02:29:54Z: the AppX container was destroyed.
• 2026-07-22 02:29:56Z: a fresh Codex packaged-app process was launched.
• The operating system did not restart during this occurrence.

Evidence checked

• No matching Windows Application Error, Application Hang, or WER event.
• No fresh Crashpad report or user crash dump.
• No explicit render-process-gone, child-process-gone, fatal, panic, or normal shutdown reason was logged.
• The pre-exit desktop log ended abruptly.

Immediately before the second exit, the desktop log recorded 17 global UI errors between 02:27:19Z and 02:29:43Z. The final log line was:

error [electron-message-handler] [desktop-notifications][global-error]
ResizeObserver loop completed with undelivered notifications.

The same process log also contained 85 failed fs/watch requests and 85 paired warnings while restoring or switching threads containing Windows file links:

Request failed method=fs/watch
error={"code":-32600,"message":"Invalid request: AbsolutePathBuf deserialized without a base path"}

Failed to watch open file
path="<redacted Windows path>"

I cannot establish that either error is the initiating cause. However, the repeated ResizeObserver errors are the last recorded application activity before the log stops, and the fs/watch failures show persistent Windows path deserialization problems during the same app session.

This confirms that the silent container restart still occurs on Codex Desktop 26.715.8383.0.

Could the app log the initiating caller or reason whenever the primary BrowserWindow or AppX container is closed or destroyed? It would also be helpful to confirm whether repeated global ResizeObserver errors or failed file-watch restoration can trigger renderer/window teardown or watchdog recovery.

Expected behavior

Codex Desktop should remain running during an active task. If it must restart, it should preserve the task and record or display a clear restart reason.

Redactions

Local usernames, raw filesystem paths, thread/turn/session IDs, process/container IDs, filenames, and prompt content have been omitted.