[Windows][26.924.1866.0] App launches to a permanent blank white screen after update

Title:
[Windows][26.924.1866.0] App launches to a permanent blank white screen after update

Summary:
After updating the ChatGPT/Codex Windows desktop app from the Microsoft Store to version 26.924.1866.0, the app launches but the entire client area remains permanently blank white.

The native window frame appears, but the UI never renders.

Environment:

ChatGPT/Codex Desktop version: 26.924.1866.0
Windows 11 Pro
OS build: 22631.6199
Package: OpenAI.Codex_26.924.1866.0_x64__2p2nqsd0c76g0
Package status: Ok

What I already tried:

Repair from Windows Settings
Reset from Windows Settings
Uninstall and reinstall from Microsoft Store
Reboot Windows
Fully terminate all ChatGPT/Codex/OpenAI processes
Rebuild LocalCache
Re-provision the elevated Codex sandbox
Relaunch normally
Try launching as administrator

Current behavior:

Normal launch: permanent blank white window
Run as administrator: fails immediately with:
"ChatGPT failed to start. The process has no package identity."

Diagnostics:

Codex Doctor: 0 failures
Authentication: configured successfully
stored auth mode: chatgpt
stored ChatGPT tokens: true
WebSocket connection: HTTP 101 Switching Protocols
ChatGPT inference endpoint: reachable
Desktop assets CDN: HTTP 200
Sandbox provisioning: complete
AppX package status: Ok
renderer processes are running
GPU process is running
network service is running
codex.exe app-server process is running

Additional observations:

GPU process reports:
--gpu-recent-crash-count=0
No new Application Error or Application Hang event is generated when the blank screen appears.
The documented log directory exists:
%USERPROFILE%\AppData\Local\Codex\Logs
but it contains no log files.
LocalCache is recreated successfully after deletion/renaming.
ChatGPT works normally in the web browser.
The issue started immediately after the Microsoft Store update.

Relevant process types observed:

ChatGPT.exe --type=gpu-process
ChatGPT.exe --type=renderer
ChatGPT.exe --type=utility --utility-sub-type=network.mojom.NetworkService
ChatGPT.exe --type=utility --utility-sub-type=storage.mojom.StorageService
codex.exe app-server

Expected behavior:
The desktop app should render the normal ChatGPT/Codex UI.

Actual behavior:
The app window opens but remains completely blank white indefinitely.

Impact:
The Windows desktop app is currently unusable, although the web version still works.

I can provide:

Screenshot of the blank white window
Screenshot of the "process has no package identity" administrator-launch error
Codex Doctor output
Windows Event Viewer output
Process command-line output

Please let me know if there is any additional diagnostic command or trace I should collect.

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

[Windows][26.924.1866.0] Desktop stuck on gray loading screen while backend and Pet remain active #48216

Powered by Codex Action

Same bug on 26.924.1866.0 (MSIX OpenAI.Codex_26.924.1866.0_x64__2p2nqsd0c76g0, build 11431, commit 97cf4a3c), Windows 10 Pro 22H2 (19045), NVIDIA RTX 2080.

It started with the update from 26.917 (build 10954). My last launch on 26.917 loaded normally. Every launch on 26.924 failed.

Same fingerprints as the original report:

Renderer console: Matched leaf route at location "/" does not have an element or Component
Every failed launch logs name=app_start outcome=failure reason=timeout at about 122 s. Marks reach settings_ready (about 4 s) and never reach shell_visible or home_visible.
The app-server is healthy but never receives thread/list, thread/read, model/list or skills/list. It only sees initialize, experimentalFeature/enablement/set and remoteControl/enable.
The main log shows bundled_plugins_reconcile_skipped_features_unavailable on every failed launch.
Setting aside ~/.codex/.codex-global-state.json did not help.

_reload workaround _

