Windows Desktop 26.623 silently destroys/relaunches AppX container after resuming long-running threads

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

• #30962
• #30338
• #31353
• #31115
• #30558

Powered by Codex Action

Update after filing: reproduced again on 2026-07-08 around 22:48 Asia/Shanghai.

This time the app was not running the three old threads simultaneously. The user opened one old long-running thread whose UI history appeared almost empty/missing. The local thread metadata still existed, but the desktop UI only appeared to recover a very small recent turn set.

Timeline and evidence:

• 22:43:25 local: thread/read for the affected conversation returned with errorCode=null.
• 22:43:46 local: thread/resume returned with errorCode=null; the desktop log then showed maybe_resume_success ... latestTurnStatus=interrupted ... turnCount=5 and IAB/browser-use route capture for the same conversation.
• 22:44:01 through 22:48:01 local: the desktop log repeatedly handled thread/turns/list for that same conversation every ~11-15 seconds, each with errorCode=null.
• 22:47:54 local: another thread/read for the same conversation returned with errorCode=null.
• 22:48:01 local: last line in that desktop log was a successful thread/turns/list, followed by a normal thread/list.
• 22:48:05 local: Windows AppModel-Runtime event ID 217: destroyed the AppX container for OpenAI.Codex_26.623.19656.0_x64__2p2nqsd0c76g0.
• 22:48:10 local: Windows AppModel-Runtime event IDs 210/211/201: created a new AppX container and launched process 24152 for the same Codex package.
• No Windows System restart/power event was recorded in the same window.
• No Application Error / Windows Error Reporting event for Codex was recorded in the same window.
• No Crashpad/CrashDumps artifact was found.

The local watchdog captured the event and saved a tail snapshot at:

C:\Users\tangt\Desktop\codex-crash-watch\tail-20260708-224809.log

The previous-process desktop log for this reproduction was:

C:\Users\tangt\AppData\Local\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\Codex\Logs\2026\07\08\codex-desktop-d88f88bc-c51d-4b2d-bbd8-aa92a92fc369-26184-t0-i1-143101-0.log

This makes the correlation stronger: resuming or loading history for an old, long-running, interrupted thread with browser-use/IAB state appears to trigger a silent desktop container teardown/relaunch. The user's project files are not deleted, but the desktop UI may render the old thread history as nearly empty before the relaunch.

Severity escalation: current 26.707.8479.0 silently terminated at least four times today

This failure remains reproducible in the current Microsoft Store Windows package:

• Codex Desktop: 26.707.8479.0
• bundled app-server: 0.144.2
• Windows 11 x64
• local time zone: Asia/Shanghai
• verification date: 2026-07-13

I separated Store-update exits from unexpected exits using AppModel event IDs 42/201/210/211/217, package versions, main-process log PIDs, and each log's final line. The three confirmed package-update transitions at 09:07, 15:06, and 16:05 are not counted below.

High-confidence abnormal exits

| Time | Main PID | Final local evidence | AppModel result |
|---|---:|---|---|
| 15:07:22 | 40252 | log stopped after only ~34 seconds; no quit/update/clean-exit marker | event 217 destroyed the AppX container |
| 16:00:16 | 10192 | final line: Recoverable Chromium child process gone exitCode=-1 processType=GPU reason=crashed | event 217 destroyed the container; new main process created at 16:00:18 |
| 16:02:40 | 5536 | final line: bundled plugin reconciliation failed because Codex app-server is not available | event 217 destroyed the container; new main process created at 16:02:55 |
| 16:35:39 | 31492 | final line was a completed thread/turns/list response with durationMs=11632; no shutdown marker | event 217 destroyed the container; new main process created at 16:36:13 |

There was one additional container exit at 16:01:32 whose preceding log contained an orderly stop_process / app-server transport shutdown. I am not counting that as a crash without stronger evidence.

This means the defensible count is at least four abnormal full-AppX exits in roughly 90 minutes, not counting updates or the ambiguous orderly restart.

The newest exit matches this issue's original failure shape

The 16:35 event happened during normal Codex use. The previous process's final logged operation was:

