Repository navigation
Windows Desktop: Possible multi-release regression affecting app-server stability, tool execution and session continuity #41395
Description
What version of the Codex App are you using (From “About Codex” dialog)?
26.826.12353
What subscription do you have?
ChatGPT Plus
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What issue are you seeing?
Codex Desktop was previously stable for sustained professional development work on the same Windows environment. More recently, repeated unexpected interruptions have occurred during active, tool-intensive development sessions.
The concern is not an isolated crash, but a possible multi-release Windows Desktop reliability regression.
Observed locally:
- repeated unexpected Codex interruptions during development work;
- interrupted active sessions requiring recovery;
- loss of reliable development continuity after failures;
- session/continuation problems, including 404-related failures and problems occurring around long-running/compacted sessions;
- recurrence across normal, sustained Codex development workflows.
The apparent pattern is:
previously stable workflow → newer release family → repeated failures → recovery required → similar independent Windows reports → problems continuing across subsequent Desktop releases
Several public Codex issues describe overlapping Windows symptoms, including app-server termination/restart during tool execution, missing tool-call outputs, session/thread recovery failures, HTTP 404 behavior, compaction anomalies and abnormal session-state/resource growth.
I am not claiming that these symptoms share one root cause. Some may be independent defects. The concern is whether they are being correlated internally as a broader Windows Desktop reliability regression.
What steps can reproduce the bug?
There is currently no single deterministic minimal reproducer.
The failures occur intermittently during sustained professional Codex development sessions involving local repositories and repeated tool/shell operations.
Typical workflow:
- Open an existing software-development project in Codex Desktop.
- Continue a development session involving repository inspection, file modifications, shell/PowerShell commands and other tool calls.
- Work normally for an extended period, including multiple agent/tool turns.
- During an active development session, Codex may unexpectedly stop or lose the active session/turn.
- Recovery or restart is then required before development can continue.
- In some cases, session/continuation problems, including 404-related failures, have also occurred during long-running development sessions.
The failure is intermittent rather than tied to one specific command.
This is why I suspect a regression/reliability issue rather than a deterministic failure of a particular tool.
A useful diagnostic approach may be to correlate Windows telemetry across:
Last Known Good build → First Known Bad build → active tool execution → app-server lifecycle → session persistence → recovery/compaction
I can provide additional local diagnostic information or logs if Engineering identifies specific data that would help isolate the regression.
What is the expected behavior?
Codex Desktop should remain stable during sustained professional development sessions and preserve transactional development continuity if an internal component fails.
In particular:
- active tool calls should either complete and remain recorded or be clearly marked as interrupted;
- completed tool outputs should not be lost after recovery;
- repository changes should remain deterministically identifiable;
- recovery should not silently duplicate completed operations;
- sessions/threads should remain resolvable after an interruption;
- context compaction should not compromise session integrity;
- an app-server restart should not corrupt or invalidate the active development state.
For professional agentic development, the expected reliability property is not merely that the Desktop window remains open, but that development can continue from a deterministic and recoverable state.
Additional information
Environment
- Windows 11 25H2
- Codex Desktop
- ChatGPT Plus
- Professional sustained software-development workflow
- Local repositories with repeated shell/tool execution
Why I am reporting this as a possible regression
Codex had previously been stable on the same general development environment.
The significant observation is therefore not simply that Codex can crash, but:
previously stable environment + later release family + new recurring failure pattern + similar independent Windows reports + persistence across subsequent builds
Public reports that appear relevant include:
-
[Windows][26.818.2872.0] Codex Desktop crashes during tool execution; app-server restarts and resumes thread #39964 – Windows Desktop failure during tool execution
-
Windows: app-server killed with STATUS_CONTROL_C_EXIT (0xC000013A) mid command execution; regressed in 26.818.5229 after being fixed post-26.810 #40231 – different stability characteristics across successive Desktop builds / possible regression window
-
[Windows] Automatic compaction repeatedly embeds inline images, growing a long-running rollout beyond 16 GiB #40323 – automatic compaction associated with extreme rollout growth
-
Windows desktop: Work Mode repeatedly restarts app-server during tool calls, leaves missing tool outputs, and consumes usage #40400 – repeated app-server restart and missing tool outputs
-
Windows Codex Desktop repeatedly shows “ChatGPT stopped unexpectedly” during active tool turns after WebSocket retries #40607 – active tool-turn failure associated with transport retries/app-server replacement
-
[Windows] Codex Desktop app-server repeatedly restarts and loses tool call outputs #41236 – app-server restart with missing custom tool-call outputs
-
Windows desktop: browser-process crash loop persists across 26.820.7780 → 26.825.3734 #41268 – Windows crash behavior reported as persisting across newer Desktop releases
-
Codex task history corrupted after Windows app crash #41333 – task/session history corruption after a Windows interruption, with failed recovery and thread-store inconsistency
These references are provided for correlation only.
I am not asserting that they have a common root cause.
Local observation vs. independent reports
| Observation | Seen locally | Independently reported | Root cause established |
|---|---|---|---|
| Unexpected Codex interruption | Yes | Yes | No |
| Repeated development-session failures | Yes | Yes | No |
| Session recovery required | Yes | Yes | No |
| 404 / compaction-related problems | Yes | Yes | No |
| app-server process replacement | Not locally instrumented | Yes | No |
| Extreme rollout growth (>16 GiB) | No | Yes | No |
| Common root cause | — | — | No |
Questions for Codex Engineering
-
Are these Windows Desktop reports being correlated internally as a broader reliability regression?
-
Has a Last Known Good / First Known Bad build range been identified?
-
Is there currently a recommended Known Good Windows Desktop build for sustained development work?
-
Has any causal relationship been established between app-server restart, tool-output loss, session recovery/404 failures and compaction/session-state behavior?
-
Is there a supported way for affected Windows users to remain temporarily on a qualified stable build while this is investigated?
A Windows-specific Known Issues notice identifying affected builds, known-good build, workaround, fix status and fixed-in version would be very useful for professional users.
Activity
github-actions commentedon Aug 28, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
ato4040 commentedon Aug 29, 2026
Additional post-update reproduction from a Windows Codex Desktop user on 2026-08-29 (Asia/Taipei).
This user had previously experienced authentication/history/MCP/Remote failures, then updated Codex Desktop. Authentication/use became possible again, but the longer-running task stability problem remains.
Post-update behavior observed twice so far:
Impact:
The exact installed build number was not captured in this reproduction. The important signal is that the failure persisted after applying the available Desktop update.
This appears consistent with the multi-release reliability pattern described in this issue: sustained task execution -> unexplained stall/freeze -> restart required -> session recovery/resume -> recurrence.
If maintainers need it, a screenshot showing the stuck Desktop task list with persistent spinners/status indicators is available. No credentials, project contents, task IDs, repository paths, or other sensitive information are included here.
Alexaura666 commentedon Sep 2, 2026
Additional Windows 11 reproduction from issue #42323 (2026-09-02).
Environment:
Observed behavior:
In the latest occurrence, that post-crash forensic check showed the active task had actually completed one local commit before the crash, while the following task was left partially modified but unstaged. This reinforces the continuity problem: local project state is durable, but task/session state after the desktop crash is not sufficiently trustworthy without manual reconciliation.
I reviewed the suggested related issues. This seems closest to the broader multi-release reliability pattern described here, with overlap to #41268 (browser/main-process crash loop) and #41236 (active tool/task interruption). It is not the same failure as #41333 because no task-history corruption or lost Git/database data was observed in this reproduction.
Original report: #42323.
STREALOK commentedon Oct 8, 2026
Historical Windows recovery/continuation observation — 4 October 2026
This adds a qualified continuity symptom to the existing investigation. It does not establish the proposed multi-release regression, an app-server replacement or a shared cause with the other reports.
User-reported sequence: the desktop app appeared to reopen automatically, roughly within a split second. A blank dark-grey background lasted about 1–2 seconds before/after the recovery. The active workflow returned briefly, then another second or two later a summary appeared and the workflow ended. Similar recovery-like screens had been reported over the preceding 2–3 months, without a verified episode count or common trigger.
These timings are the user's estimates. App crash, renderer reload, UI recovery, forced compaction and the responsible process have not been established from this report. Workflow termination does not by itself prove artifact loss or thread-history corruption.
Resource context: the dated diagnostic recorded system commit at about 99.44% while physical RAM still had about 4.79 GiB available. Those are different counters; commit is not physical RAM occupancy or actual pagefile use. Exact crash-time alignment and causality are unknown. Subsequent resource relief after a separate browser closure does not prove that the Codex issue was fixed.
A bounded fixed-pattern app-log screen and selected named-application Windows event checks found no matching records in their stated scope. That negative result does not establish that no crash/reload/OOM occurred.
Reproduction: this is a historical reported workflow, not a deterministic or clean-state reproduction. No crash, memory exhaustion, allowance depletion or process restart was deliberately induced for the report.
Environment / (Related (and installed) / Used) Runtimes & Redists: Windows desktop; incident-time app/core/build/channel and implicated runtime/redist versions are unknown in the selected record. Later updater or runtime values are not assigned retroactively.
Engineering proposal: after recovery or compaction, expose the last durable operation and pending/failed operations, distinguish a completed summary from an interrupted run, and offer a clear continuation path that does not replay completed mutations. This is a proposed diagnostic/recovery improvement, not an identified cause or tested fix.
Original logs, transcripts, task identifiers, private applications/projects, screenshots and device/account details are omitted.