Repository navigation
[Windows][26.924.2738.0] Repeated renderer crashes, white-screen reloads, and severe input lag after update #48938
Description
Severe impact on my work, planned leave, expenses, and paid usage allowance
I am a paying ChatGPT Pro subscriber on the 20x Codex plan, using it for intensive work across multiple concurrent tasks.
I am extremely angry about this incident and the lack of a meaningful explanation while serious disruption continues. This is the most severe failure I have experienced using ChatGPT/Codex. The consequences extend far beyond a slow interface.
Time set aside for important work has been consumed by the failure
I had arranged time off work in advance so that I could concentrate on very important work over September 26–29, combining the weekend with Monday and Tuesday. I did not take leave in order to troubleshoot this app. After the update late on Saturday, the failures disrupted the work I had planned for Sunday and Monday. Tuesday was also part of the planned work period; I am not claiming that future time has already been lost.
Over roughly a day and a half of troubleshooting, I have spent substantial time and effort investigating, waiting for the interface to recover, repeating explanations, re-entering lost text and voice input, and redoing work. This has also affected my sleep. These were hours I had deliberately reserved to make progress on important tasks.
Actual additional expenditure: JPY 34,320 including tax
During Codex-assisted troubleshooting, the investigation focused on PC hardware before matching reports of problems with this app version were identified. I ordered a 32 GB RAM upgrade for JPY 34,320 including tax. That is an actual additional purchase made in the course of dealing with this incident. RAM shortage has not been established as the cause, and the upgrade has not been shown to resolve these failures.
The purchase amount does not measure the total impact on my time, leave, sleep, effort, or paid usage allowance. My compensation request is for additional usage allowance / a banked Full reset credit; I am not asking for reimbursement of the RAM purchase. Order identifiers, payment details, and the receipt are kept private.
A Full reset was used, but troubleshooting and repeated work consumed the allowance
I use the Pro 20x plan and have actually used a banked Full reset. The UI failures continued afterward. Restoring the allowance did not restore my ability to work normally: substantial allowance has gone into investigating the failure and repeating work.
I run multiple tasks using Astra. The failure also prevents me from supervising and correcting those tasks at the right time:
- I need to open a conversation to check progress or correct the direction of a task.
- The interface freezes, will not switch conversations, or will not accept input.
- Work continues while I cannot intervene, sometimes in a direction I did not intend.
- By the time I can give instructions, substantial work has already been done and has to be sent back and repeated.
- Both the initial work and the rework consume time and paid usage allowance.
Background agents continuing to run does not mean that I can work normally. Being unable to supervise them creates additional rework and consumption, beyond the time spent waiting for the UI. I have not calculated an exact token count, number of repeated runs, or monetary value for this additional consumption. I ask Support to examine whatever reset and usage records can be correlated with this incident.
Why I am angry, and what I need OpenAI to do
I am losing time reserved for important work, sleep, effort, money spent on hardware, and paid usage allowance. The continuing lack of an adequate explanation compounds the disruption and damages my trust. From an affected user's perspective, a severe recurring failure without clear public acknowledgment feels like the problem is being concealed. That describes my experience of the lack of transparency.
Please provide a clear acknowledgment of this Windows app problem, the known affected versions and scope, progress on the investigation and fix, and a safe workaround that preserves existing conversations, projects, and running work. I also request a substantive explanation and apology, and a concrete decision on additional usage allowance / Full reset compensation for the loss of usable service and additional consumption. A reset credit granted before this incident must not be presented as new compensation for it.
I am publishing this experience from Japan so that other users can understand the practical consequences and avoid spending the same time and money. The technical evidence below accompanies this report of harm to my work and daily life.
Version and system
- Microsoft Store package: OpenAI.Codex_26.924.2738.0_x64__2p2nqsd0c76g0.
- App update checker: 26.924.22138, build 11645, production channel, up_to_date. Previous installed package: 26.908.9136.0.
- Windows 11 Pro 25H2, build 26200.9457, x64.
- HP Pavilion Gaming Desktop TG01 series; AMD Ryzen 5 3500 (6 cores / 6 threads); 16 GB DDR4-3200 (2 x 8 GB); NVIDIA GeForce RTX 3060 with 12 GB VRAM; 256 GB Samsung NVMe system SSD with approximately 57 GB free at inspection.
- Model is not established as a trigger: symptoms occur while typing, scrolling, or switching tasks without submitting a prompt.
What happened
I had not experienced these symptoms before updating the Windows desktop app. Windows AppXDeploymentServer events 855 and 400 show the update from 26.908.9136.0 to 26.924.2738.0 completing at 2026-09-26 22:53:47 JST. The first retained Crashpad sidecar for a renderer crash was modified at 23:07:08 JST, 13 minutes 21 seconds later.
Since then, the desktop UI repeatedly turns white and reloads to Home. Unsent typed text or voice dictation can be lost. Switching Codex tasks, scrolling a conversation, typing one romanized-Japanese keystroke, or deleting one character with Backspace can stall noticeably. Some stalls last tens of seconds or several minutes; a few required force-quitting after waiting over five minutes. During severe episodes, even the desktop mouse pointer becomes hard to move. The problem also occurs without voice input or sending a prompt.
Expected: the desktop UI remains responsive and preserves the current task and unsent draft during normal navigation and input.
Retained crash records
Crashpad sidecar metadata, counted as of 2026-09-28 18:07 JST:
| Date (JST) | renderer crashes | browser-process crashes |
|---|---|---|
| Sep 26 | 2 | 0 |
| Sep 27 | 24 | 0 |
| Sep 28 | 101 | 1 |
| Total | 127 | 1 |
These are retained capture_kind=crash metadata records, not a count of every white screen or stall. Sidecar filesystem modification times are not native stack timestamps. The inspected Crashpad reports directory retained sidecars but no usable native dump or stack. Windows also recorded Codex MoAppHang / Application Hang events on Sep 27 around 01:16, 02:23, and 21:44 JST.
Reproduction and checks
This recurs during ordinary use, but I cannot provide one deterministic click sequence. It happens when moving between tasks, scrolling, and typing in the composer; it has also happened without voice input or submitting any message. Please do not treat task switching as a proven root cause.
- Fully exiting and restarting the app helped only temporarily; failures recurred.
- Collapsing the sidebar did not improve input lag.
- Avast once used substantial CPU and was later uninstalled. Microsoft Defender is active, and Codex crashes continued.
- At sampled times, Windows still reported about 3.7–5.3 GB of available physical memory. These samples were not synchronized to every crash and cannot exclude brief resource spikes. GPU VRAM and SSD activity were not saturated in short observations.
- codex doctor found core installation, app-server connection, HTTP/WebSocket reachability, and inspected SQLite integrity healthy. It reported some history-index warnings, but their relationship to these crashes is unknown.
- No decisive matching GPU reset, disk fault, WHEA hardware error, or Windows-wide memory exhaustion event was found in the inspected System log interval. This does not rule out every local factor.
- A performance trace was captured during a period when the severe freeze did not reproduce; it does not identify the cause.
- No cache/history reset, reinstall, GPU-mode change, WSL switch, or controlled downgrade was performed, to avoid disturbing active work without a causal basis.
Related reports
My corresponding Developer Community report, now approved and published, includes the same user-impact statement: https://community.openai.com/t/windows-26-924-2738-0-repeated-renderer-crashes-white-screen-reloads-and-severe-input-lag-after-update/1401563/2
Other users report problems on the same package or app build, including different Windows hardware. These strengthen the update-regression hypothesis, but may represent different failure paths:
- Same package version, blank screen after updating on two different Windows PCs: https://community.openai.com/t/windows-chatgpt-app-26-924-2738-0-stuck-on-blank-screen-endless-spinner/1400979
- Same internal version/build, repeated browser/renderer crashes during Codex work: https://community.openai.com/t/windows-desktop-app-crashes-shortly-after-read-thread-returns-26-924-22138-build-11645/1401301
- Same package version, same-PC comparison with an earlier version smooth and 26.924.2738.0 intermittently freezing while RAM was not exhausted: [Windows][26.924.2738.0] Regression vs 26.917.9434.0: main ChatGPT.exe spikes to 30–40% CPU and UI intermittently freezes / becomes Not Responding #48665
Request and existing private support case
Please investigate the renderer crashes and UI performance regression in 26.924.2738.0 / app build 26.924.22138 (11645), and provide the response requested above. Please also advise how to collect a useful native crash dump or stack privately. If a fix is available or planned, please identify its version and release status.
I escalated a private OpenAI Support conversation on September 28 at about 14:29 JST. At the 18:14 JST check, I had not received a human reply, and I could not find an acknowledgment of this Windows desktop rendering issue on the public status page. These are the times of those observations.
This issue URL and the same correlation code have already been sent directly into my authenticated, existing Support conversation. The code was also sent to support@openai.com from the same account. The public reporter and the person raising that existing Support case are the same person. Please connect this report and the user-impact details with that case and share them with the engineering and usage-compensation teams.
Public correlation code: CDX-20260928-8C64E22E07.
No personal name, email address, employer, account or conversation ID, user path, project contents, order identifiers, payment credentials, or unreviewed raw logs are included in this public report.
Activity
github-actions commentedon Sep 28, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
jibe-dev-ship-it commentedon Sep 28, 2026
Updated the opening post to document the impact that the original technical report did not adequately convey: planned leave for important work diverted into troubleshooting, JPY 34,320 spent on a RAM upgrade during Codex-assisted troubleshooting, sleep and time lost, a Full reset actually used, and additional Astra usage from being unable to intervene before work had to be repeated. The post now states my anger and explicitly requests a fix, transparent acknowledgment, explanation and apology, and a decision on additional usage allowance. The same issue URL and correlation code CDX-20260928-8C64E22E07 were sent directly into my existing authenticated Support conversation.
jibe-dev-ship-it commentedon Sep 28, 2026
LuckRef commentedon Sep 29, 2026
Additional evidence from a different Windows machine on the same app 26.924.22138 / build 11645 / package 26.924.2738.0: #49255
The distinctive behavior here is that older history keeps loading upward even after all mouse/keyboard input stops, with scrolling problems and renderer auto-reloads. Four renderer Crashpad artifacts were recorded on September 29 within about 26 minutes. The main process and local app-server stayed alive.
In two 30-second pre-crash windows the log contained 293 and 50 history responses, respectively, plus 10 ResizeObserver errors in each. One candidate session file was about 1.514 GB on disk. This is response-count correlation, not proof of repeated cursors, OOM or the same root cause as this issue.
This machine has about 31.86 GiB RAM, with about 9.1 GiB free at an inspection sample; the sample was not synchronized with the crashes. Please include idle pagination/scroll anchoring in the investigation of this build, and provide a supported mitigation that preserves active work. Full sanitized context, timings and limitations are in #49255.
jibe-dev-ship-it commentedon Sep 29, 2026
@LuckRef Thank you for documenting this so carefully in #49255, especially the pre-crash history-response counts and the renderer reload timeline. Your measurements are valuable context for #48938.
On my PC, running the same Windows app (package 26.924.2738.0, internal 26.924.22138 / build 11645), repeated renderer crashes continue after upgrading to 32 GB RAM. As of September 29 at 19:37 JST, there were 286 retained crash records (283 renderer, 3 browser). Short observations during a period when the UI remained slow showed about 17–18 GiB of RAM free; these were not taken at the exact crash instants. Three recent renderer crash records were followed by React root reinitialization while the main process remained alive. Two subsequent
app_startspans took 9.4 and 11.1 seconds. During recovery, logs also showed repeatedConversation state not foundandunknown conversationmessages. We have not established whether these are causes or consequences.I am also seeing frequent extra delays compared with before this problem started: pressing Stop, or using Prioritize (「優先する」) to deliver a new instruction to an already running agent, can take several seconds—sometimes over ten seconds—longer to be reflected. My impression is that this happens at least about half the time; that is not a measured rate. This makes it difficult to stop or redirect ongoing work.
I have not specifically checked whether old history keeps loading upward while idle on my PC, so I have not confirmed that part of your observation or a shared root cause.
OpenAI, please cross-reference #48938 and #49255 and provide a fix or an interim workaround that preserves existing chats and active work.
Additional measured details
All times below are JST on September 29. Crashpad times are sidecar file modification times, not native exception timestamps.
MessagePort message errorat 16:53:50.141; primary React-root render requested at 16:53:52.748.app_startcompleted at 19:27:47.517 (9,382.5 ms); thread hydration recorded from 19:27:52.889.MessagePort message errorlines at 19:34:26.358; React-root render requested at 19:34:28.750;app_startcompleted at 19:34:38.094 (11,119.3 ms). The previously observed renderer was absent at subsequent sampling; new renderer processes had start times of 19:34:26.886 and 19:34:44.300. The sidecar cannot directly identify which process crashed.Conversation state not foundand 54unknown conversationlines. In 19:34:05–19:35:10, the counts were 116 and 43. In the preceding 19:20:00–19:27:36 window, it also contained 71No turns for conversationlines and 27 ResizeObserver warnings. I did not establish whether my input was idle during that preceding window. These messages and the MessagePort errors do not identify the initial cause; some may be part of recovery or occur without a visible failure.capture_kind=crash,osarch=x86_64, andptype=renderer. It contains no exception code or stack, and no native dump remained in the inspected Crashpad directory. The failing function is therefore still unknown.leesanbal-web commentedon Sep 29, 2026
Additional evidence from a separate Windows x64 machine on the newer Microsoft Store package OpenAI.Codex 26.928.1915.0 (ChatGPT.exe; app log build 12246), OS 10.0.26200.0.
The desktop interface repeatedly refreshes during active work and makes reviewing output difficult.
On September 30, 2026, 25 retained Crashpad sidecars between 04:26 and 07:06 KST all record capture_kind=crash, osarch=x86_64, ptype=renderer. These are sidecar modification times, not native exception timestamps, and do not necessarily account for every UI refresh.
A later system snapshot showed approximately 63.6 GiB total and 36.6 GiB free physical memory. This sample was not synchronized to crashes and does not rule out transient or per-renderer limits. The inspected sidecars do not identify the failing renderer, exception, stack, or root cause. No usable native dump was found in that directory.
No cache/history reset, reinstall, GPU setting change, or forced restart was performed during diagnosis. Please include this newer package in the investigation and advise a supported way to collect a useful private native crash trace without losing active work. User paths, conversation contents, account identifiers, and raw logs have been omitted.
jibe-dev-ship-it commentedon Sep 30, 2026
September 30 update: crashes continue on the newer build; Support announces a handoff after more than 45 hours
Thank you @leesanbal-web for the additional evidence. Crashes also continue on my PC with the same newer build.
After upgrading to 26.928.1915.0 / build 12246, 28 renderer crashes were recorded in approximately 152 minutes. The recorded crash total is 329.
Stuttering and delays in scrolling, clicking, task switching and input continue after both the RAM upgrade to 32 GB and this app update.
I also want other users to know how OpenAI Support has responded to this failure.
More than 22 hours for a request for additional evidence
On September 28, I requested escalation to a human Support specialist. After waiting more than 22 hours, the first reply asked me to send reproduction logs, environment details and a screen recording.
It offered no technical assessment of the crash records and diagnostic findings already supplied, and no concrete steps to restore usable operation.
I submitted the requested logs, environment details and three recordings about one hour later.
Another 16 and a half hours for “we cannot open the links; send the files again”
I had granted Support viewing access to the videos and explicitly stated from the outset that, if the links could not be accessed, I wanted a safe method for submitting large files.
In the end, working out how to submit the files, processing the videos and checking the attachments were all left to the user. While the app itself was difficult to operate, this also consumed my time and paid AI allowance.
More than 45 hours later: “we will pass this to our team”
About an hour and a half after the resubmission, the response finally said the information would be passed to the team for investigation, with a follow-up when there was an update or more information was needed.
More than 45 hours had already passed since I requested escalation to a human specialist.
You are passing this to the team now?! What was happening while I had been unable to get my work done since Saturday, cutting my sleep and repeatedly troubleshooting and re-entering lost input?
At this stage, there was still no confirmation that the videos could be played, no cause, no usable workaround, no fix schedule, no specific time for the next update, and no decision on usage compensation. The official status page also has no incident notice addressing these repeated Windows desktop renderer crashes.
After long waits, the responses have been requests for more evidence, resubmission through another method, and then notice of a future handoff. The failure continues. Time set aside for my work is being consumed by explaining the failure and preparing evidence.
I believe this problem is spreading and occurring concurrently among users around the world. Reports pointing to this are now appearing in multiple places. This is not just my problem.
I consider the delay and substance of this response to be very poor support quality. I am publishing this account so that other users of the same service can see the disruption and the support experience I have actually faced.
Public correlation code for the existing private Support case: CDX-20260928-8C64E22E07.
jibe-dev-ship-it commentedon Oct 1, 2026
October 1 update: Further updates have not resolved the problem. 552 recorded crashes, and still no technical answer after the support handoff notice
The problem continues on my Windows Codex installation. By the evening check on October 1, the recorded crash count had reached 552—223 more than the 329 in my previous public update.
Other users are reporting failures, including on a newer version
My PC is running 26.928.2636.0, but public reports show continuing symptoms on the newer 26.928.3736.0 as well.
These reports have not all been established to share one cause. They do, however, describe unusable UI across different PCs and usage conditions.
About 31 hours since the support handoff notice. Still no further reply.
jibe-dev-ship-it commentedon Oct 2, 2026
October 2 update: More than 131 hours since the failure began. Crashes continue on the latest version, 4866.0
Since about 13 minutes after updating the Windows app on the night of September 26, blank screens, returns to Home, freezes, loss of input, and various other failures have continued.
For more than 131 hours, I have been unable to get my work done properly in Work. Being able to have a conversation in ordinary Chat does not let me get that work done.
Updating to the latest version has not stopped the crashes
On the morning of October 2, I updated again to 26.928.4866.0 / internal version 26.928.40906, build 12694, but renderer crashes recurred.
The morning count reached 614 recorded crashes: 62 more than the previous evening's 552, with 29 recorded today alone. This update has not resolved the UI failure.
This morning, the app became impossible even to close normally, so I force-closed it through Task Manager. I have restarted the PC repeatedly.
Crashes during input erase what I have said
During typing or voice input, the screen turns white and returns to Home. When I reopen the original task, the input I was entering is gone.
If the app crashes before my voice input appears in the chat input field, what I have said is lost. Even after speaking for five minutes, I have to explain it all again from the beginning. My time is still being taken away.
Other users have also reported the screen reloading while typing on 3736.0. Similar new report, #50023
The support response timeline
I also want other users to know how OpenAI Support has responded to this failure.
More than 22 hours for a request for additional evidence
On September 28, I requested escalation to a human Support specialist. After waiting more than 22 hours, the first reply asked me to send reproduction logs, environment details and a screen recording.
It offered no technical assessment of the crash records and diagnostic findings already supplied, and no concrete steps to restore usable operation.
I submitted the requested logs, environment details and three recordings about one hour later.
Another 16 and a half hours for “we cannot open the links; send the files again”
I had granted Support viewing access to the videos and explicitly stated from the outset that, if the links could not be accessed, I wanted a safe method for submitting large files.
In the end, working out how to submit the files, processing the videos and checking the attachments were all left to the user. While the app itself was difficult to operate, this also consumed my time and paid AI allowance.
More than 45 hours later: “we will pass this to our team”
About an hour and a half after the resubmission, the response finally said the information would be passed to the team for investigation, with a follow-up when there was an update or more information was needed.
More than 45 hours had already passed since I requested escalation to a human specialist.
You are passing this to the team now?! What was happening while I had been unable to get my work done since Saturday, cutting my sleep and repeatedly troubleshooting and re-entering lost input?
At this stage, there was still no confirmation that the videos could be played, no cause, no usable workaround, no fix schedule, no specific time for the next update, and no decision on usage compensation. The official status page also has no incident notice addressing these repeated Windows desktop renderer crashes.
After long waits, the responses have been requests for more evidence, resubmission through another method, and then notice of a future handoff. The failure continues. Time set aside for my work is being consumed by explaining the failure and preparing evidence.
I believe this problem is spreading and occurring concurrently among users around the world. Reports pointing to this are now appearing in multiple places. This is not just my problem.
About 46 hours after the handoff notice, finally a reply saying the recordings and logs were reviewed
On October 2, a reply signed by a different support representative said the recordings and logs had been reviewed. About 131 hours had passed since the failure began.
This reply said the recordings corroborated blank screens, returns to Home, and delayed task switching. It also described UI reinitialization, prolonged timeouts, and conversation-state errors in the logs.
It said there was sufficient evidence to continue the internal investigation, and that I did not need to submit further diagnostics or repeat previous troubleshooting at this time. It also apologized for the disruption and the time and paid usage spent documenting, investigating, and working around this problem.
However, it said the underlying cause, an internal bug number, a fixed version, a safe workaround, and a resolution timeline had still not been confirmed.
The next internal step was to complete known-issue matching and, if there was no exact match, route the evidence for deeper crash and telemetry analysis. No concrete way to resume work or outlook for a fix was provided.
Regarding compensation, the English original said my request for additional usage allowance equivalent to “one Full reset” had been recorded. That decision also remains unconfirmed.
I believe this is the reply that should have come at the beginning
Support finally acknowledged this serious failure that we have been discussing around the world about 131 hours after it began, and about 91 hours after I contacted them.
There is still no concrete way to resume work and no outlook for a fix.
I did not say “one Full reset is enough.” I still cannot operate the app properly on my PC and am keeping things going through my iPhone and iPad. I paid out of pocket for RAM and replaced it as part of troubleshooting, and have already used up two of my banked Full resets. The failure continues. I am on the $200 Pro plan.
Lost time, leave reserved for work, usage allowance consumed by investigation and repeated work, the RAM purchase, and work that did not get done—the harm is too extensive to list.
Reading a reply that records this as a request for additional allowance equivalent to one Full reset, I was astonished: did they think all this harm could be covered by 100% of one week's usage allowance? I feel they have imagined absolutely nothing about what users like us around the world have lost and how much difficulty we are still facing.
Even that one reset's worth of additional allowance has not been decided. I am extremely disappointed that no compensation has been determined for the harm I have actually suffered.
I consider the delay and the substance of this response to be very poor support quality. I am publishing this so that others using the same service can see that the failure continues and understand the harm and the response that are actually occurring.
Public correlation code for the existing private Support case: CDX-20260928-8C64E22E07.
I am also reposting the account published on October 1.
leesanbal-web commentedon Oct 2, 2026
October 2 follow-up from the separate Windows user who provided the September 30 evidence above:
The problem is still disrupting my work. I continue to experience repeated app crashes / unexpected UI reloads while using two ongoing work conversations: IT스펙루트 (IT media work) and 오늘네편 (video production). This repeatedly interrupts my ability to use those conversations and make progress, and I am extremely frustrated that it keeps happening.
My September 30 comment documented 25 retained renderer-crash sidecars on package 26.928.1915.0 / build 12246. Those version and crash-count details belong to that earlier snapshot; I have not collected a fresh count or verified today's installed version for this follow-up. I am reporting continuing user-visible failures, not claiming that every reload is a newly verified renderer crash or that the root cause is identical to the original reporter's.
Please include this continuing impact across multiple existing work conversations in the investigation, provide an update on the fix, and advise a supported workaround that preserves conversation history and ongoing work. If more diagnostics are needed, please provide a safe private collection/submission method.
leesanbal-web commentedon Oct 2, 2026
I need to emphasize the real impact of my report above: these repeated failures are wasting my time and preventing me from getting my work done.
I am trying to work on IT스펙루트 and 오늘네편. Instead, the app keeps crashing or unexpectedly reloading and interrupting that work. Time that should go into completing my projects is being consumed by dealing with the app's failures. This is not a minor inconvenience. My working time is limited, and I cannot get that lost time back.
I am extremely frustrated that this is still happening after I already submitted crash evidence on September 30. Please treat the continuing loss of usable working time as a serious user-impact issue requiring urgent attention.
I am asking OpenAI for a substantive response: acknowledge the ongoing impact, explain the investigation status, provide a supported way to continue my existing work without losing conversation history, and give a concrete next update or fix timeline if one is available. If no timeline is available, please say so clearly and specify when users can expect the next progress update.
Please also explain what remedy is available for users whose time and ability to work have been materially affected. The time I am losing is real, and the disruption is continuing.
leesanbal-web commentedon Oct 2, 2026
Following up with a specific request for remediation: please grant a complimentary Codex usage reset, an additional Full reset credit, or equivalent additional usage allowance in recognition of the ongoing disruption.
The repeated crashes / unexpected reloads affecting my IT스펙루트 and 오늘네편 work are wasting the time I set aside to use the service and preventing me from making normal progress. I already provided crash evidence on September 30 and have now reported that the disruption continues.
I have not measured the exact amount of usage attributable to these failures, and I am not presenting an unverified token count or claiming that every crash itself consumes usage. My request is for a concrete goodwill remedy for the continuing loss of usable working time and ability to work.
Please treat this as a request for an additional compensatory reset or allowance, not advice to spend an existing reset credit or wait for the normal scheduled reset. Please route the request to the team authorized to assess it and provide a clear decision. If account-specific compensation cannot be handled through this public issue, please identify the appropriate private support channel and the information needed to link this report, without requiring account details to be posted publicly.
A reset would help me resume productive work, but it would not resolve the underlying app failure; I still need the stability issue addressed.
jibe-dev-ship-it commentedon Oct 2, 2026
@leesanbal-web Thank you for replying and sharing your experience and evidence. As affected users in different parts of the world, we are still facing similar failures that cost us working time and prevent us from getting our work done. I hope OpenAI resolves these problems urgently and provides an appropriate response to the harm users have experienced. I will continue asking for a proper response to the ongoing disruption and its impact on our work.
jibe-dev-ship-it commentedon Oct 2, 2026
October 3 update: Shared processing paths for UI operations and task coordination. 315 failed or interrupted coordination records and 775 crashes
1. Task coordination also depends on renderer-side processing
2. Breakdown of the 315 coordination records
Approximately 152 hours, from the onset of the incident through the morning of October 3.
Recorded outcomes: 235 error responses, 69 waits terminated before results were obtained, and 11 responses containing state lookup errors.
3. About five or six minutes just to check current state
These checks retrieve the target task's current state without waiting for its work to finish.
These were current-state checks, not requests to wait for work to finish, yet the responses were delayed by minutes. The waits were terminated without results, and the planned wake-up messages were not sent.
No renderer crash was recorded during that interval. Task coordination stalled even while no UI crash was recorded.
4. Latest version 2377.0: Another crash about five minutes later
I will share counts of task coordination problems alongside the UI crash count.
We users facing similar failures around the world are still unable to get our work done and continue to lose time; we will keep sharing the impact and the history of OpenAI's response with users worldwide, and we call on OpenAI for a prompt resolution and appropriate action.
Alongside UI crashes, I am sharing counts for the task coordination problems.
Public correlation code for the existing private Support case: CDX-20260928-8C64E22E07.
jibe-dev-ship-it commentedon Oct 4, 2026
October 4 update: ongoing incident — 782 crashes, 346 coordination failures/interrupted operations, and approximately 47 hours without a support reply
Approximately 178 hours after this incident began, unreadable conversations, lost input, and broken task communication still prevent me from moving my work forward.
This morning, severe stuttering and sluggishness returned and crashes recurred, although I restarted neither the PC nor the app.
Last night, all ten existing conversations I tested in Chrome failed to load. Some conversations also could not be displayed in the Windows app. Crashes erase unsent text or voice input and prevent me from reviewing deliverables or correcting ongoing work. Investigation and repeated input consume my own time and paid usage allowance.
Approximately 47 hours without further contact from support
I contacted support on September 28. On the morning of October 2, I received a reply from the technical team indicating the start of an investigation, but approximately 47 hours have passed since then without a new reply.
No root cause, usable solution, repair schedule, time for the next update, or compensation decision has been provided. While the incident continues costing me work and time, I am being left without concrete advice or further contact.
782 crashes in total, up by seven from the previously published 775. Seven today.
Task-coordination failures, interrupted operations, and related problems have increased from 315 to 346, an increase of 31.
New finding: app tools themselves disappear
Depending on the task, listing, conversation reading, messaging, and schedule-management functions disappear during ongoing work. Records from four tasks on the same PC show the app connection being excluded from tool provisioning. This is more than a failed communication request: the functions themselves become unavailable to call.
The current version is 26.930.2377.0, build 12776. The incident is still ongoing. I am seeking prompt resolution and an appropriate response to affected users from OpenAI.
Links to related user reports and technical investigations will be collected in a separate appendix comment.
Public correlation marker for the existing private support case: CDX-20260928-8C64E22E07.
jibe-dev-ship-it commentedon Oct 4, 2026
Appendix: related incident reports and technical investigations
My October 4 incident report
My current version is 2377.0. Different users have reported renderer crashes even in the later 3930.0 release. Reports collected by the incident-monitoring chat were checked against their primary sources and organized by symptom.
This index separates display problems, conversation retrieval, missing tools, and stalled communication. These reports have not all been established to share one root cause.
leesanbal-web commentedon Oct 4, 2026
jibe-dev-ship-it commentedon Oct 5, 2026
@leesanbal-web @LuckRef Thank you for sharing your experiences. I share the distress you describe about continuing to lose working time.
Here is my current situation:
I also strongly hope for prompt contact from OpenAI and a solution that lets me resume my work. I will continue sharing the impact and the history of the response.
jibe-dev-ship-it commentedon Oct 5, 2026
October 5 update: OpenAI officially reports errors affecting Work and Codex in the desktop app; mitigation applied, recovery under monitoring
OpenAI has officially announced "Elevated Work Mode errors".
However, the details of the incident remain undisclosed. I would like OpenAI to explain specifically what errors occurred, what was addressed, and how far the response covers the problems that have been continuing since before this announcement.
The response may include measures addressing the problems we have been reporting. However, the specific error types, causes, and mitigation details have not been published, so we do not know how far this covers the earlier renderer crashes and UI latency.
jibe-dev-ship-it commentedon Oct 5, 2026
October 5 update: First clear return to near pre-incident responsiveness after the official mitigation announcement
On my Windows machine, the app suddenly became usable again after being largely impossible to operate on the PC since the September 26 update. Responsiveness is now close to what it was before that update. After roughly nine days, I have finally been freed from this nightmare of an incident.
All times below are October 5, UTC.
Until then, I had been experiencing the following:
These operations are now smooth, and the app feels close to its pre-incident state. There had been periods with fewer recorded crashes or coordination failures before, but this is the first time my own experience of using the app has recovered to this level.
Task-to-task messaging and status checks have also returned normal responses. The app version remains 26.930.2377.0, and I did not restart the PC or the main app process when this improvement occurred.
Because responsiveness has suddenly returned to a level it had not reached during this incident, the mitigation announced by OpenAI appears likely to be related to this improvement.
I will keep observing whether this improvement lasts or is temporary and followed by a recurrence. I also intend to continue following the experiences of other users affected by similar problems.
However, there has still been no further contact whatsoever from Support.
jibe-dev-ship-it commentedon Oct 6, 2026
October 6 update: About 95 hours without a reply from Support; dramatic improvement continues
About 95 hours have passed since OpenAI Support's last reply. There has been no further contact about the cause of the incident, the actions taken, or compensation.
Last night, I reported the improvement and asked for an explanation of the cause and the actions taken, and for a response on adequate compensation. That message has not received a reply either.
Meanwhile, the dramatic improvement described in my previous update has continued for about 12 hours, including this morning.
With the same version and the same PC/app startup session, the app has gone from a state in which I could not get work done properly to one in which I can operate it without problems.
I will continue monitoring whether this improvement lasts. I will also continue asking Support for an explanation of the cause and the actions taken, and for a response on compensation.
jibe-dev-ship-it commentedon Oct 6, 2026
October 6 update: Recurrence after restarting the PC and app; OpenAI announces recovery, but Support remains silent for about 108.5 hours
The Windows app had improved, but became severely sluggish again after I restarted the PC and app.
The symptoms returned after a restart despite the earlier improvement. They then improved again without any additional action.
I will continue observing whether this state lasts or the symptoms recur.
OpenAI announced recovery from the incident affecting Work and Codex in the desktop app today at 02:10 UTC.
However, I have not even been notified of the recovery. About 108.5 hours have passed since Support's last reply, with no further contact about the cause of the incident, the actions taken, or compensation.
Future improvements and compensation for harm already caused are separate matters
In his 28-day announcement, Tibo stated that each day the team would either ship a clear improvement relevant to most Codex and Work users or provide a usage reset.
Users around the world who have suffered from this incident cannot be satisfied with promises of future improvements while the substantial harm already caused remains unaddressed. First, OpenAI should acknowledge the harm already suffered, explain the cause and the actions taken, and offer concrete compensation proportionate to the actual damage.
jibe-dev-ship-it commentedon Oct 8, 2026
10月8日続報：再び操作不能。クラッシュ833件。サポートは約156時間、音沙汰なし
改善していたWindowsアプリが再びフリーズし、PC・アプリ再起動後も障害が継続。現在、PCではほとんど操作できず、仕事を進められません。
結果が返った連携操作でも、遅延が増えています。
一律のリセットより、障害修正と実害への補償を
まず、この障害を直し、深刻な被害を受けた利用者に、実害に見合う補償をしてください。
一律の利用枠リセットや今後の改善の約束は、今回の障害修正と、既に生じた被害への補償の代わりにはなりません。
仕事を再開できる状態への修正、原因と対応内容の説明、具体的で十分な補償を求めます。
jibe-dev-ship-it commentedon Oct 9, 2026
10月9日続報：開発側が「修正取り込み済み、近く配布」と回答。サポートは約171時間、返信なし
OpenAIのCodex開発側のアカウント @yuzhu-oai が、10月9日午前5時32分（日本時間）、関連報告に次のように返信しました。
**「修正は取り込まれており、近く配布されます」**という意味です。開発側の返信
これは、非表示の画面で会話を再開しようとする処理が繰り返され、大量のログと負荷が発生する問題への回答です。利用者が分析と回避策を報告したスレッドで、Windowsでの再現報告もあります。
半年以上前から、デスクトップアプリの異常な負荷や、仕事を進められないほどのフリーズが報告されています。3月のWindows報告、4月の高負荷報告
私自身も9月26日から、仕事、時間、有料利用枠を失い続けています。今回、会話を再開しようとする処理の問題について、ようやく開発側から修正取り込みと配布予定が示されました。
私は、この修正版の配布を注視しています。どのWindows版に含まれるのかは、まだ確認できていません。実際に仕事を再開できる状態になることを強く期待しています。
個別サポートは、問い合わせても返信なし
最後のサポート回答から約171時間、新しい連絡は一切ありません。
追加の問い合わせにも、返事がありません。メールを読んでいただけたのかすら分かりません。障害の原因と対応内容の説明も、補償の決定も届いていません。
開発側の公開返信があっても、被害を受けて問い合わせた利用者への対応がないままです。
OpenAIには、早急な返信、仕事を再開できる修正、そして既に受けた実害に見合う具体的で十分な補償を求めます。
jibe-dev-ship-it commentedon Oct 15, 2026
最終報告：Windows画面障害の解決と、約2週間の業務被害・個別補償なしの記録
1. 画面障害は解決済み
10月10日、Windows版 26.1007.2314.0 への更新後に画面障害が解消。
対象は、繰り返す画面フリーズ、極端な重さ、入力・スクロール・会話切替の支障。更新前はPC再起動でも改善せず、更新後は再発なし。
本Issueで報告した画面障害は、私の環境では解決済み。
一方、別件の応答途中の切断エラーは現在も繰り返し発生し、業務への支障が継続。コンテキストの圧縮失敗も一部で継続。圧縮失敗の減少は本人の体感であり、解消の確認には至らず。
2. 約13日間、ほぼ2週間にわたる業務被害
発生は9月26日夜、画面症状の解消は10月10日朝。途中の一時改善と再発を含め、約13日間にわたるPC作業への深刻な支障。
200ドルプランの料金を支払いながら、iPad・iPhoneでの代替作業を余儀なくされた状況。
文章や音声による指示と、チャットの言葉を頼りにした作業への制限。
最大の被害は、進めるはずだった仕事の時間と機会の喪失。画面の復旧後も取り戻せない損失。
3. 具体的な解決支援・個別補償なし
サポートによる聞き取りと、資料を受領した旨の担当者返信は存在。
その後、業務を復旧させる具体的な対処、原因・修正内容の明確な説明、被害への個別補償に関する回答は得られないまま。
利用者自身による障害記録の収集、ログ調査、類似報告の検索、GitHubへの継続的な情報提供。その調査にも、自分の時間と有料の利用枠を大量に消費。
本件の個別補償として提供された利用枠リセットはゼロ。
仕事を止められた利用者が、自費で製品の障害調査まで負担し、具体的な支援も個別補償も得られない状態。
4. 一斉リセットへの評価と、被害者への個別補償の要求
Tibo氏による28日間の改善の取り組み、一斉の利用枠リセット、後から使えるリセットの配布については、高く評価。今後も継続を希望。
同時に、障害で仕事を止められた利用者への個別補償を要求。
広く配布されるリセットと、実際に被害を受け、調査にも協力した利用者への補償は、それぞれ必要な対応。
本件についても、利用枠のリセットなど、実際の救済につながる補償と、その提供方針の明示を要求。
5. Claude Coworkとの利用経験の差
GPT Workより長い期間、Claude Coworkを利用。私の利用範囲では、今回のように仕事を長期間止められる障害の経験はゼロ。
私自身の利用体験に基づく評価は、Claude Coworkが100点なら、今回のGPT Workの体験は0点。評価の対象は、仕事を続けられる安定性と障害時の対応。
OpenAIへの強い警告。仕事を止める重大な障害を繰り返し、被害を受けた利用者への十分な支援や補償を行わなければ、信頼と支持を失い、ClaudeやGeminiへの利用者の移行を招く。
6. 今後も障害と対応の実態を継続公開
本Issueの画面障害は、私の環境では解決済み。これを画面障害の最終報告とする。
今後も障害が発生した場合は、発生日時、利用版、症状、業務への影響、確認できた証拠を整理し、GitHubをはじめとする公開媒体で世界の利用者へ共有。
OpenAIのサポートが行った対応と行わなかった対応、個別補償の有無も含め、事実に基づく継続公開。
同じサービスを仕事に使う人が、障害の実態と受けられる支援を確認し、サービス選択を判断するための記録。