The reload workaround here: #48216 works. I launched with --remote-debugging-port (127.0.0.1) and sent Page.reload {ignoreCache:true} to app://-/index.html. The DOM went from 55 elements, no text and no inputs to 3,287 elements with the composer. That launch logged app_start outcome=success at 6.2 s (home_visible 5.4 s, sidebar_ready 6.2 s), followed by thread/list and thread/read.

Launching with this script via PowerShell solves the issue temporarily.

# Fix Codex blank screen
# Workaround for https://github.com/openai/codex/issues/43960
# Starts the Codex desktop app with a localhost-only debugging port, and if the
# main window comes up empty, reloads it once. Your chats and settings are not touched.
# How to run: right-click this file > "Run with PowerShell".
# The debugging port closes when you quit Codex.


$ErrorActionPreference = 'Stop'

$pkg = Get-AppxPackage OpenAI.Codex
if (-not $pkg) { Write-Host "Codex app is not installed."; Read-Host "Press Enter to close"; exit 1 }
$exe = Join-Path $pkg.InstallLocation 'app\ChatGPT.exe'

$running = Get-Process -Name ChatGPT -ErrorAction SilentlyContinue
if ($running) {
    $ans = Read-Host "Codex is already running. Close it and relaunch with the fix? (Y/N)"
    if ($ans -notmatch '^[Yy]') { exit 0 }
    Get-Process | Where-Object { $_.ProcessName -in 'ChatGPT', 'codex' } | Stop-Process -Force
    Start-Sleep -Seconds 3
}

$port = Get-Random -Minimum 40000 -Maximum 60000
Write-Host "Starting Codex (version $($pkg.Version))..."
Invoke-CommandInDesktopPackage -PackageFamilyName $pkg.PackageFamilyName -AppId 'App' -Command $exe -Args "--remote-debugging-port=$port --remote-debugging-address=127.0.0.1"

$target = $null
for ($i = 0; $i -lt 60 -and -not $target; $i++) {
    Start-Sleep -Seconds 1
    try {
        $target = Invoke-RestMethod "http://127.0.0.1:$port/json/list" -TimeoutSec 2 |
            Where-Object { $_.type -eq 'page' -and $_.url -like 'app://-/index.html*' } | Select-Object -First 1
    } catch { }
}
if (-not $target) { Write-Host "Could not find the Codex window after 60 seconds."; Read-Host "Press Enter to close"; exit 1 }

function Send-Cdp($wsUrl, $method, $params) {
    $ws = New-Object System.Net.WebSockets.ClientWebSocket
    $ws.ConnectAsync([uri]$wsUrl, [Threading.CancellationToken]::None).Wait()
    $msg = @{ id = 1; method = $method; params = $params } | ConvertTo-Json -Compress -Depth 5
    $bytes = [Text.Encoding]::UTF8.GetBytes($msg)
    $ws.SendAsync([ArraySegment[byte]]$bytes, 'Text', $true, [Threading.CancellationToken]::None).Wait()
    $buf = New-Object byte[] 65536
    $res = $ws.ReceiveAsync([ArraySegment[byte]]$buf, [Threading.CancellationToken]::None).Result
    $out = [Text.Encoding]::UTF8.GetString($buf, 0, $res.Count)
    try { $ws.CloseAsync('NormalClosure', '', [Threading.CancellationToken]::None).Wait() } catch { }
    $out
}

function Get-PageSize {
    $r = Send-Cdp $target.webSocketDebuggerUrl 'Runtime.evaluate' @{ expression = 'document.querySelectorAll("*").length'; returnByValue = $true } | ConvertFrom-Json
    [int]$r.result.result.value
}

Write-Host "Waiting for the window to finish its first load..."
Start-Sleep -Seconds 12
$before = Get-PageSize