response_routed
method=thread/turns/list
durationMs=11632
errorCode=null

Approximately 1.85 seconds later, AppModel event 217 destroyed the entire Desktop AppX container. The UI disappeared while the user was actively conversing. A new process was created 34 seconds later.

This strongly matches the earlier reports in this issue where long-running thread hydration repeatedly reaches thread/turns/list, the log ends on an apparently successful response, and the AppX container silently disappears seconds later.

I am treating the history correlation as evidence, not yet claiming that every exit has one root cause. The 16:00 event independently proves a Chromium GPU child crash; the 16:02 event proves app-server unavailability immediately before another full-container loss.

Crash diagnostics are still missing

For all four abnormal exits, current checks found:

• zero matching Windows Application Error / WER crash records
• no current Codex/ChatGPT dump in %LOCALAPPDATA%\CrashDumps
• no Crashpad report
• no usable Sentry queued report
• no Desktop fatal line explaining the 16:35 full-container exit

The absence of a dump is not evidence that the app did not crash. AppModel proves the container was destroyed and recreated, while the user directly observed the UI disappear. It means the product's crash-reporting path is failing to preserve actionable evidence for this failure class.

User impact and requested action

This is no longer an occasional inconvenience. The app terminated repeatedly during one development session, interrupted active conversations, and forced the user to wait for automatic relaunch/recovery. A development tool cannot be considered stable when its entire UI/container can disappear four times in 90 minutes without a diagnostic artifact.

Please prioritize:

1. persist a crash/restart reason before container teardown;
2. collect a minidump or Crashpad artifact for GPU, renderer, main-process, and app-server fatal paths;
3. isolate per-thread hydration failures so one large thread cannot terminate the whole Desktop app;
4. cancel and budget tail_history / thread/turns/list work;
5. do not automatically restore the same fatal state without a safe-mode/recovery choice;
6. add a current Windows regression test covering repeated long-thread resume/list activity plus GPU-process failure;
7. distinguish Store-update restarts from product crashes in both telemetry and the UI.

Related current-build evidence:

• #21211: unbudgeted long-history hydration
• #32722 / #20781: unbounded full-state snapshot fan-out

This issue should not be treated as resolved merely because Windows produced no conventional WER entry. The silent-exit behavior is continuing on the latest build.

Current-build recurrence: at least four abnormal AppX exits in ~90 minutes

This is the same silent-close/relaunch failure shape, now reproduced on the current Microsoft Store package:

• package: 26.707.8479.0
• bundled app-server: 0.144.2
• Windows 11 x64
• timezone: Asia/Shanghai
• verification date: 2026-07-13

I kept the existing process state intact and correlated AppModel-Runtime events with the final lines of each Codex Desktop log. I am deliberately separating package-update transitions and a stop-marked restart from abnormal exits.

Abnormal exits

1. 15:07:22 — process created at 15:06:47 after the 26.707.6957 -> 26.707.8168 update had already completed. The AppX container was destroyed about 35 seconds later. The Desktop log ended without a normal quit/stop marker.
2. 16:00:16 — the final Desktop log line explicitly reported:

``
Recoverable Chromium child process gone
exitCode=-1 processType=GPU reason=crashed
``
The AppX container was destroyed immediately afterward.

1. 16:02:40 — the Desktop log ended with Codex app-server is not available; the AppX container was destroyed at the same time.
2. 16:35:39 — the newest failure reported by the user during active work. The final log line before container destruction was a successful-looking thread/turns/list response that took 11,632 ms. The container was destroyed at 16:35:39 and a new package process appeared at 16:36:13.

A separate 16:01:32 restart had an explicit stop_process marker and is not counted as a crash. The 09:07, 15:06, and 16:05 package transitions were also excluded as expected update lifecycle events.

Diagnostic failure

For these current-build exits:

• Windows Application/Application Error/WER queries returned no Codex crash record.
• No recent Codex dump or Crashpad report was present.
• The user-visible result is still the same: Codex disappears and later relaunches, with no actionable error.

