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

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

   sessionIssues involving session (thread) management, resuming, forking, naming, archivingIssues involving session (thread) management, resuming, forking, naming, archiving

   browser

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

   

   github-actionsbot

   on Jul 8, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Codex Windows App silently exits without user action. #30962
   • Windows desktop app exits after idle and cannot start until AppData\Local\OpenAI\Codex is recreated #30338
   • Windows Desktop crash/hang with codex.exe MoBEX and node_repl/extension-host BEX64 after recent update #31353
   • Windows Codex Desktop crashed during in-app Browser use; bundled Browser plugin cache refreshed and old path disappeared #31115
   • Codex App crashes/hangs when opening local HTML with the built-in browser on Windows #30558

   Powered by Codex Action
3. hg28c4bytb-prog commented on Jul 8, 2026

   

   hg28c4bytb-prog

   on Jul 8, 2026

   Author

   More actions

   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.
4. HyperSpAceBoy commented on Jul 13, 2026

   

   HyperSpAceBoy

   on Jul 13, 2026 – with ChatGPT Codex Connector

   More actions

   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:

   • Thread navigation/loading slows from unbounded metadata and eager large-history hydration #21211: unbudgeted long-history hydration
   • [Windows Desktop 26.707.8479.0] New windows still fan out full conversation snapshots for every streaming thread #32722 / VS Code Codex extension repeatedly broadcasts huge thread-stream-state-changed snapshots for completed long threads, causing extension-host/renderer CPU spikes #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.
5. HyperSpAceBoy commented on Jul 13, 2026

   

   HyperSpAceBoy

   on Jul 13, 2026 – with ChatGPT Codex Connector

   More actions

   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.
   3. 16:02:40 — the Desktop log ended with Codex app-server is not available; the AppX container was destroyed at the same time.
   4. 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.
6. zmullen115 commented on Jul 14, 2026

   

   zmullen115

   on Jul 14, 2026 – with ChatGPT Codex Connector

   More actions

   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.
7. rajks85 commented on Jul 14, 2026

   

   rajks85

   on Jul 14, 2026 – with ChatGPT Codex Connector

   More actions

   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 [Windows Desktop 26.707.8479.0] Concurrent subagent streams flood both renderers, then silently terminate the AppX container #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.
8. cusoccerboy commented on Jul 18, 2026

   

   cusoccerboy

   on Jul 18, 2026

   More actions

   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.
9. jack112806 commented on Jul 27, 2026

   

   jack112806

   on Jul 27, 2026

   Last edited by jack112806

   More actions

   Additional deterministic reproduction on Windows Desktop 26.721.4979.0

   I reproduced the same failure shape on a newer Microsoft Store build. Unlike the intermittent reports above, this instance is isolated to one specific local thread: other threads in the same project open normally, while opening the affected thread crashes the app every time.

   Environment

   • Codex Desktop package: OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0
   • Windows: Microsoft Windows NT 10.0.26100.8875 x64
   • Chromium/Electron component observed in Crashpad arguments: 150.0.7871.128
   • Intel UHD Graphics, driver 31.0.101.5445
   • NVIDIA GeForce RTX 4070 Laptop GPU, driver 32.0.15.7602
   • Package health reported by Windows: Ok
   • No matching Windows display-driver reset/error event was recorded around the crash

   Affected thread

   • Thread/session ID: 019f89bf-c123-7d93-9631-9563079b437f
   • Local rollout size: 44,552,571 bytes (about 42.5 MiB)
   • The thread has persisted in-app Browser/IAB tab state; restoring it opens a Bing page in the browser sidebar.
   • The rollout JSONL itself was not modified during diagnosis.

   Reproduction steps

   1. Start Codex Desktop normally.
   2. Open the project containing the affected thread.
   3. Select thread 019f89bf-c123-7d93-9631-9563079b437f.
   4. Codex restores the thread and its in-app browser sidebar state.
   5. Approximately 8-9 seconds later, the entire Codex app exits.
   6. Relaunch can initially fail with AppModel 0x80073CFC [GetPackageToken]; after a short interval the app can launch again.
   7. Repeat steps 2-5. The crash is deterministic for this thread. Other threads in the same project remain usable.

   Correlated desktop-log timeline

   Local time zone: Asia/Singapore.

   16:26:35  thread_stream_view_activity_changed active=true
   16:26:35  browser_use_iab_backend_startup_started
   16:26:35  thread/read
   16:26:36  thread/resume
   16:26:36-16:26:37  repeated thread/turns/list
   16:26:44  Recoverable Chromium child process gone
             processType=GPU
             reason=crashed
             exitCode=101457950
   16:26:44  Chromium GPU child process
             processType=GPU
             reason=launch-failed
   

   The short, repeatable interval between thread restoration and GPU-process loss makes this more specific than a general application exit. Browser state is a correlated trigger, not a proven sole cause. The evidence does not establish a defective display driver.

   Expected behavior

   A large or malformed thread-history/browser-restoration payload should not terminate the desktop app. Codex should bound history hydration/rendering, isolate renderer or GPU child-process failures, recover without tearing down the AppX container, and provide a usable diagnostic if recovery fails.

   Additional diagnostic notes

   • Strict JSON parsers successfully validate the desktop global-state JSON; this is not evidence of JSON corruption.
   • Removing the persisted browser-tab restore entry did not provide a durable workaround while the app was running because the current process wrote its in-memory browser state back to disk.
   • No matching Windows display-driver fault was found during the crash window.

   This adds a current-build, single-thread deterministic reproduction to the failure tracked here. A useful regression case would restore a roughly 42.5 MiB thread with persisted IAB state, then verify bounded history loading, GPU-child recovery, and continued access to unrelated threads.