if ($before -ge 500) {
    Write-Host "Codex loaded normally ($before page elements). No reload needed."
} else {
    Write-Host "Window is blank ($before page elements). Reloading..."
    Send-Cdp $target.webSocketDebuggerUrl 'Page.reload' @{ ignoreCache = $true } | Out-Null
    Start-Sleep -Seconds 20
    $after = Get-PageSize
    if ($after -ge 500) { Write-Host "Fixed: Codex is loaded ($after page elements)." }
    else { Write-Host "Still blank after reload ($after page elements). Try running this again." }
}
Read-Host "Press Enter to close this window (Codex stays open)"

Confirmed: the reload workaround described above also recovered the desktop UI on Windows MSIX version 26.924.1866.0. The user has visually confirmed that the normal UI and composer are available.

One timing detail from this run: reloading immediately when the debugging target first appeared did not work. Sending CDP Page.reload with { "ignoreCache": true } again after initial startup had settled restored the UI within about 10 seconds.

We used Store app activation (IApplicationActivationManager) with a debugging listener bound to 127.0.0.1, then targeted app://-/index.html. No reset, reinstall, or local data deletion was needed. A normal restart has not been retested, so this remains a temporary workaround.

Detailed successful sequence and verification: #48216 (comment)

Thanks for sharing the workaround.

Title: [Windows][26.924.1866.0] Desktop app stuck on loading spinner after update

After updating the ChatGPT/Codex Windows desktop app to version 26.924.1866.0, the app no longer finishes loading. It opens a dark window with a spinning loading indicator, but never reaches the main interface. The app worked normally before the update.

Environment

Windows 11, x64, build 26100
Desktop app version: 26.924.1866.0
Subscription: ChatGPT Plus
Incident observed: September 26, 2026, approximately 11:38 AM (UTC+8)

Troubleshooting already attempted

Resetting the app through Windows Settings
Uninstalling and reinstalling the app
Switching networks, including a mobile hotspot

None of these resolved the issue. ChatGPT remains accessible in my web browser.

Relevant log findings

The local app-server initialized successfully.
The log reports that host startup critical-path phases completed.
A request to /accounts/check/v4-2023-04-27 returned HTTP 403, with an HTML response containing Cloudflare challenge scripts.
Shortly afterward, a separate account lookup was logged as successful.
Background worktree archive retries also report Git is unavailable.

I cannot confirm whether the HTTP 403 response is responsible for the loading spinner or whether this is a separate issue introduced by the update.

Could you investigate and provide a recovery method? I can provide a screenshot and sanitized logs.

Additional reproduction and isolation results for the post-update startup hang on Windows MSIX 26.924.1866.0.

Environment

Date observed: 2026-09-26.
Windows 11 Pro, version 10.0.26200, x64.
Installed package: OpenAI.Codex, 26.924.1866.0, x64 (verified from Windows package metadata; the affected UI cannot open About).
Affected account subscription: ChatGPT Pro.
This concerns the standalone Codex/ChatGPT desktop app, not the VS Code extension.
The user reports that the issue began after an app update.

Additional account/profile comparison

The affected account authenticates successfully, but the desktop stays on the loading screen and never displays its home/sidebar. Two other accounts using separate local profiles on the same Windows machine and the same installed desktop binary reach app_start outcome=success, with home/sidebar startup marks present.

The affected account still fails when it is the only running desktop instance. This comparison does not establish an account-side root cause, but may help isolate the startup path or timing involved.

Troubleshooting already performed

The hang persisted after:

Restarting the affected desktop process.
Regenerating browser caches and UI storage.
Isolating optional persisted UI settings.
Using a separate, clean app profile and separate CODEX_HOME.
A successful account/read token refresh.
Removing the copied authentication from the clean test profile and completing a fresh manual ChatGPT sign-in. The log reports account_login_completed success=true, followed by successful account lookup, but the user still sees the loading screen.
Closing the other desktop instances and starting only the affected account through the ordinary registered Windows application entry point.

Original conversation/project data was preserved. Temporary changes to the original UI settings were restored.

Sanitized startup evidence

The affected-account log at 2026-09-26T04:27:54.202Z records:

name=app_start outcome=failure reason=timeout initialSurface=home

Startup marks include renderer_entry_evaluated, host_services_ready, renderer_ready, host_startup_ready, and settings_ready. The shell_visible, home_visible, and sidebar_ready marks are absent for that failed startup. Authentication/account lookup had already succeeded.

Separately, custom launchers for the other accounts initially failed with a missing Windows package identity. Launching those profiles within the registered package context resolved their launch errors. The affected primary account's loading hang persists through the normal registered app entry point, including with the other desktop instances closed.

The renderer reload workaround mentioned in this issue has not yet been tested in this environment. The underlying cause is not confirmed. Please investigate the post-authentication desktop startup path in this build.

No credentials, email addresses, account IDs, private filesystem paths, conversation content, or raw private logs are attached.

Reproduction complémentaire — version 26.924.2738.0 :

lancement normal fonctionnel, échec uniquement en administrateur

Je rencontre également le message « Le processus n’a aucune identité
de package » lors du lancement en administrateur.

Différence importante avec le signalement initial : sur mon installation,
ChatGPT démarre et fonctionne normalement sans élévation.
Je ne rencontre pas le problème de fenêtre blanche décrit dans ce ticket.

Environnement

Windows 11 Professionnel, version 25H2.
Build Windows : 26200.9550.
Architecture : x64.
Version du package de l’application : 26.924.2738.0,
vérifiée avec Get-AppxPackage.
Package :
OpenAI.Codex_26.924.2738.0_x64__2p2nqsd0c76g0
État du package : Ok.
Application enregistrée dans le menu Démarrer :
OpenAI.Codex_2p2nqsd0c76g0!App
Installation initiale effectuée en passant par le site officiel d’OpenAI.
Le mécanisme d’installation utilisé ensuite n’est pas confirmé.

Comportement observé

Le lancement normal fonctionne.

Lors d’un lancement avec « Exécuter en tant qu’administrateur »,
la demande UAC apparaît. Je valide « Oui », sans saisir les identifiants
d’un autre compte.

L’application affiche ensuite :

ChatGPT failed to start.
Le processus n’a aucune identité de package.

Diagnostic du processus pendant que l’erreur reste affichée

Un contrôle en lecture seule a identifié le processus associé à
la fenêtre d’erreur intitulée « ChatGPT ».

Processus : ChatGPT.exe
PID lors du contrôle : 38836
Démarrage du processus : 26/09/2026 à 12:17:06, heure locale du PC
Exécutable :
C:\Program Files\WindowsApps\OpenAI.Codex_26.924.2738.0_x64__2p2nqsd0c76g0\app\ChatGPT.exe

L’API Windows GetPackageFullName, appelée sur un handle de ce processus
ouvert avec PROCESS_QUERY_LIMITED_INFORMATION, retourne :

15700 — APPMODEL_ERROR_NO_PACKAGE

Cela confirme l’absence d’identité de package pour le processus portant
la fenêtre d’erreur lors de cette tentative.

En comparaison, un contrôle séparé de
codex-windows-sandbox-service.exe retourne bien l’identité :

OpenAI.Codex_26.924.2738.0_x64__2p2nqsd0c76g0

L’identité du processus ChatGPT.exe lors d’un lancement normal
n’a pas été mesurée : son fonctionnement a seulement été constaté.

Autres observations

Le fichier %USERPROFILE%.codex.sandbox\sandbox.log est absent
à l’emplacement contrôlé.
Les événements AppModel-Runtime retrouvés dans une fenêtre de
cinq minutes étaient de niveau Information.
Aucun événement n’a été retourné pour les journaux TWinUI/Operational
et Application sur cette période.
Les diagnostics présentés ont été réalisés en lecture seule.

Résultat attendu et demande

La documentation Windows d’OpenAI décrit le lancement de l’application
en administrateur pour permettre à l’agent d’hériter de ces droits.