This is no longer an isolated historical report. A top-tier Windows development workstation saw four abnormal container deaths in roughly 90 minutes, including a confirmed Chromium GPU crash and a silent exit immediately after expensive local history work. The app provides no reliable crash artifact and no indication whether user work is safe.

Required fixes

1. Prevent one renderer/GPU/app-server/history failure from silently destroying the entire Desktop AppX container.
2. Persist a crash/restart reason and correlation ID before relaunch; emit a usable user-facing diagnostic.
3. Preserve the last safe thread state and allow the rest of the app to continue when one thread or one backend path fails.
4. Add regression coverage for long-thread thread/turns/list, repeated resume/navigation, GPU child loss, and app-server unavailability.
5. Treat repeated silent AppX destruction as a release-blocking reliability defect, not as a normal restart path.

The absence of WER does not make these events harmless. It means the product is failing without leaving the evidence users and maintainers need.

Additional concrete reproduction from #32904 on the same current build:

• Codex Desktop: 26.707.8479.0
• app-server/CLI: 0.144.2
• affected rollout: 302,158,899 bytes / 24,851 JSONL records
• one patch_apply_end record was 203,310,615 characters
• that record was produced by an apply_patch Delete File operation that serialized the deleted file's full contents under payload.changes.<path>.content
• every other record was below 5 MB

Opening the thread produced the same failure shape described here: thread/read and thread/resume returned successfully, the desktop log then ended without a fatal marker, and the whole app restarted seconds later with no WER or Crashpad artifact.

This provides a specific, reproducible history-hydration trigger for at least one class of the silent container exits reported here: an unbounded patch-history payload transferred while resuming a thread. Suggested guardrails are to cap or omit deleted-file contents in patch_apply_end and enforce per-record/per-field limits when reading legacy histories.

Closing #32904 as a duplicate of this issue.

July 14 follow-up on current Windows build

This silent-container-close pattern reproduced repeatedly today on a newer Microsoft Store package:

• Package: OpenAI.Codex_26.707.8479.0_x64__2p2nqsd0c76g0
• Local time zone: Asia/Shanghai
• Symptom: the whole Codex Desktop app disappeared during one long-running local coding task, with no error dialog. Restarting Codex resumed the task, but the same behavior recurred; a full PC restart did not establish a user-visible cause.
• The task explicitly did not launch subagents, so this reproduction does not require the concurrent-subagent trigger described in #32789.
• App/backend logs ended without a normal shutdown marker, panic, fatal exception, or out-of-memory line.
• Windows Application log inspection found no matching ordinary application-crash event.
• AppModel state showed container destruction/recreation around the affected sessions, consistent with the original report.
• Current local Codex log database size is 1,868,091,392 bytes; its current WAL is 4,523,792 bytes.
• The active session transcript has grown to 113,385,995 bytes.

The large persistent log database and very large resumed session may be relevant stressors, but I cannot establish causation. The absence of a fatal record or crash artifact remains the central diagnostic gap: the app can vanish repeatedly without preserving a user-facing reason or an actionable crash report.

After the restart, the same repository task completed successfully when work was kept to smaller bounded tool calls. Raw logs and transcripts are not attached because they contain local paths and task content; sanitized excerpts can be provided if maintainers identify the relevant log window or private upload channel.

Additional current macOS reproduction from #34003, matching the oversized-history failure isolated in #32904:

• macOS; ChatGPT/Codex desktop 26.715.31925 (released July 17, 2026)
• One task modified 19 large APFS-cloned sidecar files, about 3.1 GiB total logical size.
• Reopening the task or submitting a message repeatedly produced a blank task view and then “Oops, an error has occurred.”
• Desktop logs reported RangeError: Invalid string length, JSONL parser failures with lineBytes=1720880466 and later lineBytes=3453099188, plus the conversation-page React error boundary with errorMessage="Invalid string length".
• The underlying worker still completed, which isolates the failure to task-history serialization/parsing/rendering rather than model execution.
• A fresh task containing only a compact handoff renders normally; the affected task remains unrenderable.

This extends the byte-level evidence to macOS and the current desktop build. The original report and screenshot are in #34003. Full logs are not public because they contain local paths and task contents.