10. sined-rahkuk commented on Jul 29, 2026

    

    sined-rahkuk

    on Jul 29, 2026

    More actions

    Current-build recurrence with thread-state mismatch + IAB teardown (26.721.4979.0)

    This still reproduces on the newer Microsoft Store Windows package.

    Environment

    • Codex Desktop package: OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0
    • Windows x64, build 26200
    • Local time zone: Europe/Budapest
    • Package files were unchanged during the incident; this was not a Store update

    Confirmed abnormal exits

    Windows AppModel-Runtime event 217 recorded full Codex AppX container destruction at:

    • 2026-07-28 22:15:52
    • 2026-07-28 22:42:55
    • 2026-07-29 10:31:55

    The computer did not reboot or shut down. The latest incident required a manual relaunch at 10:40:43.

    Latest pre-exit sequence

    The final desktop log shows:

    10:31:50  thread/name/set completed successfully
    10:31:51  Received turn/started for unknown conversation
               (reported by primary, overlay, home-hotkey, and thread-hotkey renderers)
    10:31:55.275  IAB_LIFECYCLE unregistered debugger listener reason=manual
    10:31:55.284  renderer disposed browser sidebar webview
    10:31:55.295  browser sidebar guest torn down
    10:31:55.313  closed browser sidebar page
    10:31:55.995  AppModel event 217 destroyed the full AppX container
    

    The 22:42 recurrence had a closely related ending: IAB target-close, a rejected route/tab binding, browser host recreation, and then full AppX destruction less than a second later. The 22:15 recurrence also ended immediately after browser-sidebar teardown.

    Negative evidence

    No matching:

    • Windows reboot/power event
    • Resource Exhaustion / OOM event
    • Application Error, WER crash, or .NET runtime crash
    • local CrashDump or Crashpad report
    • Task Scheduler action targeting Codex
    • package deployment/update event

    I also checked the distinct SwiftShader/GPU signature in #35635. This machine had no Code Integrity 3033 event and no Chromium child process gone, processType=GPU, or vk_swiftshader line for these exits, so that specific cause is not supported here.

    This strengthens the thread/IAB lifecycle hypothesis in this issue: desktop renderer/app-server conversation state becomes desynchronized, browser sidebar teardown occurs, and the full AppX container silently disappears without preserving a fatal reason.

    Please prioritize:

    1. isolate unknown/stale conversation events from unrelated renderers;
    2. make IAB teardown idempotent across task completion, route changes, and window overlays;
    3. persist the actual process/container termination reason before exit;
    4. generate a Crashpad/minidump artifact for this silent-exit class;
    5. add a Windows regression test with parallel/long-running threads completing while an IAB sidebar session is torn down.