Documentation :
https://learn.chatgpt.com/docs/windows/windows-app

Pouvez-vous examiner pourquoi ChatGPT.exe ne dispose pas d’identité
de package lors de cette tentative de lancement avec élévation ?

Je ne conclus pas que cette erreur a la même cause que le problème
de fenêtre blanche du ticket initial. Merci d’indiquer si ce cas
doit faire l’objet d’un ticket distinct.

Je peux fournir les captures du message et du contrôle ciblé.
Aucune transcription de session, donnée de projet ou information
d’authentification n’est jointe.

I can reproduce a very similar issue on Windows 11 with Codex Desktop 26.924.2738.0.

The app starts but remains indefinitely on the startup spinner.

Bundled desktop app-server:
codex-cli 0.158.0-alpha.2.1

The Codex VS Code extension works normally on the same machine/account.

Observed startup sequence:

renderer starts
settings_ready succeeds
authentication succeeds
pub/sub connects
shell_visible is never emitted
sidebar_ready is never emitted
home_visible is never emitted
app_start eventually fails with reason=timeout after ~121 seconds

Codex Doctor:

overallStatus=warning
auth OK
WebSocket handshake OK (HTTP 101)
provider reachability OK
config OK
no FAIL checks

However, while the desktop app and its bundled app-server are visibly running, Doctor reports:
desktop.app.version -> running=false
desktop.app_server.handshake -> "the desktop application is not running"

The active processes are:

ChatGPT.exe (desktop main process)
bundled codex.exe app-server child process

Read-only integrity checks did not find corruption in the inspected SQLite/LevelDB state, and no concrete GPU/auth/network failure was found.

I have additional sanitized diagnostic reports if useful.

I can reproduce the same startup-spinner failure on Windows with ChatGPT/Codex Desktop 26.924.2738.0.

Additional sanitized evidence from my desktop log may help isolate the failure path.

Environment

Windows 11 x64
OS release reported by the app: 10.0.26200
Desktop package: OpenAI.Codex_26.924.2738.0_x64
Bundled app-server: 0.158.0-alpha.2.1
Web ChatGPT works normally on the same account/network

Troubleshooting already attempted

Repair
Reset
Full uninstall/reinstall from Microsoft Store
Fully terminating all ChatGPT/Codex processes
Closing VS Code/Cursor/other possible Codex clients and launching only the desktop app
VPN is already using global proxy + TUN

None of these changed the behavior: the desktop app opens and remains indefinitely on the startup spinner.

Startup sequence that succeeds

The log shows that the backend/runtime side initially comes up normally:

[AppServerConnection] Transport start success connectionId=1 hostId=local transport=stdio
[AppServerConnection] initialize_handshake_result ... outcome=success transportKind=stdio
[AppServerConnection] Codex CLI initialized
[AppServerConnection] ... next=connected ... initialized=true
[window-manager] window main frame finished load ...
[electron-message-handler] [chatgpt-account-lookup] ... authenticatedAccountPresent=true authMethod=chatgpt ... result=succeeded

The primary runtime installation/validation also finishes successfully:

primary_runtime_validation_finished ... outcome=passed problemCount=0
primary_runtime_install_finished ... status=installed

IPC/app-server failure observed later

After startup, the log records repeated IPC connection resets, then the already-connected local app-server is stopped, followed by EPIPE:

[IpcClient] Received broadcast but no handler is configured method=ipc-connection-reset
[IpcClient] Received broadcast but no handler is configured method=client-status-changed
[IpcClient] Received broadcast but no handler is configured method=ipc-connection-reset
[IpcClient] Received broadcast but no handler is configured method=client-status-changed

[AppServerConnection] Stopping app-server transport connectionId=1 transport=stdio
[AppServerConnection] app_server_connection.state_changed cause=stop_process ... previous=connected next=disconnected ...

[IpcRouter] Socket error errorCode=EPIPE errorMessage="write EPIPE"
[IpcClient] Received broadcast but no handler is configured method=ipc-connection-reset

There are also multiple [IpcRouter] I am the router entries during startup.

One earlier warning is:

Failed to start the Artifact Session host
Artifact Session host Unix-socket transport is not available on Windows.

However, this does not appear to be immediately fatal in this run, because the app-server subsequently starts, completes its initialize handshake, and authentication succeeds.

This suggests the spinner may be associated with the desktop IPC/client lifecycle rather than runtime installation or authentication.

I can provide a longer sanitized log if useful. No credentials, email addresses, account IDs, project names, or private repository names are included here.

Update: I was able to isolate the problem to the local .codex state.
The app had been working normally. The failure happened after this sequence:

I was working in an existing conversation (“Kuristiku esimesed tunnid”).
ChatGPT asked to switch to Work mode in order to create a Word document, and I allowed it.
The .docx file was created successfully and opens normally.
After the document task completed, I sent a short “thank you” message in the original conversation.
At that point the app became stuck, and every subsequent launch showed the permanent loading spinner.
Additional troubleshooting showed that network connectivity, WebSocket connectivity (101), authentication, reinstalling/resetting the app, and killing all ChatGPT/Codex processes did not resolve the issue.
The workaround that fixed it:

I completely closed ChatGPT/Codex.
I renamed %USERPROFILE%.codex to .codex-old.
I launched ChatGPT again.
The app immediately reached the normal sign-in screen instead of the loading spinner.
After signing in, my server-side conversations reappeared normally.
I then tested the affected original conversation. It opens normally with the fresh .codex state, accepts new messages, and responds normally. I also closed and relaunched the Windows app afterward, and it still starts normally.
This strongly suggests that the startup hang was caused by something in the old local .codex state rather than by the conversation itself, authentication, or network connectivity.
One potentially relevant detail: the failure occurred immediately after a Work-mode/document-generation workflow. The old local state contained workspace/thread state associated with that workflow. I cannot confirm that Work mode itself caused the corruption, but the timing may be useful for debugging.
I have kept the original .codex-old directory and can provide specific non-sensitive state files or diagnostics if useful.

Potential workaround reported by another user:

Fully close ChatGPT/Codex.
Rename the local .codex state directory from %USERPROFILE%\.codex to something like .codex-old.
Relaunch ChatGPT/Codex.
Sign in again if prompted.

In that report, the app stopped hanging on the permanent loading spinner after recreating a fresh local .codex state, and server-side conversations reappeared normally afterward.

This suggests the startup hang may, in some cases, be related to corrupted or incompatible local .codex state rather than network connectivity, authentication, or the app installation itself.

It may be worth testing this as a reversible workaround by renaming the folder rather than deleting it.

Confirmed — renaming the local .codex directory and letting the app create a fresh one also resolved the permanent loading spinner for me. Thanks for sharing the workaround.

Confirmed - renaming the local .codex directory works to me as well. Cheers!

Additional Windows startup-white-screen report on OpenAI.Codex 26.924.2738.0, observed on 2026-09-27. This is a related symptom report; a shared root cause with the original issue has not been established.

User-visible behavior

The user normally launches from the Windows Start menu.
The app repeatedly opens to a white startup window and cannot be used.
The user reports that repeating a repair operation sometimes allows entry, but recovery is inconsistent; the exact repair operation has not been independently verified.
A later launch became usable, so this installation's failure is intermittent rather than permanently reproducible.
This is distinct from the user's earlier existing-chat send-button blockage (reported in Windows desktop: existing-chat sends indefinitely blocked by loading-local-config / pending codex-home; main-window reload recovers, normal restart can recur #44342); we have not established a common cause.

Verified local evidence

Installed/running MSIX package: 26.924.2738.0, x64. Package registration reports normal status. Times below are UTC+8.

A launch at approximately 11:29 recorded an app-start timeout at 11:31:23:
- name=app_start, outcome=failure, reason=timeout
- durationMs=121464.5
- renderer_entry_evaluated=1449 ms
- host_services_ready=1488.7 ms
- renderer_ready=1717.6 ms
- host_startup_ready=1725.5 ms
- settings_ready=2189.6 ms
- rendererWindowVisible=true
  These partial readiness events did not result in a successful app-start measurement.
A separate launch at 11:35:49 logged:
- Desktop bootstrap failed to start the main app, phase=bootstrap-import-main
- followed by updater startup recovery and “The process has no package identity.”
  The updater error occurs AFTER the bootstrap failure, so it is not established as the original exception or root cause. The launch mode of this specific failed instance is unknown.
The later usable instance started at 11:36, with explorer.exe as parent and no test-profile or debugging command-line switches. Main, GPU, utility, and renderer processes were present during the later inspection.
No matching Windows Application crash/hang events (1000/1001/1002) were returned by the day's query. This does not exclude an exception handled inside the app.

Read-only inspection of the installed bootstrap code indicates that the catch path destroys existing BrowserWindows, logs the generic bootstrap phase, sends the underlying exception to error reporting, and then attempts updater recovery. The local generic error line does not expose the original exception.

Requested investigation

Please correlate startup-timeout and bootstrap-failure diagnostics for this release, expose the original startup exception in actionable local diagnostics, and provide a supported recovery path preserving local chats, projects, and research files. Repeated repair attempts have not provided dependable startup.

No raw chat transcripts, credentials, account identifiers, private project paths, or full logs are included in this public report. No cache reset, reinstall, permission changes, or process termination was performed during this diagnostic pass.

Further user clarification

The user has already tried waiting approximately two minutes and closing/reopening; these did not reliably recover the app. After closing the visible window, ChatGPT background processes remain. The user clarified that force-termination DOES complete, but relaunching afterward still produces a white window; a fresh launch after ending the processes is therefore not a reliable recovery. Repeated repair/open attempts sometimes work. The required workflow is local Work with existing local tasks and files; ordinary browser chat is not an adequate substitute. Please provide a recovery procedure usable even when the desktop UI itself cannot load.

The user additionally clarified that the research task was intentionally paused before this investigation. Its inactive/interrupted status should not be counted as an unexpected task failure or as evidence of the startup root cause. Background process presence alone does not establish whether research work is running.

The .codex rename workaround does not resolve this on 26.924.2738.0 in my case.
Reporting it since four people above confirmed it worked for them, so there
appears to be a second factor.

Environment

Windows 11 Enterprise, build 26200.9445 (25H2), x64
Microsoft Store package OpenAI.Codex 26.924.2738.0
Arrived via an in-place Store update; the deployment itself was messy
(Remove, two Stage attempts, then Register within ~13 minutes)

Symptom — the app dies within ~20 s of every launch. No window, only a
modal dialog "ChatGPT failed to start. The process has no package identity."
Desktop log, in this order:
error Desktop bootstrap failed to start the main app phase=bootstrap-import-main
info [sparkle] in_app_updates_policy_startup_recovery policy=pending
error [sparkle] Failed to set up updater errorMessage="The process has no package identity."

Note the ordering: bootstrap-import-main fails first; the package-identity
error is downstream of it, not the cause.

Tried, no effect (each verified, not assumed)

Renamed %USERPROFILE%\.codex per the workaround above — state dir was
recreated clean (fresh sqlite files), still fails
Full uninstall (Remove-AppxPackage) + clean reinstall from the Store, with
%LOCALAPPDATA%\OpenAI\Codex emptied first
Reboot (which cleared 6 pending PendingFileRenameOperations)
Add-AppxPackage -Register of the manifest
Windows Settings → Repair: reports success in the UI, but the AppX
deployment log shows three 0x80073D02 "apps need to be closed" failures.
The packaged service CodexSandboxService.OpenAI.Codex (StartType
Automatic) keeps the app counted as running — it must be stopped first,
otherwise Repair silently never completes.

Ruled out by measurement, so please don't spend time here

Runtime extraction is complete, not truncated: runtimes\cua_node\<hash>
has 2,366 files with a valid manifest.json
(cua-node-0.0.24-20260924074400, node 24.21.0). Earlier runtimes on this
machine ranged 846–4,366 files, so file count alone is not an indicator.
Not a MAX_PATH problem: LongPathsEnabled=0, but the longest extracted
path is 234 characters and no file exceeds 240.
Package is intact: app.asar 482 MB and readable, all helper binaries
present, Status: Ok, IsPartiallyStaged: False, SignatureKind: Store.
Network is fine: chatgpt.com, ab.chatgpt.com, api.openai.com,
auth.openai.com and persistent.oaistatic.com all resolve with TCP 443 open,
no proxy configured.
No Windows Application crash event is generated, and on most attempts no
desktop log is written at all.

One anomaly that may help localise it: roughly 1 launch in 10 gets past
the bootstrap and instead shows a different dialog, titled "Codex" —
"Organization settings could not be loaded ... A network connection, proxy, or
firewall may be preventing access" with Retry / Sign out / Quit. That launch
then dies too. So the bootstrap failure is intermittent rather than absolute,
and something in the org-settings/auth path sits immediately behind it.

Request: please treat the .codex rename as a partial workaround only.
On this machine the bootstrap import fails with a clean state dir, a clean
package and a complete runtime, which suggests the import failure has a cause
independent of local state corruption.

Confirmed - renaming the local .codex directory works to me as well. Cheers!

Update: When I start my PC after it has been shut down, the loading problem comes back. This means I need to rename the .codex folder again in order for it to work. So technically, the problem has not been resolved.

Navigation Menu

Repository navigation

[Windows][26.924.1866.0] App launches to a permanent blank white screen after update #48313

_reload workaround _

Environment

Additional account/profile comparison

Troubleshooting already performed

Sanitized startup evidence

Reproduction complémentaire — version 26.924.2738.0 :

lancement normal fonctionnel, échec uniquement en administrateur

Environnement

Comportement observé

Diagnostic du processus pendant que l’erreur reste affichée

Autres observations

Résultat attendu et demande

Environment

Troubleshooting already attempted

Startup sequence that succeeds

IPC/app-server failure observed later

User-visible behavior

Verified local evidence

Requested investigation

Further user clarification

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Windows][26.924.1866.0] App launches to a permanent blank white screen after update #48313

Description

Activity

github-actions commented on Sep 26, 2026

kylerjkirk commented on Sep 26, 2026

_reload workaround _

Oliver3026 commented on Sep 26, 2026

xiaoming2337-byte commented on Sep 26, 2026

jipon0729-svg commented on Sep 26, 2026

Environment

Additional account/profile comparison

Troubleshooting already performed

Sanitized startup evidence

aymenelkhayati112-stack commented on Sep 26, 2026

Reproduction complémentaire — version 26.924.2738.0 :

lancement normal fonctionnel, échec uniquement en administrateur

Environnement

Comportement observé

Diagnostic du processus pendant que l’erreur reste affichée

Autres observations

Résultat attendu et demande

optimssro commented on Sep 26, 2026

kkccckk26-byte commented on Sep 26, 2026

Environment

Troubleshooting already attempted

Startup sequence that succeeds

IPC/app-server failure observed later

ashertece commented on Sep 26, 2026

kkccckk26-byte commented on Sep 27, 2026

kkccckk26-byte commented on Sep 27, 2026

bravoDevVincent021026 commented on Sep 27, 2026

Jiaxu666-dev commented on Sep 27, 2026

User-visible behavior

Verified local evidence

Requested investigation

Further user clarification

aiken070707 commented on Sep 28, 2026

bravoDevVincent021026 commented on Sep 29, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions